Go Down

Topic: Using HCSR 04 for communication (Read 1 time) previous topic - next topic

NPB777

HCSR 04 is a distance measuring Ultrasound Module. Can we use that for communication by interfacing to an  Arduino at both receiver and transmitter side? If yes how?

With regards


AWOL

Probably, but not at very high data rates.
Maybe ten or twenty bits per second.

NPB777

Hi AOWL

If I have a temperature sensor interfaced to Arduino, can I send measured data?
Anyway measured sensing data is very small, so can we?

AWOL

How long have you got to complete your project?

Johnny010

Hi AOWL

If I have a temperature sensor interfaced to Arduino, can I send measured data?
Anyway measured sensing data is very small, so can we?
Yes.

Why the HC-SR04? Is there a reason you can not just use some transducers and make your own circuits?

You can make a basic oscillator to drive the transducer at the 40KHz...
Use a 40Khz Crystal oscillator circuit. This will pulse the transducer, causing it to make a sound.

You can then send data by simply using a fast switching transistor to turn the transducer on and off.

Data can be sent via an arduino pin to the transistor...in binary using shiftout()

A checksum and a pre-amble sequence may be things you need to look in to. Check out "Manchester Encoding".

Johnny010

#5
Apr 01, 2016, 02:30 pm Last Edit: Apr 01, 2016, 02:33 pm by Johnny010
Just had a look myself out of interest, but an Astable 555 circuit will produce 40KHz with 100ohm resistors and a 170nF capacitor.


http://www.daycounter.com/Calculators/NE555-Calculator.phtml

Use that maybe?

I am a noob...so if anything I am saying is really dumb, then someone please intervene :P.

EDIT 2:
Looks like someone got there first:
http://www.gadgetronicx.com/ultrasonic-transmitter-circuit-ic555/

MrMark

Without modifying the HC-04 it would be very difficult because you would have to develop a scheme that first synchronizes the two communicating nodes.  The reason is that the HC-04 works by emitting a pulse and only then listening for a return, thus it isn't normally listening for arbitrary transmissions.

From the schematic linked below, it seems like it would be possible to tap into the HC-04 "Signal" net and directly detect any received transmission.  Then one would have to develop some protocol (OOK, PPM, etc) for message exchange.  It's kind of an interesting possibility though the practical value vs RF communications isn't obvious to me.  Maybe underwater comms?


http://i.stack.imgur.com/ZneOW.jpg

MrMark

For what it's worth, this topic piqued my interest enough to spend a few hours exploring it.

Based on information here (http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html)  I modified a pair of HC-SR04 devices by removing the microcontroller from the transmit device adding wires to directly control "TX1", "TX2", and "HVoff" and the receive device to add a wire to directly read "Signal".  My HC-SR04 had a somewhat different component layout from that pictured in the link, but the signals at U1 were the same.

Ultimately I was able to demonstrate reliable detection of a sequence of transmit bursts over a distance of a couple meters inside my workshop before it became unreliable.

I tried a couple approaches to FSK signaling, but FSK only worked over very short distances.  I believe this is because the receive transducer is sharply resonant at a particular frequency so it essentially output that frequency (after detection) unless driven by a very strong input signal.  The practical result is that one is limited to OOK or PPM signaling schemes.

The other discovery, which is probably obvious in retrospect, is that the receive sensor sees a lot of echoes so a nominal 200 microsecond transmit burst results in a detection burst that may last several milliseconds.  This duration is probably highly dependent upon the environment (a modest-sized room in this case) but the net result is that one has to wait for a burst to die down before transmitting the next.  Thus signaling rate is limited to something on the order of 100 bits per second.

"Signal" is nominally a binary 40 kHz burst so my symbol detection logic (eventually) was simply to look for some small number of cycles with about the right period.  This rejected most noise events and was sufficient to detect FSK at very short ranges.

If someone else were to pursue this, the modification to the transmit device is probably unnecessary to start. The standard device produces an 8 cycle 40 kHz burst (200 microseconds) and I didn't find the ability to produce longer or different frequency bursts particularly helpful for this application.

Go Up