JSN-SR04T (distance sensor) Reliability Issue Fix?
-
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.
