Change bluetooth communications channel from repl?

[RKBoss6]

For BlueWatch, the iOS companion app, I'm struggling a bit with the default bluetooth communications channel being the same as the repl and console. SInce prints and logging show up at the same time as the app and phone handshake, it's struggling to connect properly without interference from prints, functions, and other data on the repl stream, and the commands often get corrupted or mixed with another line in REPL as a result. Is there a way that I can separate the communications between the app to watch, and the repl and app loader in the app? I know you can always make your own characteristics for communications, or change where the console is set, but I don't quite know if that's the way to go about this, or if there's an easier way.

[farfromexact]

For a phone-to-watch protocol, I would not share the same line-oriented channel with the REPL and console output. A custom BLE characteristic with a small framed protocol is the robust solution.

The frame should include a message type, length, sequence or request ID, payload, and checksum/CRC if corruption is possible. The watch can send notifications for responses/events, while writes from the phone carry commands. That keeps application traffic independent from debug prints and avoids trying to parse a stream that can legally contain arbitrary console text.

If a custom characteristic is not practical for the first prototype, move the REPL/console to a different transport and reserve the existing BLE channel for the app, but document the trade-off: changing the console can affect the app loader and development workflow. Temporarily suppressing prints during the handshake may hide symptoms, but it will not solve interleaved output during normal operation.

Also make the protocol tolerant of partial BLE packets. A single write/notification is not guaranteed to contain one complete application message, so the receiver needs a buffer and a parser that can recover from an incomplete frame. Add a version byte and reject unexpected frame types instead of letting a malformed command enter the REPL.

That separation will make BlueWatch more reliable and leave the console useful for debugging instead of turning debug output into a source of protocol corruption.

[gfwilliams]

Are you a bot account? In one day you produced 10 very wordy responses in a variety of different projects.

I value contributions and new users, but I'm just interested... I don't want answers that a user could have got just by pasting the question into an AI.

[gfwilliams]

It's not ideal, but we have managed pretty much ok with Gadgetbridge and the App Loader so far. If you split by newline, and ignore anything that doesn't start with { and is valid JSON it usually works out fine.

the commands often get corrupted or mixed with another line in REPL as a result.

This shouldn't happen? do you have an example? In the App Loader/etc we send "\x10" (char code 16) before commands which turns echo off for that line (so if you're not doing that you may be having issues).

It's easy to say that it should be a custom characteristic, but there are all kinds of gotchas. As the post above mentioned, partial writes - and the limit on the maximum size for characteristic writes (so how would you split one notification over several writes). Also we handle the Nordic UART characteristic internally (with a buffer) so it's more efficient than just a direct write.

... not to mention the difficulty adding features and being backwards compatible if there's a predefined communications format with message IDs (especially if you define that just for your iOS app).

Having said that, recent builds have added a packet protocol on top of the standard Nordic UART channel: https://github.com/espruino/Espruino/blob/master/README_Protocol.md

It's also supported by UART.js (https://github.com/espruino/EspruinoWebTools/blob/master/uart.js#L83-L94) and the app loader does increasingly try and use it - so you could use that for sending commands, and at least you get an 'ack'.

There's also this which might be handy: https://github.com/espruino/Espruino/blob/master/src/jsinteractive.c#L1871

Char code 5 (Ctrl-e) -  on a new line, ENQ(enquiry) outputs `Espruino 2v25 JOLTJS\n` or similar

so you can do that right after connect to get info on the device

[RKBoss6]

Thanks! Here's an example of the commands mixing for reference:
Upon connect, BlueWatch sends a command to the repl require("bluewatch").receive("BlueWatch Connected");, which acts as the first stage in the device handshake. The bangle sees this message in the receive function and sends back "Handshake successful". However, when I looked at what's actually going through the repl, it is intermixed with other data, due to the fact that the watch also sends its health data upon connect, so it looks like this: {t:"health", bpm:85, steps:303Handshake Successful, movement: 344}. While I can fix this issue, there's always the chance for more issues like this down the line, and I'd rather try to solve the issue from the root.

Right now though, I'm actually having a separate problem with bluetooth pairing. When I pair the watch to my iPhone, it does the usual pairing, notifications and connection, but when I disconnect the watch for a period of time, it doesn't reconnect to the phone like it used to. Manual connection via the bluetooth settings menu doesn't work either, it's as if the watch is no longer there, even though all the bt settings are on. I've tried factory resetting, clearing pairing data hard and soft, and uninstalling both Bluewatch apps from each device in case it's something there, but it doesn't look like anything's going wrong there. I'm not sure whether this is a phone problem or bangle problem, I've rebooted both devices several times...

[gfwilliams]

{t:"health", bpm:85, steps:303Handshake Successful, movement: 344}

This shouldn't be possible. JavaScript doesn't allow one bit of JS to interrupt another, so you can't just have a command you send being executed right and outputting in the middle of another.

I think you have a deeper problem - perhaps for some reason you're getting Bluetooth characteristic updates in your app that are appearing out of order?

Right now though, I'm actually having a separate problem with bluetooth pairing.

Sorry - I'm afraid I can't be much help here - but checking if the Bangle thinks it is connected and using another device with NRF Connect to see if the Bangle is advertising or not could help to track it down.

[RKBoss6]

After some searching, I managed to find the source of that pairing issue, which was the line NRF.setAdvertising({}, { connectable: true }); I'm not sure if this is by design, but it looked to me like it prevented the bangle from advertising other services, rendering pairing and notification services inoperational. I've fixed it and pushed it in PR #4305.

As for the communications, I went for a small patch for now, which was queueing each message on both sides and encoding them in Base64 to avoid escaping JSON. Seems to work well now.

[gfwilliams]

That's odd - I'm not sure why it had that (it is your code though?), but the line allows the Bangle to keep advertising while connected )(but when connected the connectable flag is 0 as you might expect). It should still advertise ANCS/etc but the first {} would remove any BTHome/etc from other apps.

edit: there's going to be some communications issue in your app that caused those interleaved packets. You might manage to work around it with base64 for now (although that might just make it fail silently with no error if packets get mixed?) but it'll probably come back to bite you at some point in the future

[RKBoss6]

Yeah, this is just a temporary solution until I can properly rework communications, which should at least be somewhat more reliable than what it was before...