JSN-SR04T-2.0 needs to have longer high pulse to work reliably

[Jussi Sainio]

Hi,

I have two JSN-SR04T-2.0's with a waterproofed sensor unit that has a long (~2m) cable, bought from eBay in May 2017.

With the stock v1.9.1 (and v1.8) library and NewPingExample example, it returns occasionally a correct measurement, but mostly it returns 0.

When investigating this, I noticed that the sensor didn't make a ticking sound every time it was being triggered.

A datasheet specifies that the trigger pin needs to be given a 10us logic high pulse, but it does not specify how long the pin should be held low. (Datasheet: https://www.jahankitshop.com/getattach.aspx?id=4635&Type=Product)

With experimentation, I found that by increasing the default pin low delay value of 4us to 10us makes this sensor board work reliably with the NewPing library.

In NewPing.cpp (current master), change line 132:

    delayMicroseconds(4);              // Wait for pin to go low.

to

    delayMicroseconds(10);              // Wait for pin to go low.

Same for line 158.

Possibly a better fix could be to have a configurable #define for low/high delay times, if you don't want to increase the delay time for all boards.

I tested the both sensor boards and the code fix on an Arduino Uno clone (AVR, 5V TTL logic levels) also, and observed the same behaviour.

I'm also happy to report that this library (and the fix) works on esp8266 architecture, specifically on a Wemos D1 mini board (3.3V logic levels, just use a voltage divider with 1kohm resistors to 5V and GND for the Tx/Echo pin for JSN-SR04T-2.0 to make a crude level shifter). Currently, the Arduino IDE gives a warning that esp8266 maybe incompatible with this library, but it seems to work well at least with the default settings.

Update:

It seems that with ONE_PIN_ENABLED properly set to false, the pulse high time needs to be increased from 10us to 13us. (lines 136 and 160)

[Tim Eckel]

Have you tried the sensor with the stock NewPing library running on ATmega hardware or just the esp8266? The delayMicroseconds(4) has nothing to do with triggering the ping, it's just changing the port state (which should already be in the correct state). Are you trying to do this using only one pin or the standard two pin method?

[Jussi Sainio]

Thanks for the reply. I used both ATmega/avr and esp8266 hardware, and observed the same behaviour.

You are right, the 4us delay does not make sense as the pin should be low by default.

I'm using the standard two pin method, separate pins for trigger and echo. However, I didn't notice that ONE_PIN_ENABLED is true by default, so the code did a port mode change for the trigger pin. Of course, that is not needed, and my original analysis for the root cause was wrong and my original suggested fix was probably bogus.

I tested changing ONE_PIN_ENABLED to false now, but did not fix the problem alone. I also had to increase the high pulse time to 13us, 'low time' kept at '4us'. Any high pulse length value below 13us produces a lot of spurious zero measurements/missed triggers at least on my Arduino Uno clone. Perhaps using the 10us pulse length spec on these boards is a bit too tight to work reliably.

Both the sensor board and the Uno board do have crystals as their clock source, so their clocks should run relatively stable. I don't have my oscilloscope handy to verify their clock frequencies right now, but in general, it seems a good idea to have few extra microseconds longer high pulse, at least with these JSN-SR04T-2.0 boards.

[Jussi Sainio]

I also have HC-SR04's, the more common ones with two separate ultrasonic probes (separate pulse send and echo receive) soldered to the board. These work well with the original high pulse length of 10us, or the increased pulse length of 13us.

If I drop that to 4us or lower, they start misbehaving in similar manner too, reporting mostly zero measurement and occasionally the correct one. So that also suggests that JSN-SR04T-2.0 just require longer high pulse. (I'll change the bug title to reflect this.)

[Tim Eckel]

The HC-SR04 specs are that the trigger should be high for 10us. But as you noticed (and I as well), it works at about half that. I set it to 10us as that's the spec, and well over (basically double) what's needed.

It seems the JSN-SR04T-2.0 sensor took the HC-SR04 specs at face value and require the full 10us to trigger. Of course, due to slight timing issues, it needs a bit longer to work 100% of the time.

If you're using two pins, setting #define ONE_PIN_ENABLED false is the correct thing to do. It defaults to true because it should work in all cases. But, it's an option due to the possibility of a problem and the code is slightly smaller if you set it to false. It wouldn't hurt to make the 10us pulse an option that can be defined, which is probably the solution for this. Making the default pulse 13us instead of 10us would require consideration. It really sounds like the JSN-SR04T-2.0 is out of spec, and making everyone wait another 3us for one sensor that's out of spec doesn't seem like the right thing to do. But, I'll think about it.