Do you see a handleDisconnected in your log? And where is it relative to XON/XOFF? It might be handy if I could see your log file.
The only thing I can think is that maybe there was a Bluetooth packet that was received with XOFF in it, then the Bangle disconnected, and then the packet was processed after the Bangle reconnected?
Maybe a possible solution would be to send XON automatically on every fresh bluetooth (re-)connect?
As above, I'd have hoped Gadgetbridge did that automatically, but...
So it seems that the Bangle needs some seconds to understand that the Bluetooth connection has been fully lost
Yes, that is the case - but I think that's not a problem... The issue isn't with Bangle.js, it's on the Gadgetbridge side by the look of it.
One potential option is to ensure that Gadgetbridge doesn't even pause transmission forever. In the code I linked mPauseTransaction is a boolean, but we could just make it a counter so when XOFF is received, we pause transmission for maybe 2 seconds.
It might lead to some data loss when Bangle.js was busy for a very long time (compacting for example), but in the majority of cases that'd probably a lot better than the alternative of it locking up.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Well, it could be, but Gadgetbridge should automatically turn flow control back on when it disconnects, connects, or attempts a reconnect - for example: https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BtLEQueue.java#L312-L315
Do you see a
handleDisconnected
in your log? And where is it relative to XON/XOFF? It might be handy if I could see your log file.The only thing I can think is that maybe there was a Bluetooth packet that was received with XOFF in it, then the Bangle disconnected, and then the packet was processed after the Bangle reconnected?
As above, I'd have hoped Gadgetbridge did that automatically, but...
That would be an easy one to try actually, you could just edit the connect event at https://github.com/espruino/BangleApps/blob/master/apps/android/boot.js#L253 to send
Bluetooth.print("\x11");
and see if that helps.Yes, that is the case - but I think that's not a problem... The issue isn't with Bangle.js, it's on the Gadgetbridge side by the look of it.
One potential option is to ensure that Gadgetbridge doesn't even pause transmission forever. In the code I linked mPauseTransaction is a boolean, but we could just make it a counter so when XOFF is received, we pause transmission for maybe 2 seconds.
It might lead to some data loss when Bangle.js was busy for a very long time (compacting for example), but in the majority of cases that'd probably a lot better than the alternative of it locking up.