Confirming this is the MDBT42Q breakout board with 2V04.
I poked around various BLE documentation some more and -- running out of other options -- set the scan to 'active' in NRF.requestDevice({active:true, ...)}. That made a big improvement in the connect() success rate!
The sensor I'm using supports active scanning ... in my BLE understanding this should be compatible with passive scanning (it just allows the peripheral to send additional advertising data in a second packet) but apparently the MDBT42Q stack doesn't handle this transparently.
The point is that for (some?) devices a passive scan appears to return a different MAC address of the peripheral than an active scan. So when NRF.requestDevice() does a passive scan (which is the default) and finds a device with a specific MAC, but then you pass that MAC into connect() then it doesn't match the active scan MAC of the device and the connection times out. This is very reproducible in my setup if I flip between {active:true} and {active:false}.
The reason this worked in the nRF app may be because the nRF app handles passive vs. active scans transparently ... there appears to be no way in the app to select passive vs. active scanning and maybe the underlying stack deals with the change in MAC automatically.
In any case, using NRF.requestDevice({active:true, ...)} raised the rate of connect() success significantly ... I still get occasional errors that the device is not found or the connect attempt times out (BLE isn't 100% reliable, so that's OK), but now the code succeeds in pulling off the data from the sensor in >80% of runs so that's a huge improvement.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Hi Robin,
Confirming this is the MDBT42Q breakout board with 2V04.
I poked around various BLE documentation some more and -- running out of other options -- set the scan to 'active' in NRF.requestDevice({active:true, ...)}. That made a big improvement in the connect() success rate!
The sensor I'm using supports active scanning ... in my BLE understanding this should be compatible with passive scanning (it just allows the peripheral to send additional advertising data in a second packet) but apparently the MDBT42Q stack doesn't handle this transparently.
I found a hint here: Passive scan returns different address type than active scan for BLE devices -- this appears to be related to the nRF BLE stack, but this post is for a Linux Python driver.
The point is that for (some?) devices a passive scan appears to return a different MAC address of the peripheral than an active scan. So when NRF.requestDevice() does a passive scan (which is the default) and finds a device with a specific MAC, but then you pass that MAC into connect() then it doesn't match the active scan MAC of the device and the connection times out. This is very reproducible in my setup if I flip between {active:true} and {active:false}.
The reason this worked in the nRF app may be because the nRF app handles passive vs. active scans transparently ... there appears to be no way in the app to select passive vs. active scanning and maybe the underlying stack deals with the change in MAC automatically.
In any case, using NRF.requestDevice({active:true, ...)} raised the rate of connect() success significantly ... I still get occasional errors that the device is not found or the connect attempt times out (BLE isn't 100% reliable, so that's OK), but now the code succeeds in pulling off the data from the sensor in >80% of runs so that's a huge improvement.
Best,
-- Terrence