TouchDRO error - connection timed out

I have had a similar issue on occasion but put it down to the 8 year old Chromebook that I'm using. It would generally happen when I walk away from the machine for a period of time. Hitting the Bluetooth button in the app before leaving the workshop for the day has almost completely eliminated the error.

When it has happened, it seems like monkeying with Bluetooth on the Chromebook (or rebooting) would fix it. Rarely I have had to power cycle the interface board. It seems like the Chromebook occasionally tries to connect to the board at the OS level and then the connection to the app doesn't work after that. It's also quite possible that I have no idea what I'm talking about;)
So there are two Bluetooth "bugs" that in combinations can cause 99.9% of TouchDRO connection issues:
1. Some Android images (it was much more common with some older lower-end tablets with Android 4.2.x - 4.4.2 os versions) had a bug where the "socket" was left hanging when the connection was lost (i.e. the "slave" device got turned off or went out of range).
2. Some Bluetooth firmware would not reset "congested" flag when the connection was dropped due to the "master" device going out of range, or going to sleep. When the same device was re-connected, the physical connection would be restored, but the "congested" flag remained set.

These things have to happen together, usually require either the tablet to left sitting with the screen on for weeks, the adapter being powered off at a wrong time while the app is running. The connection issue can be resolved by rebooting the adapter and the tablet. This is also pretty rare, I had two cases last year, and may be 4-5 total cases with the ESP32 based adapter. One was my good friend who lives 20 minutes away, and we spent weeks trying to reproduce this once we knew what to look for.

What Dan is experiencing sounds very different, and given that his adapter is "patient 0" out of couple thousand adapters with this firmware/chip revision, I'm very inclined to believe that this is a failure somewhere.

What you are describing smells very much like some flavor of #2, with potential sprinkling of #1. I don't have a lot of information/data with regards to running TouchDRO via Android VM on a Chrome OS. I test this for basic functionality on Google Pixel Slate and Pixel Chrome, but I suspect there is some variability between different Chromebook implementations, especially around power management.

Regards
Yuriy
 
"patient 0" is "out for delivery" to you today, maybe tomorrow.. (the way USPS runs lately)

Thanks Yuriy for all of your support..
I sense you have fun with TouchDRO, of course with various headaches.
It is a great product for sure..

Dan
 
"patient 0" is "out for delivery" to you today, maybe tomorrow.. (the way USPS runs lately)

Thanks Yuriy for all of your support..
I sense you have fun with TouchDRO, of course with various headaches.
It is a great product for sure..

Dan
Dan,
I'll let you know when it arrives.
I do have fun for the most part, and over the years I've met a lot of great people. It gets a bit stressful when things break, though. I expect that some [hopefully very small percentage] percentage of units will break over time (electronic things are not 100% bullet proof), but there is always this thought "what is this is some bug I missed and other people are going to run into it".

Example: I had a bug in the very first iGaging ESP32 firmware that affected the first 27 units I shipped, and 16 of those units are still "in the wild" (the other 11 customers had me re-program their units). Last December I added a workaround for the Samsung/Lenovo Android power management bug. That fix was to simply send a "bell" character to the adapter to keep the OS from trying to power down the transceiver, but that bell character happens to interact with the firmware and causes all sorts of issues. Now there is a setting in TouchDRO called "disable two way communications" that is there specifically for the 16 buggy iGaging units :(

Regards
Yuriy
 
Yikes.. Your mind must be constantly going.. I can picture as you quietly sit at the dinner table, your wife saying "now what are you thinking about Yuriy" :)
Hopefully you have time to unwind..
 
Last edited:
Yuriy, desperately need you help - the situation: ESP32WROOM connected via USB cable to PC running WIn10. Used PowerShell to flash the firmware. I used your firmware from download section: there is two options, current v1.6 and 1.4. I checked both. My ESP32 is on COM port 16 so Powershell command looked like this:
C:\dro> esptool.py -p COM16 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader.bin 0x8000 partition-table.bin 0x10000 touchdro-diy-universal-1.6.bin
So after this i cycled RESET button on ESP32 module while holding BOOT button and esptool recognized and uploaded all three files with no errors as in attached screenshot.
The problem is ESP32 is not listed on bluetooths devices list. I checked two Android phones (xiaomi 10 pro) and tablet (recent Lenovo pro). So farly new devices and none of them can see "Touch DRO DIY" devices on the list. Same on Win10 BT scan - no such davice available.

What now? ESP32 is standard devkit, called WROOM. Anyway flashing shows zero issues. Why it is not working? :(
 

Attachments

  • powershell screen flashed.png
    powershell screen flashed.png
    28.6 KB · Views: 21
Back
Top