Posts made by bmillier

@kl3m3n That was quick! Yes, your code which restarts the advertising in the onDisconnect routine is much better. I believe I tried putting it there first but I don't think it would compile ("not in scope" error). Then I checked out that Kolban demo and just did it his way.
You must be a pretty good programmer to be handling all aspects of this by yourself. Even programmers that do both MCU programming and either smartphone or PC applications, are often not good writers- i.e. their documentation is poor. Your's is excellent.
FYI. I have used an IOS app called TechBasic which is something like GUI-O in that it lets you communicate with MCUs via Bluetooth. It is, however, a Basic interpreter running on the IOS device. So, its a bit more versatile but you do the actual programming/development on the IOS device itself. That's not ideal. The TechBasic app itself starts up like a PC IDE for Basic programming, and you can compose/edit or select & run your Basic programs from there.. So, it's not really a stand-alone app that a non-programmer can use easily. The auto-connect feature of GUI-O is quite superior in this respect.
Also, as far as I know, IOS only works in the BLE mode- not the legacy Bluetooth SPP mode. I happen to like that the Android OS lets you use legacy Bluettoth/SPP.
So, I agree- you are right to be hesitant about an IOS app. There would be a lot of adaptation you would likely have to do.
Again- thanks for your attention and efforts on my forum posts.

@kl3m3n Hi:
I sent the patched BasicBLE_NUS.ino file to the email address you mentioned. The added lines are marked with the comment "//BM added". I don't feel that you need to acknowledge me in the demo because I just studied a BLE uart example originally written by Neil Kolban and ported to Arduino by Evandro Copercini, and changed your demo accordingly.
I understand your issues with IOS. I had wanted to write IOS programs to act as a GUI for my MCU projects about 8 years ago. I used PCs at work and at home, but had purchased a Mac Mini because I was also doing support functions for some of our staff that used Macs exclusively. However, shortly after I got interested in trying to write IOS apps in Objective C, the Mac OS had to be updated to use it, and my Mac Mini wouldn't support the update. So, I was disappointed. Later on when Swift , Clang came along, I didn't want to spend another $1500 to buy a new Mac. Also, to be honest, I found Objective C hard to understand- I use C for everything now, but used Visual Basic on PCs and BascomAVR for the AVR MCUs I was using at that time.
As far as I know, there's nothing like your GUI-O on IOS- at least not that I've found. Since Matjaz gave me a free license, I can't see what you charge for GUI-O. But, if you decided to do an IOS version, I think you should charge more- there is not a huge market for this sort of app, but those who need it would be willing to pay more than the usual $5-$10 that apps often sell for. For IOS, there's no way the average MCU programmer is going to be able to develop their own IOS app for something like this.
BR

@kl3m3n Good news! I solved the problems.
I decided to eliminate some unknowns so I tried my ESP32 running BasicBLE_NUS- connecting to my iPad running Adafruit's Bluefruit BLE Connect (utility/diagnostic app). It connected properly, I could send @init and get the GUI screen setup code back. But, when I disconnected, I could not re-connect- same as GUI-O. So, the problem was in the BasicBLE_NUS program. After some troubleshooting, I determined the problem was that the BasicBLE_NUS was failing to re-instate advertising after the disconnect. I added code to this program to start the advertising up again after a disconnect. Now both GUI-O and the Adafruit BLE Connect program run properly even after multiple disconnect/connect cycles.
Regarding the 30-40 sec delay I was experiencing. The blame for that lies with the OS on my Samsung Note 10.1 (Lineage 16). Whether I was running GUI-O or Adafruit's Bluefruit BLE Connect, it took 30-50 secs to connect with this tablet. However, running BasicBLE_NUS and connecting to my iPad, running Bluefruit BLE Connect, the connect time was instantaneous. I'm going to take this opportunity to encourage you to port GUI-O to IOS
I don't know how to attach my modified BasicBLE_NUS.ino to this message. If you want to see the code I changed, maybe give me your email address, and I can attach it to that.
BR

@kl3m3n Thanks-
I went into the Android Settings/Bluetooth and used "Forget this device" on the BasicBLE_NUS device, Now, it still takes 30-40 seconds (after the ESP32 says BLE has connected) to switch to the characteristic screen, but now I see the Nordic UART service. When I select this, the GUI-O demo now works. However, like you, if I close the GUI-O app, I cannot run GUI-O again until I re-boot the ESP32 (even though my ESP32 Serial monitor shows that the ESP32 BLE has disconnected).
After I re-boot the ESP-32, if I open GUI-O again (with autoconnect selected) it will successfully auto-run the demo app- but it still takes 30-40 seconds to connect.
But, the need to re-boot the ESP32 between connections is not good!
Re Wi-Fi. When I said that ESP32-S3 only has BLE, I really meant that it doesn't have legacy Bluetooth. I already have my own code for the ESP8266 or ESP32 which allows me to control/monitor an ESP32/8266 target using either Android or IOS phones/tablet with a web browser-based interface (that the ESP32/8266 serves up). Its written for a specific project- not versatile like GUI-O is, but adequate. I got interested in GUI-O for cases where Wi-fi was not available/practical- but Bluetooth was a good option.

BR

@kl3m3n Hi:
I am trying out the BasicBLE_NUS example. It acts virtually the same way as the BasicBLE example. The serial monitor on my ESP32 reports that a connection is made- almost immediately.
But, it still takes 30+ seconds and then comes up with the 3 available services: 0x1801,0x1800 and 0xFFE0. If I choose 0x1800, I then have 3 choices for characteristic: 0x2A00, 0x2A01, 0x2AA6. The 0x2A00 choice gives an error- and you have to re-boot ESP32 to try again. So does 0x2A01 and 0x2AA6
Trying service 0x1801 yields characteristic of 0x2A05 which then shows a connection but the GUI-O app just says "Connected device not responding".
Trying service 0xFFE0 yields characteristic 0xFFE1. When chosen, this shows a connection but again, the GUI-O app shows the error message "Connected device not responding".

Looking at your BLE_NUS code, I cannot figure out where all of the above services/characteristics are coming from. It seems the FFE0/FFE1 values are "left over" from the BasicBLE.ino program I had tried before. I know the ESP32 caches WiFi SSIDs, etc. but wonder if it stores BLE characteristics in non-volatile Flash too?
I am wondering if this problem arises from my Android tablet, and not GUI-O code? It is an older Samsung Galaxy Tab 10.1 which I had to root and then install Lineage 16 Android OS. My wife has a much newer LG Android smartphone, but currently I only have GUI-O licensed for the Note 10.1
Sorry for all this trouble- I'm doing fine with legacy Bluetooth, so the BLE is not a deal-breaker for me- except that I can't use my ESP32-S3 which only has BLE.
BR

@kl3m3n Hi:
Yes- I think that in terms of a GUI-O - supplied BLE demo, it would make sense to use either the Nordic or UART service as a default because a newcomer would like the demo to work immediately and not have to figure out the service/characteristic. In the BLE demo C code, it would be easy to add a comment at the top explaining that a person can pick another service besides UART and maybe include commented out example code for another service.
I have some experience with BLE and the various services using the Cypress MCUs. I have to admit I am "old-fashioned": I prefer to use the simple SPP protocol and write my own parsing routines for various functions. I really don't like those really long UUIDs- they're too long to recognize/remember.
BR
Brian

@kl3m3n Hello. The BLE example did work for me but only after waiting 30 seconds or more for a connection, and then I had to pick both the service and the characteristic. This is not intuitive since several UUIDS show up in the scan for both choices. The FFE0 and FFE1 (the ones that work) are specified in the demo code, but not mentioned in the video, if I remember correctly.
For the BLE demo, I am using the same ESP32 board(s) that work very well with GUI-O legacy bluetooth (and connect almost immediately).
Like you, I cannot re-connect if I quit the QUI-O app, and re-open the GUI-O app. But, if I re-boot the eSP32, then I can re-connect- but with the same long connection time, and the need to re-enter the service and characteristic UUID. So, basically the same as you, but mine takes much too long.
When I try the procedure you mention at the end of your note, if I re-boot ESP32 while I am waiting (30 sec++) for a connection, I just get an error in GUI-O. But, if I don't reboot, and just wait, eventually it connects. My boards also contain a WROOM-32.
I don't know if this matters, but I also see a few other BLE devices during the scan. I expect they are the 2 Amazon Firesticks I have, or maybe the Raspi's that I also have running and which have BLE connectivity (which I don't use).
On a happier note, I submitted my article to SE with a GUI-O project and they are processing it now. Also, another, more complex project that I am doing using GUI-O + legacy Bluetooth is working well, at this stage anyway. That project is for Circuit Cellar, but will be a ways off.
BR
Brian

@kl3m3n
thanks for looking into this. While I am doing fine with legacy bluetooth with an ESP32, I also have ESP-S3 boards which I will use in the future, and the S3 only works with BLE

I have had success using GUI-O in Bluetooth SPP mode with ESP32 and auto-connect.
I have recently tried to use GUI-O BLE mode using an ESP32-S3 with the GUI-BasicBLE example. It works somewhat:

1. It takes about 20-30 seconds for the GUI-O app to acknowledge that it has made a connection- even though the serial monitor on the ESP32-S3 shows a connection very quickly.
2. You then have to pick 0xFFE0 for service and then 0xFFE1 for characteristic.
3. Then the dashboard works.
4. if you then switch on Autoconnect, and re-start GUI-O, it brings up the Quick Connect menu but shows 2 separate BasicBLE devices ( I only have 1 ESP32 running)
5. Picking either one does not show a "connect" message on the ESP32 serial monitor and shows a bluetooth low energy error message on GUI-O app
   The same thing happens if I use a standard ESP32 module (non S3) with the same GUI-O_BasicBLE example code.
   It appears that one cannot use the autoconnect function with BLE and also that you cannot reconnect to an ESP32 while running the GUI-O_BasicBLE example.
   Thank you

@kl3m3n On another, unrelated topic- I use the ESP32 arduino core version 2.0.3-RC1, since it adds support for the newer ESP32C2, C3 etc. This version works fine with the BasicBluetooth demo you provide, and I am using straight Bluetooth for my current project.
However, out of curiosity, I tried to compile the GUI-O_BasicBLE demo. It wouldn't compile. It turns out that I had to remove the existing,older ESP32_BLE_Arduino-master folder from my Library folder. After that ,it will link with the proper BLE library that comes with the ESP32 vers. 2.0.3-RC1 core. Other GUI-O users, who have also upgraded to the latest ESP32 core library, may have the same issue if they have that other, older library installed.
BR

@kl3m3n
Hi- Yes, I agree that adding the sendMsg is not necessary- the programmer will know what their specific routine is named.
I just tested to see if Live Designer would work properly with my HC05 Bluetooth port when I still had my ESP32 target MCU plugged in and showing up as a Com port on my PC. It didn't work before the beta 0.2 but it does now.

@kl3m3n Thanks! I tried out the beta. .2 and I see that the double quotes are ESCed as I asked. This will save some time and confusion, I think.
I see the serial port changes but not sure what this corrects for. I had reported to Matjaz that if you leave your target MCU plugged into the PC, and select (in my case) the USB-com port that my HC05 is connected to, and which is needed for the live designer to work, that live designer would immediately jump to the comm port that the target MCU was connected to. No problem unplugging the target MCU, but was confusing at first.
I didn’t have time to try this with beta .2
BR

@kl3m3n
Hi kl3m3n. Thanks a lot for your fast response and news that you think my suggestion is useful. I am new to GUI-O (started it only last week) and I will have some other questions/comments, I’m sure.
I must say that GUI-O is very much like I would have designed myself- if I had any experience with programming on Android ( I use iPhone/iPad personally but revived an old Samsung Galaxy Note 10.1 by rooting it and putting Lineage 16 OS on it, when I discovered GUI-O).
As I mentioned to Matjaz, I write for Svet Elektronika and Circuit Cellar (here in N.A.) and want to write some articles featuring GUI-O.
Best Regards

@kl3m3n
The GUI-O Live Designer works well in allowing the user to add/customize widgets and

1. see them on the Android target device

2. observe the Initialization string that must be sent to the target Android device

   However, it would be very useful if the developer could take the Initialization strings shown in the right hand window
   and directly incorporate them into their MCU's C code. If you look at GUI-O's demo programs, they send the necessary initialization strings to the target as follows:

sendMsg("|LB UID:title X:50 Y:15 TXT:"Simple light switch" FFA:"font8" FSZ:3.5\r\n");

void sendMsg(const String &msg) {
btSerial.write((const uint8_t*) msg.c_str(), msg.length());
}

As you can see, they are using the String variable type to define and send out an initialization string. If you were to copy an initialization string from the right-hand window of Live Designer, for some commands you could merely paste this (copied) string after the
SendMsg("
and then add \r\n"); at the end.

However, any initialization strings which have the " character embedded in them, will have to ESCAPE the " using a preceding \ character. (As in the LB command shown above).
An experienced "C" programmer will be aware of the need to ESCAPE the " , but it is still a bother to have to do this editing.

I would suggest that it would be a useful addition to GUI-O Live Editor, if there could be an option button which would change the right-hand window's display to a "C" code format. That is:

1. Add a " at the start of the init. string
2. ESCAPE any " characters
3. Add a \n\r" at the end of the init. string.
4. optionally add a SendMsg( at the beginning and a ); at the end.

Realistically, anyone using the Live Designer app will be inserting the initialization strings into "C" code for the target MCU, and this would be the quickest way to accomplish this.
Thank you.