How to increase the search time for finding a device?

[MaBecker]

looks like this is static set to 3sec.

https://github.com/espruino/EspruinoTools/blob/dbbfb3f14256b1fcbed198731884fddafb8e4d1a/core/serial_noble.js#L131-L135

Could this be added as a new command line option?

[gfwilliams]

I don't believe that's where you have the issue. I think it's in:

https://github.com/espruino/EspruinoTools/blob/master/bin/espruino-cli.js#L742

and

https://github.com/espruino/EspruinoTools/blob/master/bin/espruino-cli.js#L802

But yes, it could be a command-line (or maybe just config) option

[Totalus]

I found that increasing the following timeout value helps a lot to detect my BLE device:

https://github.com/espruino/EspruinoTools/blob/1b9109dcd847c8354d96316fa990133f13ba6fa6/core/serial.js#L169

[gfwilliams]

@Totalus so you see the Port .... not found - checking ports again (X attempts left) message when using --verbose?

The idea is it keeps checking repeatedly, so if the device is available it will continue pretty much as soon as it is, while waiting if not.

What about changing the number of attempts in https://github.com/espruino/EspruinoTools/blob/1b9109dcd847c8354d96316fa990133f13ba6fa6/core/serial.js#L145 so that it just waits a bit longer in total but doesn't delay if it picks the device up at the start

[Totalus]

@Totalus so you see the Port .... not found - checking ports again (X attempts left) message when using --verbose?

Exactly

The idea is it keeps checking repeatedly, so if the device is available it will continue pretty much as soon as it is, while waiting if not.

What about changing the number of attempts in

https://github.com/espruino/EspruinoTools/blob/1b9109dcd847c8354d96316fa990133f13ba6fa6/core/serial.js#L145 so that it just waits a bit longer in total but doesn't delay if it picks the device up at the start

Both modifications seem to help, though there are still moments when the BLE device is not detected. I would prefer a more robust detection so I don't need to call my command to flash the board again each time it does not find the device.

[gfwilliams]

What's the device name you are trying to flash?

If it isn't an Espruino board we know about (https://github.com/espruino/EspruinoTools/blob/1b9109dcd847c8354d96316fa990133f13ba6fa6/core/utils.js#L711) then EspruinoTools will rely on having the Nordic UART service in the scan response packet to identify it. The problem with that is it's a packet that has to be requested, and in areas with a lot of radio traffic it can be really sketchy whether it appears or not - it's nothing to do with EspruinoTools.

[Totalus]

I am specifying the device mac address in the command I am using to flash, so it has nothing to do with the device name or visibility of the Nordic UART service I believe.

I think the problem is more in the scan timeout. By default there is only a 2.5 seconds timeout for scanning devices (both for espruino --list and espruino -d <device>), which seems a bit too short for properly picking up all devices around. Even though most devices advertise at an interval generally below 1 second, it seems like not all the advertising packages are systematically caught by the device scanning, so it takes more time to find all the devices.

The best would be to allow the user to specify the timeout value as a command line argument. This way you could keep a default to a decent waiting time but still provide a way to handle environment where detection si more difficult and takes more time. Let me make a PR.

[gfwilliams]

Thanks for the PR - just merged.

Out of interest is the device you're trying to flash one of the ones I linked in that post above, or is it something else.

mac address... so it has nothing to do with the device name or visibility of the Nordic UART service

Ok - I think you'll be fine but just so you know the code for that (which uses addRecognisedDeviceAddress to shortcut the uart check) was added reasonably recently and I'm not 100% sure that's in NPM yet. So if you were using the NPM version I guess you might have git the issue with the UART service

[gfwilliams]

I think we can close this now as that --scan-timeout PR should definitely fix the original issue