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

[gfwilliams]

Can the Jolt advertise on coded whilst connected to a central on 1mbps?

I just tried with NRF.setAdvertising({},{whenConnected:true,phy:"coded"}) when it's connected and it seems to work fine for me?

[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