Most ultrasonic distance sensors aren’t waterproof which can be a problem if you need your project to withstand the elements outdoors. No need to worry any more! We have developed waterproof ultrasonic distance sensors with a waterproof sealed emitter. This sensor is suitable for outdoor applications such as car reversing sensors, security alarms, industrial inspection, etc. What will you make?
Unfortunately this product doesn’t have a variant with a longer cable that we have in stock, however with some heat-shrink and some careful stripping and soldering you could likely make a ‘Frankenstein-ed’ extension to the cable to extend its range. Just be sure that you don’t accidentally leave any holes which would remove the sensors weatherproofing.
I’m using 3 of these to measure water tank levels with Arduino UNO. Tanks 1 &2 work OK over very long (100 meter) cable runs. Tank 3 cable run is a little longer (130 meters) but not yet working. I’m getting a constant reading of around 300mm when it should be measuring 800mm. The reading varies when I move the sensor but it isn’t accurate. Any ideas how I might troubleshoot the source of the problem? I already proved the sensor is accurate with shorter cables.
How interesting, if you can, is there any way you can measure the resistance of the cable run? (I totally understand if that’s not possible, over that distance it’d be quite difficult) out of curiousity, when you say the reading isn’t accurate, can you please let us know the readings that you get when it’s actually at 400mm, 600mm, 800mm, and 1000mm if it’s not a linear relationship then we’ve got an interesting problem on our hands as it may not be related to the resistance of the cable. Thanks.
I have experienced some troubles when trying to extend the length of the cable between the sensor circuit board and the probe itself. I was just using fig8 speaker cable (because its what I had plenty of). But continual incorrect readings made me assume that the extension must be made using single core shielded cable.
I ended up instead lengthening the distance between the sensor and the microcontroller using that 4 core telephone cable. That stuff is easy to find and cheap.
I have not had a fiddle with this type of sensor or studied up on how they work. However a number of years ago (a lot) I did sometimes get involved with marine echo sounders. The supplied cable was critical and could not be lengthened or shortened at all as it formed part of the sensor resonance or tuning. If this changed the loading on the transmitter would be all out which could be disastrous in a high power unit. Possible smoke.
It is possible (probable) that these units are entirely different but I thought I would throw this into the mix for something to think about.
According to the Wiki it looks like it sends a signal, so shielding will be essential in maintaining a cleaner wave.
If you are able to open up the cable to test, using an oscilloscope or logic analyser to check that the signal is still making it to various points of the cable. The microcontroller has a cut-off voltage for a “high or true voltage” and it might just be under the required voltage at the cable length of 130m.
If at some point you choose to move away from running wires a LoRaWAN network might be good to wirelessly transmit the data (the Pycom range is currently down on Core’s site at the moment).
It seems there are several people with a similar problem. It also seems that all are trying to increase the cable length from the sensor board to the transducer (another word for the ultrasonic “sensor” unit itself). This cable is 2 wire (refer pic of connector) and must carry the 40kHz excitation signal to the transducer and the echo (40kHz) signal back which is then processed in the sensor board to provide single pulse whose length indicates distance. If this is the case an oscilloscope would be very useful to measure signal levels but a logic analyser really not much use.
It could well be that the extra cable attenuates this 40kHz signal and could be reduced to a level where the transducer can no longer function effectively. This could be the difference between 100 and 130 metres.
It could be a solution to leave the transducer cable as is and move the DFRobot sensor board and extend the 4 connections for Power, Trigger and Echo out to the board. These signals are relatively slow but I would still use 3 twisted pairs. One for Power, one for Trigger and one for Echo. Join the Power Gnd, Trigger pair Gnd and Echo pair Gnd together at both ends. This may seem a bit strange but this technique provides a twisted pair for each function ands minimises problems before they happen.
Note. RS232 used to be quoted as reliable over about 3M or so but using the above technique and low capacitance cable reliable distances of 70M plus can be achieved. So it does work.