Bangle.js 2 and 1 Bluetooth Similarities?

[RKBoss6]

For BlueWatch, I'm looking to add support for Bangle.js 1, which is a bit of an interesting approach, as I don't have a Bangle.js 1 to test on. From what I can tell, the Bluetooth sending/receiving should all be the same, as nothing in the app is inherently specific to BJS2, so I'm really just looking for confirmation on a few key points that I need to make sure it works:

• TX, RX, and Service characteristics are the same
• No major changes in how the Bangle receives data through REPL (the app communicates using bluetooth console)
• Chunk size limits for Bluetooth packets or the optimal chunk size? (Right now the app uses a small chunk size of 15 chars, and a setting to take it to 40, which is quite unreliable during testing)
• No changes in how quickly it processes data coming in over bluetooth (this one is an edge case, but I'd like to make sure so it doesn't bite back later on)

I'm also thinking of actually doing a proper beta testing cycle for Bangle.js 1 if the changes are different enough, and use TestFlight/beta feedback, rather than releasing the app and testing on my own watch as I don't have one. I'm not sure how to spread the word for beta testing for bangle.js 1 users if it needs to be done, as it's my understanding that the majority of Bangle.js users have a BJS2 and most are not active on github/discussions.

[enaon]

• Chunk size limits for Bluetooth packets or the optimal chunk size? (Right now the app uses a small chunk size of 15 chars, and a setting to take it to 40, which is quite unreliable during testing)

Standar MTU size is 23, the Bangle1 is at 53, and Bangle2 is at 131. Other than this they use a different softdevice. But how is it possible to get unreliable comms at 40 bytes long chunks? Are you sure you are actually chunking at 40 bytes? Could it be that you have a payload on top of it? If so, 53 will not be enough.

[RKBoss6]

I'm not sure, it could be that it's sending characters somewhere that aren't standard ASCII characters, and so it takes up more bytes, but I doubt it's sending any additional payload apart from the 3 byte header.
Thanks for the MTU sizes though, that'll help!

[gfwilliams]

You may be able to ask iOS what the MTU is - because it's negotiated, just because the Bangle can do it doesn't mean it's actually allowed to by iOS.

Because we can't tell in Web Bluetooth, what I do is set the MTU to the size of the biggest packet I've received over Bluetooth LE from the Bangle. That seems like a nice, safe way of doing it

[RKBoss6]

Yes, it used to call peripheral.maximumWriteValueLength(for: .withResponse), which did basically that, but the chunks it sent using that att kept getting dropped by the bangle, which is why I drastically reduced what it reported of 128 or so.

It could be that I asked for the maximum write value without response, instead of with response like the code above, which would have reported the bytes needed for the response, and additional headers, so I'll look into that more.

[gfwilliams]

Supporting Bangle.js 1 sounds like a neat idea - but ideally you need someone you know has one and is willing to test :)

No changes in how quickly it processes data coming in over bluetooth (this one is an edge case, but I'd like to make sure so it doesn't bite back later on)

It might be a bit slower, and it has a lot less RAM which might hit you.

However Bangle.js and Espruino in general use XON/XOFF flow control so if you honour those then hopefully you'll be fine. If you do the packet transfer protocol it'd be great as well.

[RKBoss6]

Thanks for this - I know you use android, but do you have an iPhone you'd be willing to test with? I imagine you're the only person I know who has access to a bangle.js 1 ;)

[gfwilliams]

I'm afraid not! I have several old iPads but they are effectively e-waste at this point, so I've been trying not to buy more Apple gear :)

[RKBoss6]

No worries! If they're not too old, the app does support iPads if you want to give that a spin, but it has to be on iOS 18 or greater...