Factory default behavior is for the HS2xx3A start automatically on power-up. This library works off this assumption, which should be fairly safe, but there should be a way to make this more reliable.
There's not currently a command (that I'm aware of) that will query the running status of the device. Factory default behavior has the sensor dumping out $JYBSS messages once per second, so that's a clear indication that the sensor is running. But this option can be changed (via setUartOutput), so we shouldn't rely on that.
Also, I've observed on my own project that setting options in a setup() function sometimes fails. My guess is that we're trying to feed configuration to the sensor before it's ready (e.g. internal start-up is complete)? I haven't been able to replicate this in a direct serial connection, so I'm not certain how this problem manifests.
I know this sensor has about a 5-second initialization/self-calibration period wherein presence detection does not occur, but I don't believe that this correlates with the "not ready" status that I've encountered.
Needs:
Develop reliable methods for determining:
- stopped/started state
- if the sensor is "ready"
Might also be a good idea to figure out what the start-up time is of the internal firmware (independent of the 5-second initialization/self-calibration period).
Observations:
-
If you send a sensorStop when the sensor is already stopped, it will respond with something like "sensor stopped already" and "Error" instead of "Done". Same for sensorStart. However, issuing the stop/start command just to check for the "Error" response won't work for determining state because you might end up stopping or starting the sensor instead.
-
I've discovered that sending a single space character causes the sensor to respond with the leapMMW:/> prompt, so this might be a way to check that the sensor is not only alive and connected, but also "ready."
-
In a direct serial connection, I've observed the sensor rebooting itself -- can't recall exactly what that messages looked like on the serial console, but it was clearly a reboot. Did I have a funky config value? Need more experimentation with this...
Factory default behavior is for the HS2xx3A start automatically on power-up. This library works off this assumption, which should be fairly safe, but there should be a way to make this more reliable.
There's not currently a command (that I'm aware of) that will query the running status of the device. Factory default behavior has the sensor dumping out
$JYBSSmessages once per second, so that's a clear indication that the sensor is running. But this option can be changed (viasetUartOutput), so we shouldn't rely on that.Also, I've observed on my own project that setting options in a
setup()function sometimes fails. My guess is that we're trying to feed configuration to the sensor before it's ready (e.g. internal start-up is complete)? I haven't been able to replicate this in a direct serial connection, so I'm not certain how this problem manifests.I know this sensor has about a 5-second initialization/self-calibration period wherein presence detection does not occur, but I don't believe that this correlates with the "not ready" status that I've encountered.
Needs:
Develop reliable methods for determining:
Might also be a good idea to figure out what the start-up time is of the internal firmware (independent of the 5-second initialization/self-calibration period).
Observations:
If you send a
sensorStopwhen the sensor is already stopped, it will respond with something like "sensor stopped already" and "Error" instead of "Done". Same forsensorStart. However, issuing the stop/start command just to check for the "Error" response won't work for determining state because you might end up stopping or starting the sensor instead.I've discovered that sending a single space character causes the sensor to respond with the
leapMMW:/>prompt, so this might be a way to check that the sensor is not only alive and connected, but also "ready."In a direct serial connection, I've observed the sensor rebooting itself -- can't recall exactly what that messages looked like on the serial console, but it was clearly a reboot. Did I have a funky config value? Need more experimentation with this...