Custom BLE service freezes bangle while peripheral to iPad

[AndySmee]

I have an unexpected problem getting a custom BLE peripheral service working on the Bangle js2 from a "central" iPad. It works completely when the central device is an Android phone.

I am working on extending my Umpire Ball Counter app to connect to a cricket scoring app commonly used for scoring cricket matches in the UK. The app is the ECB's Play Cricket Scorer app (PCS) which is available on Google Play and the Apple app store.

The app offers an "External Scoreboard" feature which sends updates to bespoke cricket scoreboards via Bluetooth. It turns out that the protocol is very simple and I've successfully ported the service and characteristic UUIDs discovered by the team at https://buildyourownscoreboard.wordpress.com/optional-play-cricket-scorer-app-integration/

This works well when I run the PCS app on my Google phone and connect my Bangle js2 as the external scoreboard to the app in its match settings (see link above). My umpire app interprets the values sent by PCS and updates a js object with the simple numbers which would appear on a physical scoreboard but also interprets the sequence of scoreboard updates to infer the runs or extras scored on each ball of the over... happy days!

However, when I tried to connect from the iPad version of PCS app the Bangle app freezes. It seemingly doesn't respond to touch or btn actions whilst connected. However, when I disconnect my "scoreboard" in the PCS match settings, the touch and btn events appear to fire all at once, and scoreboard events via Bluetooth even appear to have taken effect.

The problem is that while I can debug on Android, as the terminal in Chrome can connect to the Bangle after I've made the "scoreboard" connection, I can't debug on the iPad, so I don't know if there is an exception occurring or something else going on.

Any ideas?

[AndySmee]

The code is simple enough to post here (but isn't ready for app review ☺️)

NRF.disconnect(); // drop BLE connections to allow restart of BLE

NRF.setAdvertising({}, { name: "Umpire Ball Counter", showName: true, discoverable: true , // general discoverable, or limited - default is limited
connectable: true, // whether device is connectable - default is true
scannable : true , // whether device can be scanned for scan response packets - default is true
whenConnected : true ,// keep advertising when connected (nRF52 only) interval: 1000});//,
//phy: "1mbps, coded"});

NRF.setServices({ "5a0d6a15-b664-4304-8530-3a0ec53e5bc1" : { "df531f62-fc0b-40ce-81b2-32a6262ea440" : { value : ["BTS100/9"],
writable : true,
onWrite : function(evt) { try { var typeA = new Uint8Array(evt.data, 0, 3); var dataA = new Uint8Array(evt.data, 3); //console.log(E.toString(typeA), E.toString(dataA)); logPCS(E.toString(typeA), E.toString(dataA)); } catch { g.drawString(e, 10, 10); } } } } });

NRF.on('connect', function(addr) { Bangle.buzz(1000); });

NRF.on('disconnect', function(reason) { Bangle.buzz(1000);
PCS.connected = false;
addLog((new Date()), over, counter, "BT Disconnected", reason); });

[AndySmee]

My next step was going to be to test coded phy from iOS, which probably isn't supported but I do need the long range when umpiring some 45m from the central device.

[AndySmee]

Thanks for the link. In the event, neither the 6th Gen iPad or my Google Pixel 6 can connect to services advertised on coded phy, so that's the end of my journey there. However, a nugget for future searchers; the BT 4.2 system on the iPad shows low RSSI but can broadcast round corners 😂 (@ 15m through walls, -86dBm) whereas the Pixel does not get through from that location at all. But the Pixel offers much higher RSSI stats using its BT5.2 when in line of sight (-38dBm @ 10m vs -75dBm @ 10m for the iPad). I will take things into the cricket field next and see if it is viable on 1/2mbps without coded phy at 45-50m.

[fanoush]

neither the 6th Gen iPad or my Google Pixel 6 can connect to services advertised on coded phy, so that's the end of my journey there

If in nrfconnect app when going to device information you see "Long range (PHY Coded) supported NO" then indeed that's the end. If you see green YES then there is some chance. Without changing anything on the Bangle2 you can try and connect to it in nrfconnect over normal 1mbps connection and then when connected click three dots and "set preferred PHY", if you see "LE Coded" there both for TX and RX you may try to check just those and click ok. then if you slide to the right to see the log you may see PHY updated(TX: LED Coded, RX:LE Coded)

[AndySmee]

neither the 6th Gen iPad or my Google Pixel 6 can connect to services advertised on coded phy, so that's the end of my journey there

If in nrfconnect app when going to device information you see "Long range (PHY Coded) supported NO" then indeed that's the end. If you see green YES then there is some chance. Without changing anything on the Bangle2 you can try and connect to it in nrfconnect over normal 1mbps connection and then when connected click three dots and "set preferred PHY", if you see "LE Coded" there both for TX and RX you may try to check just those and click ok. then if you slide to the right to see the log you may see PHY updated(TX: LED Coded, RX:LE Coded)

I replied on another thread, but... including "coded" in the advertising [note, as a peripheral in my use case] prevents scanning, so renders the peripheral invisible to scanners which are not in our control. Is that an absolute constraint of needing extended advertising for coded packets? That you can't be scannable?

Edit: NRF.setAdvertising({}, {
: name: "Umpire Ball Counter",
: showName: true,
: discoverable: true , // general discoverable, or limited - default is limited
: connectable: true, // whether device is connectable - default is true
: scannable : true , // whether device can be scanned for scan response packets - default is true
: whenConnected : true ,// keep advertising when connected (nRF52 only)
: interval: 1000, //});
: phy: "1mbps,coded"});
WARNING: Extended/coded advertisements can only be used with scannable:false. Disabling scan response.

Result: device not visible in NRf connect

Edit, edit: now not sure, it's not consistently reproducible

Final edit: I'm totally confused. NRf connect now shows the device but no connect button.

[fanoush]

Is that an absolute constraint of needing extended advertising for coded packets? That you can't be scannable?

as I understand it yes, coded phy advertising => must use extended advertising => cannot be scannable. I think it is also technical limitation - extended advertising data is sent in normal data channels with some delay, not in three advertising channels, it is already more complex so scan response (which is handled over advertising channels) would be even more complicated (and not really useful)

If you want to only advertise over coded phy (with no connections) then it is not an issue since everyone who can scan for it will support extended advertising.

As for connections - as explained you can connect in the old way and then switch to coded phy if device supports it. However at the time of the connection you cannot be far away.

For compatibility with other devices one can also switch advertising - alternate between legacy and extended.

And BTW the "1mbps,coded"value means it will advertise only over 1mbps (= the first one), not both, that's how nordic softdevice works. Only "coded' or "coded,1mbps" will advertise over coded phy. it is there becasue BLE has notion of primary and secondary PHY and you need to set them somehow so you can use this combination if it is useful for something.

[AndySmee]

Thanks. I noticed something in a clean re-test so started a new topic here https://github.com/orgs/espruino/discussions/7783 . It may just become a reference point and be closed but needed a clean new thread

[gfwilliams]

Is that code enough to reproduce the problem completely? And your Bangle.js firmware is up to date?

One thing I guess might be an issue is if you're writing a lot of log information to the console? Maybe the fact that the iPad connects via Bluetooth but then doesn't request information from the Bluetooth UART service means that Bangle.js stores everything you're outputting via console.log/print and then when the output buffer gets full it stalls?

I honestly thought I had added something to work around that (detecting when notifications are enabled and ignoring console.log calls if not) but maybe there's something about iOS that's confusing it.

So maybe try one of:

• Commenting out all console.log/print so the Bangle isn't printing anything to the console
• Add Terminal.setConsole(1) to your code (which will cause all console.log to go to the Bangle's screen)
• Add E.setConsole(null,{force:true}) to your code (which will cause all console.log to be ignored)

Note that with the last 2 you won't be able to connect/flash the Bangle while your app is running because the console gets moved out the way

[AndySmee]

I'm on 2.25 firmware, so I'll try 2.27.

I've installed a BLE browser on the iPad (Bluefy) so I can access the ide but, after connecting, the ide console gives an error: Connection Failed: TypeError: JSON.stringify cannot serialize cyclic structures.

That is connecting when in clock mode, not after starting my app, so don't know if there's a clue there. I'll try firmware next before trying again

[AndySmee]

I'm on 2.25 firmware, so I'll try 2.27.

I've installed a BLE browser on the iPad (Bluefy) so I can access the ide but, after connecting, the ide console gives an error: Connection Failed: TypeError: JSON.stringify cannot serialize cyclic structures.

Just to confirm, this cyclic structure error is still happening after upgrading to 2.27 firmware. If it remains an issue, I'll split it out to a new ticket

[gfwilliams]

The error is not in Espruino though - it doesn't create error messages like that. That'll be the IDE I guess

[AndySmee]

My primary issue is resolved. Piping all console logs to screen fixed the freezing issue;

Add Terminal.setConsole(1) to your code (which will cause all console.log to go to the Bangle's screen)

[AndySmee]

The error is not in Espruino though - it doesn't create error messages like that. That'll be the IDE I guess

For completeness, this was the error when the ide doesn't receive console messages, as I'd piped them to the bangle's screen