Closed dandelany closed 3 years ago
BTW - the "found device" 94-b0-1f-68-5a-99 in the log above is not my MDBT42Q - I'm not sure what it is.
However, running the verbose test a few more times, I did notice that occasionally there are failed runs of the test where getPorts
does not return the Espruino board, but then it does subsequently show up as "found" in the log! eg.:
...
Noble: stateChange -> poweredOn
Noble: Disable Web Bluetooth as we have Noble instead
Noble: Starting scan
Noble: Found device:
Noble: Found device:
Noble: Found device:
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device:
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device:
Noble: Found device:
Noble: Found device:
Noble: Found device:
Noble: Found device:
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device:
Noble: Found device:
Noble: Found device:
Noble: Found device: ALAM (24:64:46)
NOT FOUND :( // getPorts callback called here
Noble: Found device:
Noble: Found UART device: MDBT42Q db64 e8-04-f5-d8-db-64 // here is my espruino
Noble: Found device:
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
Noble: Found device: 94-b0-1f-68-5a-99 94-b0-1f-68-5a-99
(most of the time, though, it's missing from the logs entirely)
Also BTW - this is not a super high priority problem for me, since I can still upload code if I try enough times :) Hopefully it's helpful though.
Hi Dan, thanks - I'm a bit bust at the moment but I'll try and look at this when things calm down.
Because the same code gets used for the IDE itself, the scan is done in the background and for each getPorts call, the devices found up to that point are returned. The scan doesn't immediately stop as soon as the getPorts stops being called (in case getPorts is called >1 time), which might be why you see other devices?
getPorts should be called more than once though, and if it's being called after the UART device is found and isn't returning the device, that's definitely a big bug we should look at.
Also if the CLI is reasonably reliably finding your device after scanning is stopped, we could try calling getPorts one more time to extend the scanning window?
I've got a similar issue using --list
on the Mac (Catalina 10.15.1 / Node v12.18.1), the results are sporadic - however, not unexpected from my experience of working with BLE devices on the Mac, can pick it up pretty consistently with the Nordic app on my phone.
@gfwilliams whats your thoughts on perhaps just adding a timeout option to --list
to allow for longer scan period? e.g. --list 10000
, at a glance it looks like it would be a case of making this timeout configurable? Could be trivialising, but would be happy to take a proper look and create a PR for it.
Ok, as expected definitely trivialised this - wasn't thinking about the fact it would need supported across all the various target platforms 🤦
:) I think it'd be a good idea. Actually it's almost that easy I think:
https://github.com/espruino/EspruinoTools/blob/gh-pages/bin/espruino-cli.js#L683
Although looking at it, Espruino.Core.Serial.getPorts
is called in two places with two different types of timeout, and that should really be merged into one function.
I think probably it needs to call Espruino.Core.Serial.getPorts a few times and actually merge the results it gets
Think this is fixed now - getPorts is called multiple times until a device is found
Hi and thanks for Espruino!
I'm seeing some "flaky" behavior connecting to my MDBT42Q breakout board over BLE using the CLI - sometimes it works, sometimes it doesn't. Retrying usually works after a few times. It almost always works in the Web IDE, but I'd prefer to use the CLI. The board was purchased recently & I just updated to the latest firmware
2v04
. I am running Mac OS Mojave 10.14.6.Here's a test script I wrote, with the relevant bit snipped from the CLI code. I noticed the CLI already tries two attempts to list the ports - I kept this in the test to see if it helps, but it doesn't seem to. I realize this is more likely a problem in the underlying (
noble
?) library, but figured I'd post here in case it's helpful.Here are the outputs from a few runs of the test - I tend to get long strings of "OK" or "not OK" in a row for some reason, but not always. I also don't appear to be getting any "OK on 2nd try," so I'm not sure the retry in the existing code is helping.
Finally, here's a verbose output from a "not working" run. Thanks in advance for any help!