Using Jolt as a Bluetooth long range relay device

[AndySmee]

Having got the Bangle js2 to act as a peripheral to the Play-Cricket Scorer app, running on an iPad (this is a constraint), I've now tested the range from the iPad to the Bangle and it is appalling! The iPad (on BT 4.2) drops the connection at about 15m line-of-sight. I didn't imagine it would be that useless. So now I am looking at options to extend that range.

I like the idea of using a Pixl to act as a peripheral mini scoreboard over 1mbps phy but then replaying the characteristic to the Bangle js2 over coded phy.

Would that work?

The data is tiny, typically a string of 8-10 characters, and occur every 30 seconds or so, in a burst of 3-5 messages 100ms or more apart. Could I just advertise this data on coded phy without the Bangle needing to actually connect? Or could the Pixl connect to both central and peripheral devices to relay messages?

[gfwilliams]

Hi! Unfortunately Pixl.js uses the nRF52832 which can't do Bluetooth Long Range. You could use another Bangle.js, or a Jolt.js (but that has no display).

It would be pretty trivial to hook a Jolt.js up to a display (even potentially a big 7 segment one), but it's not an 'out of the box' solution. Assuming you did that though:

Could I just advertise this data on coded phy without the Bangle needing to actually connect?

I'd imagine so - you could probably scan on coded phy and then have the 'relay' device advertise itself but on normal Phy?

Or could the Pixl connect to both central and peripheral devices to relay messages?

I think it could do that too (holding central+periph at the same time isn't a problem), although while Pixl/Jolt/Bangle/etc can all do that only Jolt/bangle currently do the long range.

[AndySmee]

Here's the two sides at my last iteration:

Bangle as peripheral:

NRF.disconnect(); // drop BLE connections to allow restart of BLE
NRF.setTxPower(8); 
NRF.setAdvertising({}, {
  name: 'Umpire Watch',
  showName: true,
  discoverable: true , // general discoverable, or limited - default is limited
  connectable: true,  // whether device is connectable - default is true
  scannable : false ,   // whether device can be scanned for scan response packets - default is true
  whenConnected : false ,// keep advertising when connected (nRF52 only)
  //manufacturerData: [over + '.' + counter],
  interval: 1000, //});
  phy: "coded"});

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

Jolt as central:

const CONNECTION_OPTIONS = {
    minInterval:1000, 
    maxInterval:4000, 
    phy:"coded"
  }

addLog('Starting request device');
  NRF.requestDevice({ filters: [{ namePrefix: 'Umpire Watch' }], phy:"coded" }).then(function(device) {
      addLog('Device found');
      remoteDeviceFound = true;
      remoteDevice = device;
      return device.gatt.connect(CONNECTION_OPTIONS);
    }).then(function(g) {
      LED1.reset();
      addLog('Gatt connected');
      gatt = g;
      gatt.device.on('gattserverdisconnected', function(reason) {
        LED1.set();
        addLog('Gatt disconnected');
      });
    return getRemoteService(gatt);
    }).catch(function(e) {
      addLog(e);
      LED1.set();
      //setTimeout(function(){E.reboot();},1000);
    });

function getRemoteService(gatt) {
  return gatt.getPrimaryService("5a0d6a15-b664-4304-8530-3a0ec53e5bc1").then(function(service) {
    addLog('Service found');
    LED1.set();
    return service.getCharacteristic("df531f62-fc0b-40ce-81b2-32a6262ea440");
  }).then(function(characteristic) {
    addLog('Characteristic found');
    LED1.reset();
    scoreCharacteristic = characteristic;
    NRF.setTxPower(8);
    addLog('TX power set to 8dBm');
    return characteristic.writeValue("HLO123\n");
  }).then(function() {
    addLog('Hello sent');
    //LED3.reset();
    LED2.set();
    setTimeout(function(){
          LED2.reset();
          //LED3.set();
        }, 50);
    GattConnected = true;
  }).catch(function(e) {
    addLog(e);
    LED1.set();
    //setTimeout(function(){E.reboot();},1000);
  });
}

[gfwilliams]

Thanks for digging into this @fanoush! It would be good to get something like those changes in so we can get more info about what's going on. Maybe I have a way to get generic connection info like MTU too.

@AndySmee are you sure that both devices are running the 6.1.1 SDK? Jolt.js that shipped with 2v26/2v27 should have it, but if your Jolt had an older firmware it'd still be using the older SDK and that might be stopping it?

I might try not setting minInterval:1000,? I'm not sure but that seems a bit long and I guess if that failed, maybe it would fail to negotiate the coded phy too. I'm clutching at straws though

[fanoush]

It would be good to get something like those changes in so we can get more info about what's going on. Maybe I have a way to get generic connection info like MTU too.

Yes, would be nice to have information about the connection somewhere including currently negotiated MTU. The central connections have the gatt server object but the peripheral connection is not available like this? it could be exposed somehow and have same/similar structure as the server one? also there is the NRF.getSecurityStatus which is similar as it has the 'connected' flag.

As for the phy update method - I created generic method updateConnection first, but when thinking what other parameters could be updated there is not much, mainly the connection interval - but for peripheral connection there already is NRF.setConnectionInterval(interval), however there is not equivalent for the central. Additionally I was thinking about MTU but it looks like that could be negotiated only once per connection so "mtu" parameter should possibly go to primarily to connect method options. An if there was a flag to not negotiate MTU right after connection, only then it would make sense to do it later via updateConnection. To sum it up - if creating PR for this would you better prefer updatePhy or setPhy method or this updateConnection way?

As for MTU I was checking if it would make sense to make it lower it when creating coded phy connection but it looks like there is no need after all according to this https://devzone.nordicsemi.com/f/nordic-q-a/80956/improve-communication-throughput-changing-conn_params-and-att-mtu-params/339247 - for coded phy the lower layer splits it into smaller packets so higher MTU does no harm(?).

[fanoush]

Also what about events? maybe the phy (and MTU?) change could be done vie event so one could handle it and store the value somewhere if interested. Also why the RSSI change is not done via events on the connection too, is event more heavy than the setRSSIhandler? There already is connenct and disconnect event https://www.espruino.com/Reference#t_l_NRF_connect

EDIT: maybe the discussion should go to some created issue

[gfwilliams]

Yes, probably best on a new issue. I'll make one

Events are a good plan, thanks! setRSSIHandler was done so that we don't always wake up to handle/check if the event is handled even if there is no handler. But for MTU/Phy that happen rarely events would be fine.

[fanoush]

And BTW if I let it connect over coded phy and then run

NRF.updateConnection({"phy":"auto"})

on the peripheral it will switch to 2mbps for me, here is output on the central side, 7 is 1+2+4=all requested, 2 is the result

>gatt.phy_req
=[ 7, 7 ]
>gatt.phy_res
=[ 0, 2, 2 ]

[gfwilliams]

@fanoush I've just pushed bba081b23 with code to handle these changes (and MTU) as events. Does that all look ok to you?

[AndySmee]

Looking outside of Nordic, there seems to be a couple of things which are implied by coded phy "long range at both 500 kbps and 125 kbps speeds" and "receive sensitivity of the coded PHY at -101 dBm (500 kbps) and -106 dBm (125 kbps)" [https://community.infineon.com/t5/Blogs/Long-Range-Communication-with-Bluetooth-Really/ba-p/436291#.]

I'll start recording RSSI scans when testing, and see whether there is a difference between the cutoff behaviour on coded vs 1mbps, and maybe 2mbps

[earp123]

You mentioned the supervision timeout. Currently we set this (SLAVE_LATENCY_CENTRAL) to 2x intervals. I can try raising it - I'm not sure if there are any good reasons why it shouldn't be higher.

My project could benefit from this being higher as well. I'm bit confused on how the documentation reads but I think the latency has a max value of 8 intervals?

[gfwilliams]

I've just pushed a change that increases this to 4 intervals, and you can now do device.connect({slaveLatency:...}) to configure it manually.

[AndySmee]

I've just pushed a change that increases this to 4 intervals, and you can now do device.connect({slaveLatency:...}) to configure it manually.

How do I get that update?

[gfwilliams]

Just install the latest 'cutting edge' build - any change I push should get compiled and put there within ~5 minutes

[enaon]

You mentioned the supervision timeout. Currently we set this (SLAVE_LATENCY_CENTRAL) to 2x intervals. I can try raising it - I'm not sure if there are any good reasons why it shouldn't be higher.

one question on this. Is supervision timeout and SLAVE_LATENCY_CENTRAL the same thing? I read that SLAVE_LATENCY_CENTRAL unit is intervals * the Connection Interval, and after that time, if there is no respronse, starts the timer of supervision timeout is seconds, and after that the connection is dropped. If this is correct, we do not have supervision timeout setting, is this true?

[enaon]

I am using this thread as it has a lot on nice info, I hope it is ok, I am trying to test the coded range, and I am failing miserably.

I have 4 devices, a Bangle.js 2, a Rock, a Magic3, and a nano.

the Bangle and the Magic3 are on 2v27, the nano and the Rock are on 2v27.36. The Bangle and the Magic3 are softdevice 6.0.0, the rock and the nano are 6.1.1

I use the Rock to scan for phy:"coded", but this step make no difference, I can use the nano or the Bangle with the same results, using this:

NRF.setScan(function(d) {
  print(`
id ${d.id}
name : ${d.name}
rssi: ${d.rssi}
`);
},{phy:"coded"});

No script other a watchdog is running on the Magic/Rock, nothing is running on the nano, on the bangle I use the clean boot option.

I use this line to enable advertising on coded on the devices that act as peripherals:

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

what works:
I can scan the devices from the rock, all of them, as long as I am connected from the IDE to one of the devices I use as peripherals, and I have just issued the above command.

As soon as I disconnect, the device is lost, I cannot see it on the Rock no more. I have E.setFlags({onErrorSave:true});, and in the error fiile I get an ERR 0x13.

Only the Bangle.js2 works as expected, when I disconnect the IDE from the Bangle when using it as a peripheral, I can still see if from the Rock. The others, I cannot, they give the ERR 0x13 and they are not visible any more.

is there any hint I could use?

[enaon]

on the manual on the site it says:

1mbps,coded - both long range and normal, but advertisements sent on the 1mbps phy - this allows for long range connections while also being compatible with everything
but I think this doesn't work, as it does not allow for scannable :true, even if 1mbit is the advertising mode.

I managed to have advertising on both coded and 1mbit, and be able to connect using the IDE (chrome) from windows, using this:

switchAdv = {
  type: 0,
  start: function() {
    this.type = 1 - this.type;
    NRF.setAdvertising({}, { interval: 500, name: "eC-test", connectable: true, phy: switchAdv.type ? "coded" : "1mbps", scannable: (switchAdv.type ? false : true) });
    setTimeout(() => { switchAdv.start(); }, 1000);
  }
};
switchAdv.start();

So I do not really understand this line:
On NRF52833/NRF52840 based devices you can specify phy (the physical connection type used) as:
is NRF_setAdvertising really about connections too, or just advertising?

and one last thing if one has a android phone that supports coded. Can one check when the BT on the phone is on, and NRF connecct is scanning, if espruno hungs when using NRF.setScan with phy:"both"? In my case, my phone (samsung) makes all of my espruino devices that are currenty scanning on phy both, reboot due to the watchdog timeout, no errors, they freeze and the watchdog reboots them.

[fanoush]

is NRF_setAdvertising really about connections too, or just advertising?

well advertising is separate in the sense that device may not even support connections but it is first step to connection. you cannot connect without device advertising and the advertising advertises that the device is connectable (and/or scannable = accepting scan response request)

EDIT: and NRF.setAdvertising should really be about setting advertising

but I think this doesn't work, as it does not allow for scannable :true, even if 1mbit is the advertising mode.

I think 1mbps,coded implies extended advertising and I think scannable is not possible for extended advertising no mater what phy you are advertising on. Extended advertising sends just small packet over advertising channel with info about on which data channel and when the (possibly much bigger) rest of advertising data will be sent a bit later and there is no time (and even reason) to try to fit handling scan request and scan response (which is again over advertising channel) into such already complicated flow.

Nordic softdevice cannot advertise on both automatically so it advertises only on the first in the list. Switching advertising as you did is probably the best solution for now.

as for reboots, this is strange as phones typically don't advertise at all so should not affect scanning, do you run something special on phone to advertise over BLE? setscan may crash the device if it has too small stack and/or you do something slow or memory intensive in the handler so something overflows (which may be related to too many devices around you?)

[enaon]

as for reboots, this is strange as phones typically don't advertise at all so should not affect scanning, do you run something special on phone to advertise over BLE?

Nothing, if you have a phone with coded support, can you plese check it? Enable BT, start scan with NRF connect, take the espruino device really close to the phone, and do a scan on "both" like so:

I get 100% freezes, every time, 5 devices reboot the same time.

NRF.setScan(function(d) {
  print(d);
}, {  interval: 600, window: 300, phy: "both" });

so something overflows (which may be related to too many devices around you?)

I do have a lot, but disabled them all, just the android when scanning on 'both", instant freeze on the espruinos. That is only on "both", just coded or just 1mbit is fine.

I think 1mbps,coded implies extended advertising and I think scannable is not possible for extended advertising no mater what phy you are advertising on.

yes I noticed that, it is just that on the site it says that it will work as a normal 1mbit, I think it a mistake.

[fanoush]

That is only on "both", just coded or just 1mbit is fine.

that's strange, can you remove the print(d) or print something small like print(d.id)

I do have such phone and tested setScan with "both" many times before. I do have BT enabled all the time on the phone for gadgetbridge connected to Bangle. But I don't think phone advertises by default when bluetooth is enabled without doing anything special. The nrfConnect Android app can start advertising via setting up 'advertiser' tab with data and toggling it on.

[enaon]

that's strange, can you remove the print(d) or print something small like `print(d.id

the same, instant freeze, and you are corret, NRF connect has nothing t do with it, I just killed it, it the same. I do not even get a line of output on the espruino if the phone is very close to the esrpruino and the BT is just enabled n the phone, I guess it does advertise when enabled for a while.

this results to no output, instant freeze and wathdog reboot. If I turn off the Bt on the phone, all is ok.

>NRF.setScan(function(d) {
:  print(d.id);
:}, { timeout: 300, interval: 600, window: 300, phy: "both" });
=undefined

if the phone is some 3-4 metee away, I do get some output and then a freeze.

I also get a freeze with NRF.requestDevice when on "both" not imediatetly, after 2-3 tries. I do not have any devices on coded now, something has to to do with the "both" option. Anyway, if you cannot replicate, them maybe we will find it at a later time.

this is a test, on coded there are no devices now, I put them all to sleep, on 1mbit it works fine for days, the same on only coded, I use on the cats a lot, on both, instant freeze if I have the phone near by. bangle, and nano, and magic, all freeze, maybe it is just my phone.

2v27.47 (c) 2025 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>NRF.setScan(function(d) {
:  print(d.id);
:}, {  interval: 600, window: 300, phy: "coded" });
=undefined
>
>
>not frozen
Uncaught ReferenceError: "not" is not defined
    at REPL (:1:1)
not frozen
^
>NRF.setScan()
=undefined
>NRF.setScan(function(d) {
:  print(d.id);
:}, {  interval: 600, window: 300, phy: "both" });
=undefined

--instant freeze here

I do have BT enabled all the time on

if you have not tried it and have some time, please test it after just enabling BT on the phone, mine has no issues if it was enabled a long time before, but freezes the espruinos on both if it is just turned on.