• a bluetooth connection loss falls exactly into the time between XOFF and XON

    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?

    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...

    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.

    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.

About

Avatar for Gordon @Gordon started