Open ES-Alexander opened 2 years ago
I've just remembered that prior to v3.28.0
firmwares were hardcoded to a particular baudrate, in which case legacy_ping1d_detect
should probably also check 9600 baud, not just 115200. It's also possible the attempts to auto-detect maximum baudrate could be messing up the ability for the device to communicate properly when on older firmwares - they probably shouldn't be checked with other options.
This is weird. the ping seemingly responds with the device ID, ~then responds to the 115200 baud. then we can't talk to it anymore...~ Nevermind, I see your point now. I agree we should start it with None.
Another possible point of failure would be that ardupilot may be trying to use SERIAL3 for something. SERIAL3_PROTOCOL needs to be set to 0
detect_highest_baud
initialises the "last_valid_baud" to 115200, even though it hasn't yet been tested. That means if all bauds below that fail, then even if it fails to connect at 115200 baud it will still log as valid, and be used to register a new (non-functioning) device. Probably it should be initialised toNone
, and raise an exception if thelast_valid_baud
is stillNone
after all intended baudrates have been tested.Issue was discovered thanks to the log in this forum comment, whereby it starts out connecting with
then tries to establish a baud rate (at which point it is seemingly no longer working)
then proceeds to repeatedly
with no
send_distance_data
logs in between.For robustness, we should probably also keep track of repeated reconnect attempts with no data received in between, and possibly kick the device after a few attempts (or at least have some kind of logging + a frontend indication that the device is "there" but not responding as expected). Likely the simplest tracking approach would be to have a
repeated_reconnect_counter = 0
before the loop, increment it every time a reconnect is attempted (and check for the threshold), and reset it to 0 every time a distance message is sent.