Allow for configurable trigger width

[gordee78]

Is it possible to provide a configuration option to allow for a configurable trigger width?

I'm asking because I've ordered a bunch of JSN-SR04T rev 2.0 boards (which are prevalent in the market) which appear to require a >20uS Trigger pulse as opposed to the default >10uS pulse originally required. This is especially true of many of the waterproof sensors.

This link has multiple models which could benefit from longer TRIG pulse.

Due to the humidity in the sump pit I was finding that the standard stereo HC-SR04 sensors would fail every 2years or so, even with PCB conformal coating. The failure appears to be in the exposed sensor transducer itself.

[alaudet]

The sensor code is provided by hcsr04sensor. I am not sure what you mean by configurable trigger width. The way it works now is that the sensor code takes 11 readings and returns the median reading. The time between each of those readings can be adjusted, is that what you mean by trigger witdth. Consider the two following readings.

default settings

pi@BasementPump:~ $ hcsr04.py -t 17 -e 27  (uses a speed of 0.1ms)
trig pin = gpio 17
echo pin = gpio 27
speed = 0.1
samples = 11

The imperial distance is 11.0 inches.
The metric distance is 27.9 centimetres.

Slower settings (with .3 ms speed)

pi@BasementPump:~ $ hcsr04.py -t 17 -e 27 -sp 0.3
trig pin = gpio 17
echo pin = gpio 27
speed = 0.3
samples = 11

The imperial distance is 11.0 inches.
The metric distance is 27.9 centimetres.

In the Raspisump code I pass a sample speed of 0.3. That is totally adjustable and can be modified if you need that.

[gordee78]

Hi Al - when I refer to trigger width, I'm referring to the width of the pulse that is sent to the JSN sensor module for each individual reading. My understanding is that the trigger pulse starts the measurement process where the ultrasound transducer begins to send it's 40kHz square wave pulses out, and then the "ECHO" pulse width is measured by the hcsr04 module to determine the actual distance.

I believe I'm talking about sensor.py -- line number 87. I'm not a python guy, but I believe this is where trig_pin is asserted, (trigger width sleep time), and then de-asserted. And changing here, would increase trigger width for say all 11 measurements, which are the inputs to the median function reporting.

[alaudet]

Do you mean line 78?

time.sleep(0.00001)

you could always test it by changing it to 0.00002 directly in the module to see if it helps. Let me know if it does and I can look at adding an option. I have no way to test.

What behaviour of readings are you getting as is?

I would need to modify the code in hcsr04sensor and then provide the option in raspisump to add the width as a configurable item.

[gordee78]

Yes sorry I meant line 78. Yes I've already started experimenting with this, but the increase pulse width is not helping at this point (despite many web readings indicating this should help). In general this particular module I have (JSN-SR04T v2.0 hardware) seems to have hardware precision issues (ie repeatability is an issue, spurious min/max readings).

The readings I'm receiving are all 0.0 (this is the median read-back from sensor.py).

The more I read -- even STANDARD stereo ultrasonic sensors (ie HC-SR04) only specify "minimum" TRIG pulse of 10uS, so changing this within the sensor.py directly may not be a bad solution and this should work for all modules. But that's getting ahead of ourselves. I'll need the weekend to debug this further to see if there is any merit to this TRIG pulse increase request.

[alaudet]

Ok keep me posted. Can you try using the hcsr04.py utility which should be installed on your pi? The way I did further up. Raspi-sump error corrects negative values to 0. I want to see what the actual reading is and I bet those 0 readings are something like -10000 .

If you are up to it we could share a desktop over discord to troubleshoot. Would be happy to do that with you so you can get those sensors working right.

[alaudet]

I was looking at that link and there is a part there that discussed R27 to change the mode to be compatible with HR-04 (I assume they mean HCSR04. Might be worth reading the documentation on that board. Looks like R27 can be soldered.

---

EDIT

Nevermind all that. The documentation suggests otherwise. Could still be worth reading this.

Manual

[gordee78]

Yes R27 is a configurable population -- but I think we want it open in our situation (use of TRIG and ECHO).

Thanks for the nudge to user the hcsr04.py utility which gives me more visibility. Raspisump was returning 0.0 all the time, and it's clear as to why. It appears as though the sensor.py mod (line 78 == time.sleep(0.00002) ) seems to be working (both for rev 2.0 JSN-SR04, and for the more reliable rev 3.0 JSN-SR04 modules).

Turns out when obstruction is too close the Rev 2.0 modules report:

pi@raspberrypi:~/raspi-sump/csv $ hcsr04.py -t 17 -e 22 -sp 0.3
trig pin = gpio 17
echo pin = gpio 22
speed = 0.3
samples = 11

The imperial distance is 405.7 inches.
The metric distance is 1029.8 centimetres.

Anecdotally I can tell you the Rev 2.0 sensor is more "finnicky" in that when obstruction or distance is close to or less than 25cm, it will report very large distances (50cm, 150cm etc) much more easily. So it appears as though the sensor is sensitive to TRIG echos and will report erroneous measurements more easily. This explains why ultimate measurement by RaspiSump is more often 0.0 (since my sump pit dept to sensor is ~50cm).

Compare this to Rev 3.0 modules (With an obstruction 5cm away) which report (The metric distance varies ~+/-2cm -- but all results are essentially the same, it reports back with minimum read distance as per the sensor datasheets. This is the main downside of the single sensor JSN-SR04 sensors in that their minimum read distance is ~20-25cm):

pi@raspberrypi:~/raspi-sump/csv $ hcsr04.py -t 17 -e 22 -sp 0.3
trig pin = gpio 17
echo pin = gpio 22
speed = 0.3
samples = 11

The imperial distance is 9.0 inches.
The metric distance is 22.8 centimetres.

Given this behaviour it explains why RaspiSump reports 0.0 for any erroneous (objects too close) readings from the 2.0 sensor. I'm now back to fiddling with the TRIG pulse width, and I can report that BOTH sensors work well with both a 10uS, and 20uS pulse width. There ARE sensors in the original request which could benefit from a wider TRIG pulse -- but I don't possess them now so I cannot test them.

So based on all of this, I think we can close this request because the increased TRIG pulse doesn't appear have a direct effect on the sensor behaviour (both 2.0 and 3.0 hardware) so there is no reason to implement this feature for now.

[alaudet]

Right, I was aware that the JSN was unreliable at shorter distances. Is that what the issue was finally? I had that issue in the FAQ for some time.

https://www.linuxnorth.org/raspi-sump/faq.html#7t

[gordee78]

Hi Al,

So it’s related — but it wasn’t the issue at the root cause. I was aware the JSN module has much large “min” sense distance.

The FAQ applies to both HW rev 2 and 3 JSN-SR04 modules.

But the distinction comes down to the behaviour of the rev 2.0 hardware — it’s behaviour is different from the original HCSR04 and the other version did the JSN-Sr04 in that when an object is less than the specification - ie less than 20Cm, it operates erratically by returning very high distances (100, or 1000+ cm). The other hardware reports the minimum (ie 20Cm). So the raspisump math “works” with the other versions of hardware ….. while rev 2.0 returns 0.0.

I had hoped that the wider trigger pulse would clear this up or improve the behaviour but it appears not.

Thanks for your help!

Sent from my iPhone

On Jul 18, 2021, at 2:58 PM, Al Audet @.***> wrote:

 Right, I was aware that the JSN was unreliable at shorter distances. Is that what the issue was finally? I had that issue in the FAQ for some time.

https://www.linuxnorth.org/raspi-sump/faq.html#7t

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.