Is it a completely different number, or just the difference between public/random?
Usually non-active scan works fine and as you note, Active just allows extra data to be transferred (via a scan response packet). Normally devices don't rely on that because it's super unreliable when you get in congested radio areas.
It seems like the address type being reported isn't public or random - and I guess it's possible that in that case Espruino defaults to the wrong one...
About 30% of the time: "ERROR No device found matching filters"
The usual fix for this would be a long timeout, but it seems you're already doing that. My guess would be that the device is advertising its name in a scan response packet (only available with active:true rather than in the main packet).
If you could find another way to filter (maybe run NRF.findDevices(print) and see if anything recognizable like a service UUID is present) then you might be more reliable connections.
About 30% of the time: "ERROR Connection Timeout"
What does NRF Connect say the advertising interval is?
I guess what might be happening is: the BLE device you connect to advertises very rarely (1 sec or less) and only speeds up when it gets asked to provide a scan response in an active scan.
If you're then connecting after doing a non-active scan, the advertisements are too far apart for the MDBT42 to be able to reliably connect.
About 30% of the time: IDE disconnects from MDBT42Q during execution of the program (usually around connect()), so I loose the console and don't know what's happening
That's really strange. The 2v04 firmware is really very reliable with Bluetooth and I can't remember the last time I crashed it while connecting to anything. You mentioned a Serial connection earlier - if this happens again please can you try while connected on Serial and see if any errors get reported.
Anyway, glad you got it working more reliably with active:true. It's very hard for me to debug any firmware issues if I can't reproduce though.
Am I right in thinking you're in Germany? If this continues to be an issue is it possible that you could lend me one of those devices to try out?
I just tried this connecting to nRF connect on my phone, and definitely have issues connecting. On closer inspection it seems to be because the phone is using a RANDOM_PRIVATE_RESOLVABLE address (most devices either public or random static), and Espruino was interpreting that as a public address.
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,
Sorry you've had so much trouble with this - I'll try to answer what I think might still be outstanding but let me know if I missed anything...
Wow, I have never come across that before at all. And you actually see a different MAC addresses if you do:
Is it a completely different number, or just the difference between public/random?
Usually non-active scan works fine and as you note, Active just allows extra data to be transferred (via a scan response packet). Normally devices don't rely on that because it's super unreliable when you get in congested radio areas.
The fix applied for that Python issue you found looks odd as well: https://github.com/IanHarvey/bluepy/commit/91227b7335acdc23703be4b7de45e804b3231be8
It seems like the address type being reported isn't public or random - and I guess it's possible that in that case Espruino defaults to the wrong one...
The usual fix for this would be a long timeout, but it seems you're already doing that. My guess would be that the device is advertising its name in a scan response packet (only available with
active:true
rather than in the main packet).If you could find another way to filter (maybe run
NRF.findDevices(print)
and see if anything recognizable like a service UUID is present) then you might be more reliable connections.What does NRF Connect say the advertising interval is?
I guess what might be happening is: the BLE device you connect to advertises very rarely (1 sec or less) and only speeds up when it gets asked to provide a scan response in an active scan.
If you're then connecting after doing a non-active scan, the advertisements are too far apart for the MDBT42 to be able to reliably connect.
That's really strange. The 2v04 firmware is really very reliable with Bluetooth and I can't remember the last time I crashed it while connecting to anything. You mentioned a Serial connection earlier - if this happens again please can you try while connected on Serial and see if any errors get reported.
Anyway, glad you got it working more reliably with
active:true
. It's very hard for me to debug any firmware issues if I can't reproduce though.Am I right in thinking you're in Germany? If this continues to be an issue is it possible that you could lend me one of those devices to try out?
I just tried this connecting to nRF connect on my phone, and definitely have issues connecting. On closer inspection it seems to be because the phone is using a RANDOM_PRIVATE_RESOLVABLE address (most devices either
public
orrandom static
), and Espruino was interpreting that as a public address.I have now fixed it, so if you try with a 'cutting edge' firmware from http://www.espruino.com/binaries/travis/master/ you may have more success.
It still doesn't explain the crashes you were seeing though as mine just failed with
ERROR Connection Timeout
each time.