Bangle.js 2 Coded PHY Connections? (Central)

[earp123]

Has the Long Range landscape for the Bagle.js 2 developed much since @gfwilliams got it working a couple years ago? I have an application in which the Bangle 2 would be perfect for if it does indeed support connections as a Central device. So far I haven't been able to get it to pick up any advertising packets from my (non-Bangle, non-Espruino) peripheral devices advertising on Coded PHY, let alone connect to them. The peripherals are advertising as connectable however, so I wonder if that's preventing the Bangle from picking it up.

Tangentially related, if this is possible it would be really beneficial for a whole community of users of a product of mine. I'm looking for a clever way for my users to receive alerts on their wrist via a smartwatch from a about 150m away (line-of-sight). If this is possible, I would be sending an entire world-wide community to the Bangle shop :)

[gfwilliams]

We've made a few small changes but there hasn't been a huge amount of feedback on it. I'd have thought that a Bangle could do 150m line of sight pretty well (especially if you're advertising from somewhere with a decent aerial).

My understanding was where it was left we could transmit and receive advertisements on coded phy, and if a connection was made to a device found on the coded phy I think it would negotiate to use coded phy for that connection.

I made an app that allows two (or more!) Bangles to communicate using Advertising, and you can check the source at https://github.com/espruino/BangleApps/blob/master/apps/shownearby/app.js

It's possible that just requesting coded phy when you use NRF.setScan/findDevices/requestDevices would be good enough to find the device that's advertising?

NRF.setScan(function(d) {
  // ...
},{phy:"coded"});

I'm happy to look into making changes to improve matters, but unless you're able to try things out yourself and suggest changes to how exactly we scan (eg at https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L3021-L3023) then I'd probably need a device here to test with.

[fanoush]

I did some quite successful tests with Gadgetbridge over coded phy and reported it in the coded phy github issue espruino/Espruino#2465.
As the nrf52 cutting edge builds are broken now https://www.espruino.com/binaries/travis/master/ here is my build with coded phy changes espruino_2v25.409_banglejs2.zip

I think that with that build and recent android phone that can do coded phy and can see advertising over it (still not that typical, check NordicSemiconductor/Android-BLE-Library#166) you may just run following code in Web IDE

NRF.setAdvertising({},{
  phy:"coded",
  connectable:true,
  scannable:false,
  showName:true
});

disconnect and then just try connect in Gadgetbridge and enjoy improved range. I think you don't need to update softdevice to 6.1.1, even current 6.0.0 should work as long as advertising data in total is up to 31 bytes.

[fanoush]

and can connect from IDE in Chrome on Windows (because of name)

Unfortunately after more testing it looks like extended advertising does not work in Chrome (EDIT: on Windows). I can connect from previously remembered list, sometimes it does show in the list of scanned devices but without any signal strength but mostly it does not show at all. I guess that if it shows it is from some sort of cache. So unfortunately only legacy advertising works in Chrome (tested on Windows and Android), there is also issue here WebBluetoothCG/web-bluetooth#604 about this.

[gfwilliams]

Thanks for all the updates. So for the moment both actually isn't worth adding as it doesn't work?

Swapping the advertising style when we swap advertising packets (SWI1_IRQHandler) would be cool, but I'm not sure how possible it is? I think SWI1 is called right before a transmission is scheduled so I'm not sure we could stop/restart advertising there as that post implies?

Would it be possible for you to post up your extended advertising changes? Or is it literally just changing the size of m_adv_data/tmp_adv_data ? But I guess it's not that important for the current situation as we can still scan for extended advertising ok? It's just if we want to advertise ourself?

[fanoush]

Unfortunately after more testing it looks like extended advertising does not work in Chrome.

This was on windows 10, yesterday I tested in ubuntu 22.04 and latest Chrome and it is more promising there. I did not use WebIDE (will try later) but tried the page that connects to various thermometers with custom firmware https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html and there I could set my thermometer to advertise over coded phy only. This feature is there for quite some time but I know some years ago this meant you simply cannot connect to it from Chrome anymore. Yesterday on linux with builtin intel bluetooth (Gemini Lake platform) I tried again to flash thermometer with recent custom firmware and switch it to coded phy. Then enabled scanning over coded phy via known hack hcitool -i hci0 cmd 08 31 03 07 07 and I could consistently see that thermometer in Chrome scanning dialog on that page also with signal strength and then I could even connect to it. repeatedly. Double checked via nrfconnect that it only advertises over coded phy and with extended advertising and yet it seem to just work from that page. Also when going to chrome://bluetooth-internals/#devices and clicking start scan i do see that thermometer in the results. So nothing is lost yet. It may still not work for many cases but there hopefully is a way to scan for devices with extended advertising if the OS and hardware supports it.

[fanoush]

Would it be possible for you to post up your extended advertising changes? Or is it literally just changing the size of m_adv_data/tmp_adv_data ?

Not sure what you are referring to but apart from addin "both" as posted above which I later changed to "1mbps,coded" and "coded,1mbps" so that I could select the order of primary/secondary, I also tried to merge scan response just after advertising packet but don't remember mentioning that. Anyway, it was a hack but actually not as bad as I thought it would be. I will post that later today to github issue (basically when we find that non_scannable is true and we already crafted nice scan response that we will throw away here, I just concatenate them before calling jsble_advertising_update and allow larger advertising data to overwrite scan response buffers when scan response parameters is null/0). But nothing from that is currently needed that would improve 2 main use cases - connecting from chrome via web bluetooth in WebIDE and/or connecting over coded phy from gadgetbridge. Extending m_adv_data would however help just to have bigger advertising packet for other uses cases. And it theory could help with curent IDE filtering for Nordic GUID if extended edvertising would work for more people then just me on one linux intel laptop and we would not go for replacing it with manufacturer data. And also this will likely break with 6.0.0 softdevice.

[fanoush]

So far I haven't been able to get it to pick up any advertising packets from my (non-Bangle, non-Espruino) peripheral devices advertising on Coded PHY, let alone connect to them

Oh, yes, had the same problem even for advertising. Updating SoftDevice to 6.1.x worked. This Bangle example app worked for some reason but I couldn't get (possibly longer?) advertising packets over coded phy from thermometer until I upgraded SoftDevice as per espruino/Espruino#2465

[gfwilliams]

Sorry for not following up on that properly - I'll reply in espruino/Espruino#2465

[fanoush]

I couldn't get (possibly longer?) advertising packets

Yes I can confirm this now. With S140 6.0.0 I can find device flashed with peripheral_hr_coded example named "Nordic_HRS" but when just changing the name by adding "_1234567890" the advertising data increase to 34 bytes and Bangle2 with 6.0.0 no longer finds it.

[earp123]

Update on my side: I flashed @fanoush 's 2v25.409 build and successfully connected to the Nordic_HRS peripheral sample over coded phy as expected, thanks again for the persistence!

Currently I'm still stuck at getting the Bangle to pick up any advertising packets from my custom board/service that's also over coded phy. I can pick up the Nordic_HRS sample packets just fine with this sketch:

packets=4;
NRF.setScan(function(d) {
  packets--;
  if (packets<=0)
    NRF.setScan(); // stop scanning
  else
    console.log(d); // print packet info
},{phy:"coded"});

//works with Nordic sample but not my custom service :(

But not getting anything from a custom service with near identical advertising parameters. I've been trialing different min and max scan intervals among other typical Bluetooth scan/adv troubleshooting with no luck. The only difference between the two applications (mine vs. Nordic_HRS) is the advertised service and the device name. Reason I haven't taken this to the Nordic forums is that my service does show up on my NRF toolbox app on my Samsung phone and I can confirm that it advertises exactly as the Coded HR sample does. I can connect to it successfully as well. So I was wondering if there was something specific with the Bangle firmware that I still needed to adjust?

EDIT: Just to keep my beacon of purpose in the picture here: This custom service is for a product that could REAALLY use a standalone smartwatch integration; ergo the Bangle.js 2 I believe is the perfect match for this and I'd be delighted to write and maintain the software for it - and send all my customers to the espruino shop to purchase one. The only catch is that the application is over the 150m like I mentioned.

[gfwilliams]

What happens when you don't have VTG connected? I guess it may not be required.

I use the nRF52/nRF52840DK pretty interchangeably so either should be fine

[earp123]

Having VTG open just flashes the on board chip :'( So I have a feeling I'm still missing something. Will update as I investigate further.

[gfwilliams]

Maybe check the USB cable? I guess it's possible the two middle pins aren't connected properly? It might not be something they test at the factory I guess.

[earp123]

After an embarrassingly high number of attempts, I was successful in flashing the hex file with the newer revision of the 840 DK. The trick is NOT to tie the SWD-SEL (formerly VTG) to VDD-NRF as most of the discussions suggest, but to tie SWD-SEL to VDD-NRFHV, located a bit further down the P20 header. The GND Detect pin was not used and the successful attempt was while powering the Bangle from the 5V rail of the DK while flashing. Not sure if the 5V is needed but I think you'll forgive me for not re-bricking the watch to find out.

Sorry for the detour. After recovering the Bangle with 2v25.409 firmware I successfully flashed S140-6.1.1 again and finally was picking up advertising packets from my custom service over coded phy! Still might pester this thread as I work through connecting, discovery, notifications, etc. but thanks again for the persistence!