JSN-SR04T (distance sensor) Reliability Issue Fix?
-
Thanks for the comments guys.. My application is very different than water level sensing though. I'm using it as a "people-distance" sensor (detecting distance to people's torsos) and our 3D printed case has a hand adjustable angle mount that works well for us:
The PROBLEM (for me) is that while the JSN sensor works well against flat, hard, smooth surfaces like plywood or a liquid surface (did all my testing of this on the bench), they seem to be much less reliable with soft surfaces like a clothed torso, a coat on a hangar, a pillow, etc. This soft-surface error appears in the output as distance pulse "jitter" as seen here in the signal pulse width output jumping around:
Thus far I'm solving this specific issue in software with a rapid detection loop that throws away known "bad values" (as previously discussed) with a watch-dog loop-break that limit its detection polling duration.
I hope that's clear enough.
It sounds like the JSN is a perfect sensor for detecting walls (from a car bumper) or other hard/fault car surfaces (<20ft proximity.. maybe along with radar).. and I know most people following these threads seem to be using it for liquid-level measurements (which is really cool).. but one is pushing the JSN's usability with soft target objects.
If anyone comes up with a better, more elegant solution for making this sensor more universal in its target detection.. even if done at the sensor hardware or STM micocontroller reflashing side of things.
Cheers..
TWeeks
For anyone interested in this.. I found that ultrasonic sensors, while accurate on solid surfaces.. detecting distance of "soft" objects like torsos with clothing in front of it can create "ghosting", or massive jitter (at best) at certain distances and angles. This can be seen in the o-scope image above. As soon as I put a piece of plywood on my chest, the signal is rock solid. So yes, tracking the depth of water (a solid, mostly smooth surface) works great.. detecting people walking and distances reliably is problematic. Some of it can be lessened via software filtering, but not all.
For those looking for a soft-body distance measurements.. this IR LIDAR TOF sensor works VERY well.. is sub-CM accurate(!!) and is sunlight resistant, and quick as hell.
Link -
https://www.aliexpress.com/item/1005001643925191.htmlplus.. it's TINY!
T.Weeks
-
For anyone interested in this.. I found that ultrasonic sensors, while accurate on solid surfaces.. detecting distance of "soft" objects like torsos with clothing in front of it can create "ghosting", or massive jitter (at best) at certain distances and angles. This can be seen in the o-scope image above. As soon as I put a piece of plywood on my chest, the signal is rock solid. So yes, tracking the depth of water (a solid, mostly smooth surface) works great.. detecting people walking and distances reliably is problematic. Some of it can be lessened via software filtering, but not all.
For those looking for a soft-body distance measurements.. this IR LIDAR TOF sensor works VERY well.. is sub-CM accurate(!!) and is sunlight resistant, and quick as hell.
Link -
https://www.aliexpress.com/item/1005001643925191.htmlplus.. it's TINY!
T.Weeks
@Thomas-Weeks , in your scenario do you have to deal with condensation (water vapor moisture) on sensor head? I replaced my ultrassonic SN04T by a time-of-flight VL5310X , but still getting many erratic readings when drips form on sensor face...
Home Assistant / Vera Plus UI7
ESP8266 GW + mySensors 2.3.2
Alexa / Google Home -
@Thomas-Weeks , in your scenario do you have to deal with condensation (water vapor moisture) on sensor head? I replaced my ultrassonic SN04T by a time-of-flight VL5310X , but still getting many erratic readings when drips form on sensor face...
@rvendrame Again.. I'm not measuring water.. I'm measuring people in a climate controlled environment. No problems with condensation. But I can see how condensation would wreak havoc on an IR laser TOF sensor. Why did you have to move away from the JSN04T? It seems pretty solid candidate for your application.
Tweeks
-
@rvendrame Again.. I'm not measuring water.. I'm measuring people in a climate controlled environment. No problems with condensation. But I can see how condensation would wreak havoc on an IR laser TOF sensor. Why did you have to move away from the JSN04T? It seems pretty solid candidate for your application.
Tweeks
@Thomas-Weeks I'm looking for alternatives, as I started with JSN04T. Scope is to measure house's water tank (2000 litres). The sensor is fixed at a hole in the tank cover (on top).
The tank stays at roof. Once sun in at its peak, a lot of vapor and condesantion appears in the tank, and the sensor face gets completely covered by water drops. Both JSN04T and VL5310X then start to give very out-of-range readings. (and this happens almost every day, for multiple hours).
Home Assistant / Vera Plus UI7
ESP8266 GW + mySensors 2.3.2
Alexa / Google Home -
@Thomas-Weeks I'm looking for alternatives, as I started with JSN04T. Scope is to measure house's water tank (2000 litres). The sensor is fixed at a hole in the tank cover (on top).
The tank stays at roof. Once sun in at its peak, a lot of vapor and condesantion appears in the tank, and the sensor face gets completely covered by water drops. Both JSN04T and VL5310X then start to give very out-of-range readings. (and this happens almost every day, for multiple hours).
@rvendrame Timely - I haven't put it into operation yet as only just finished the plumbing mods in the pump well for a 5psi water pressure sensor. Because I've saddled the sensor to the pump suction line I'll have to inhibit readings when the pump runs, hence delayed operation.
5psi is equivalent to 3.516m head, so you will measure over 80% of the ADC range giving a resolution of 4.25mm..
My 3,000 litre underground water tank suffers the same issue over condensation when winters drop below -5.
Hope this helps.
-
For those interested..
I found another engineer who reverse engineered the JSN-SR04T v2. Not identical, but close. Here's the v2 schematic:
Here's the full theory of operation article he wrote (in Vietnamese, google xlate URL) on how to remove the STM 8 bit microcontroller and do your own echo-pulse based on the waveshape of the detection LED driver.
Here's an interesting tidbit of implementation info that's good to know before you try to use this sensor in a project:
"Defect:
-
JSN-SR04T has a very large opening angle (> = 75 degrees), so it is NOT suitable for measuring distances in tight spaces. Should only be used in open spaces such as outdoors or large-size tanks - no obstructions .
-
If measured in a confined space, the error is very large due to the reflected wave being impacted and the object or the tank - tank wall."
Good to know!... I have seen some of this error in the form of echo width "jitter" both in the bad/unreliable data, as well as with the raw signal combing back on the o-scope:
I'll need to experiment with this in confined spaces.. but the JSN units also seems to have problems with "soft targets" (like people in clothes). You can test this yourself by testing with a plywood sheet (the size of a person) vs a clothed person. If anyone finds a way to get more reliable soft target detection, please share here.
These JSN-SR04 modules seem to have multiple operating modes.
On the v2 module, the empty R27 pad controls the echo mode of operation. Here's a best guess regarding the four "operating modes" that I think the author is documenting (attempted to better translate from Vietnamese):
1. Trigger/Echo ECHO-Pulse Mode (default): (R27 open)
You send a 10uS pulse on Trigger pin, then 8 x 40KHz pulses are sent out of sensor, if bounce signal returns within 60mS, the duration of the time to return is sent as pulse-width based on the formula:
Distance = (high time * speed of sound (340M / s)) / 22. Continuous Distance-Data TX Mode: (R27=47k)
In this working mode, every 100ms will automatically output the measured sensor distance value, in millimeters. Once the module is powered on, it operates in mode 2 immediately, and data will be sent every 100 ms via echo (TX) pins. The data sent includes: 0xFF + H_DATA + L_DATA + SUM. Breakdown:- 0xFF: Byte signaling to start sending data.
- H_Data: 8 bits above of the distance.
- L_Data: 8 bits below the distance.
- SUM: Byte checks whether the passed data is correct or not.
- SUM = 0xFF + H_DATA + L_DATA (H+L = 16bits which represents distances in millimeters.) (assume 9600, n, 8, 1 data on echo pin)
For example, the sensor sends FF 07 A1 A7 Sum = A7 = (0x07 + 0xA1 + 0xFF) & 0x00FF. 0x07 is the upper 8 bits of the distance. 0xA1 is the lower 8 bits of the distance. The distance value is 0x07A1, converted to 1953mm in decimal3 . Standby Distance-Data TX Mode: (R27=120k)
Same as mode2, but module starts in a disabled, standby mode, waiting for a 0x55 command (on trigger pin, as 9600, n, 8, 1), after which module runs same as mode-2 (continuous distance data TX mode)Well that's all useful info!
Hmm.. No R27 pad on my v3 sensor.. but I wonder what these four jumper pads do :)
If anyone else gets time to play with these new v3 jumpers.. or figure out how to resolve the "jitter issues", please do share here.
T.Weeks
@Thomas-Weeks please tell me what type of signal i generate for the PB5 pin ? and how to replace the inbuilt stm8 to ESP32 microcontroller
-
-
I'll open this up again. I've just received some JSN-SR04T V3.0 and was having similar issues to those described here. Using PlatformIO and the Arduino framework and a simple code that did the 10us pulse and measured the time of the return pulse.
The top trace is just a line toggle as the code goes around the loop. The second trace is the echo and the bottom the trigger pulse. You can see that multiple triggers don't get a return echo. Using the function pulseIn() it times out after a second and we go around the loop again.
Using pulseInLong, that also defaults to a 1sec timeout but making the timeout 10000 ensure the code doesn’t hang for longer than necessary. but still, losses plenty of echoes.
Next was increase the trigger to 12us It still gets the occasional lost echo
So next was 20us trigger, very few lost echoes
and 30us trigger, no missing echoes
So for better reliability us a 30us trigger pulse and the pulseInLong() function with a timeout of 10000.
I concluded that the limited datasheet saying the trigger should be 10us really should say greater than 10 us.Hope that helps somebody
Pete
-
I'll open this up again. I've just received some JSN-SR04T V3.0 and was having similar issues to those described here. Using PlatformIO and the Arduino framework and a simple code that did the 10us pulse and measured the time of the return pulse.
The top trace is just a line toggle as the code goes around the loop. The second trace is the echo and the bottom the trigger pulse. You can see that multiple triggers don't get a return echo. Using the function pulseIn() it times out after a second and we go around the loop again.
Using pulseInLong, that also defaults to a 1sec timeout but making the timeout 10000 ensure the code doesn’t hang for longer than necessary. but still, losses plenty of echoes.
Next was increase the trigger to 12us It still gets the occasional lost echo
So next was 20us trigger, very few lost echoes
and 30us trigger, no missing echoes
So for better reliability us a 30us trigger pulse and the pulseInLong() function with a timeout of 10000.
I concluded that the limited datasheet saying the trigger should be 10us really should say greater than 10 us.Hope that helps somebody
Pete
@Doubletop Interesting, as this made me check my own program for the V3.0, which finds a typo - I'd set the trigger at 100 instead of 10, but it never failed to get two consecutive readings.
Can you clarify your experiment on this was at 3v or 5v ?I've gone back to try ultrasonics again in the underground tank - The transducer is now installed in a plastic pipe which should solve the condensation issues from the previous metal pipe below -10 blinding the transducer.
The 5v requirement of the V3.0 is met by a pro-mini talking over I2C to the 3v node unless it's running on batteries.One facet of the v3.0 I fell over in setting this up was it's inaccuracy at short range - Measured level 298mm, read level 275mm, from 1m down the error vanished - both devices bought responded identically.
The solution here was to scale the pulseIn for top and bottom for the known volume, and thus far, working reliably. -
@Doubletop Interesting, as this made me check my own program for the V3.0, which finds a typo - I'd set the trigger at 100 instead of 10, but it never failed to get two consecutive readings.
Can you clarify your experiment on this was at 3v or 5v ?I've gone back to try ultrasonics again in the underground tank - The transducer is now installed in a plastic pipe which should solve the condensation issues from the previous metal pipe below -10 blinding the transducer.
The 5v requirement of the V3.0 is met by a pro-mini talking over I2C to the 3v node unless it's running on batteries.One facet of the v3.0 I fell over in setting this up was it's inaccuracy at short range - Measured level 298mm, read level 275mm, from 1m down the error vanished - both devices bought responded identically.
The solution here was to scale the pulseIn for top and bottom for the known volume, and thus far, working reliably.3V from ESP32
The other thing I realised is that zero values from pulseInLong aren't only from no echoes timeouts, they are also from out of range echoes. (obvious now I've written it down).
The conclusion is set the correct trigger time, ignore zero values and use a timeout that is relevant to your own application. if you don't want to read beyond a certain distance timeout and dont hang for up to a second waiting for the default to do it for you.
-
3V from ESP32
The other thing I realised is that zero values from pulseInLong aren't only from no echoes timeouts, they are also from out of range echoes. (obvious now I've written it down).
The conclusion is set the correct trigger time, ignore zero values and use a timeout that is relevant to your own application. if you don't want to read beyond a certain distance timeout and dont hang for up to a second waiting for the default to do it for you.
@Doubletop Thanks for that.
I haven't range limited the readings on this version (ie ignore bad results) but do check for two consecutive readings, thus far no bogus readings recorded.In my own case, the 3v node had no spare pins, so had to expand anyway to avoid using to a second dedicated node.
Having read on the 5v returning stable results, went with a second pro-mini at 5v controlling the v3.0 (also enabling further expansion) running off a PSU, talking I2C to the Node.
My principal problem was winter condensation on the transducer head due to the pipe used, aside that the v2.0 ran two years before finally dying.
This time it's on plastic pipe and the v3.0 is socketed for easy swap should it go faulty, fingers crossed for a trouble free winter.
