• 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...

    set the scan to 'active' in NRF.requestDevice... MAC addresses change

    Wow, I have never come across that before at all. And you actually see a different MAC addresses if you do:

    NRF.requestDevice({ timeout: 20000, filters: [{ name: 'devicename'}] }).then(print);
    

    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/comm­it/91227b7335acdc23703be4b7de45e804b3231­be8

    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.

    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.

About

Avatar for Gordon @Gordon started