Sensor data looks like its being filtered on free run mode

[cmydlarz]

After running the Maxbotix vs teh Adafruir US sensors on the roof for >24hours, I see that the Maxbotix looks like it is filtering the distance data and jumps between discrete 10mm values as we saw when the filtered mode was switched on.

This code was pulled from the main branch so I think is current.

Can we confirm what is going on?

[Praneethsvch]

The mode we currently use is Triggered - Real-time Range Data, in which we pull the Pin 4 High for 20us before each sensor reading.

From the datasheet,

• "When pin 4 is low and then brought high, the sensor will operate in real-time and the first reading output will be the range measured from this first commanded range reading. When the sensor tracks that the RX pin is low after each range reading, and then the RX pin is brought high, unfiltered real-time range information can be obtained."
• "Users can enter and remain in the real-time or triggered operation by making sure that before the end each range cycle, the voltage level on pin 4 is set low. After the sensor has completed the last reading, then Pin 4 is brought high. When Pin 4 is brought high, a brand new range cycle starts and the HRXL-MaxSonar-WR will output the most recent range data without filtering."

The same is implemented in the sensor_singleread(void) function.

In contrast, Free-Run Operation uses a filter for increased accuracy and this needs the Pin 4 to be on all times.

From the datasheet,

• "On the HRXL-MaxSonar-WR sensors, when pin 4 is left high, the sensor will continue to range, the data output includes a filter for increased accuracy in environments with acoustic noise."

[Praneethsvch]

Prior to using the serial output, Pulse-width output has an inaccuracy of 0.5% of serial output plus a different 1uS/mm resolution compared to serial, which is simply 1mm. In the latter, the microcontroller calculates the distance based on the duration or width of the incoming pulse which could further add inaccuracies from the clock.

[cmydlarz]

The code definitely looks like it is setup for triggered realtime but it is returning filtered data based on the output from that sensor. Other deployed sensors are also showing filtered output:

Do you think the timing isnt working for the trigger pin so its getting stuck in free run mode?

[Praneethsvch]

This is the change of sensor reads from the beginning, just leaving here for reference:

1. old v2 sensors - Always ON, Trigger every 20us and digitalRead(PulseIn Output)

Hoyt and 5th sensor data:

2. April 5 2021 - Always ON, Trigger every 20us and Serial Read

Carroll and 4th using feather:

Carroll and 4th using Heltec:
3. Nov 15, 2021 - Low-Power using Vext, Trigger every 20us, and Serial Read

From the above series of events, this has been the case since the sensors completely shutdown every sleep cycle using Vext pin.

Further comments: You are right and I still can't comprehend this bug as it is counterintuitive. As the sensor is completely shut off from power, isn't it expected to reset and boot every time giving non-filtered readings? I speculate whether there is an internal memory that keeps track of filtering parameters that are saved beyond power cycles. However, this theory wouldn't hold as we are not running this on filtered-mode, unless something changed in their design since we started using them

[Praneethsvch]

Confirming that the Serial read using Trigger mode from the latest branch is giving filtered output. The resolution drops from 1 mm to 1 cm and the readings end with 2.

Observations after testing:

• Picked a random sensor and with every combination of VEXT and Serial read using Trigger mode, the output is same 1 cm resolution with 2 at the end. The same is observed with every sensor in the field, readings end with 2.
• The same sensor when rewired and operated without Serial pin, using Pulse width mode, the resolution is back to 1 mm (the first deployments are with this configuration).

[Praneethsvch]

while loop at:

flood-sensor/firmware/src/maxbotix.cpp

Line 49 in 020fa2d

while (index < 3)

was only reading in 3 characters. As this logic has been overlooked, now that it is solved by changing it to 4, the drop in resolution is ruled out

[Praneethsvch]

fixed a1d7071