Page 1 of 1

Ultrasound/ultrasonic data transfer

Posted: Sun Feb 16, 2014 10:04 pm
by smooth_jamie
Hi All,

Is it possible to communicate underwater via ultrasound with a raspberry pi? I am not interested in receiving data just sending it as commands to the pi. I have tried 'quietnet' but I am having trouble installing it. There is very limited information about communicating via ultrasound online (most articles are concerned with rangefinding which is not what I am after), can anyone offer any insights as to how I might be able to achieve this on the Rpi?

Kind Regards,
smooth_jamie

Re: Ultrasound/ultrasonic data transfer

Posted: Sun Feb 16, 2014 10:38 pm
by chrisryall
Should be very similar to radio, AM or FM possible, Digital is doable (not read that up). Range at MHz frequencies isn't good (tens of cm) so you may be stuck with kHz and consequently less bandwidth. Water is a pretty good conductor, though not as good as solids. "Aerials" are more complex, you need 1/4 wave plates and things to match impedancies. "Beaming" is quite straightforward mechanically, harder if you use phased arrays. Similar to radio/radar, side bands etc.

not sure how to link that to the Pi, but there are some good FM threads here, the little fellas clock frequency looks favourable, but I think you should seek to do modulation "electronically"? The medical ultrasound people cracked a lot of this 25 years back, there should be specialists chips, but they may be "proprietory" don't know.

You need to get the waterproofing right!

Re: Ultrasound/ultrasonic data transfer

Posted: Sun Feb 16, 2014 10:39 pm
by FLYFISH TECHNOLOGIES
Hi,
smooth_jamie wrote:Is it possible to communicate underwater via ultrasound with a raspberry pi?
Generally speaking yes.
You should not expect fast communication... my pure guess is that the speed would ideally be something like 2400 baud on shorter distances and less if you'd like to communicate at a distance over 20m or so... (don't get these numbers very seriously, this is just my feeling). The reliability (and consequently speed) killers are echoes.
smooth_jamie wrote:I am not interested in receiving data just sending it as commands to the pi.
It could be advantageous if you receive acknowledges.
smooth_jamie wrote:can anyone offer any insights as to how I might be able to achieve this on the Rpi?
You're underlining "RasPi" too much... The easy part is to adjust/interface this circuit designed for any other digital board.
You should avoid ultrasonic modules (although a pair could be used for a _very_ low speed communication, I'd guess that the upper limit is something like 1 baud or even less).

To summarize: search for the same circuits designed for other digital devices (the easy way) or get & modify ultrasonic circuit containing discrete components (advanced knowledge required).


Best wishes, Ivan Zilic.

Re: Ultrasound/ultrasonic data transfer

Posted: Sat Feb 22, 2014 11:26 am
by smooth_jamie
Hi Everyone,

Thanks for the input. I've looked for the little fellas clock frequency thread on the forums and I can't find it, so I'd appreciate if someone could post the link so I can see if it helps with my research.

It might be simpler using the following method. As I understand it, I could send 'raw' RS232 pulses through a piezo driver (or speaker of some kind) and translate them into commands at the controller?

Re: Ultrasound/ultrasonic data transfer

Posted: Sat Feb 22, 2014 12:41 pm
by FLYFISH TECHNOLOGIES
Hi,
smooth_jamie wrote:As I understand it, I could send 'raw' RS232 pulses through a piezo driver (or speaker of some kind) and translate them into commands at the controller?
I don't think you can get any usable result without data modulation. Raw pulses approach might give some limited success - short distance, direct pointing one side to the another, static positions, etc., but this would rather be a result of pure luck instead of a proper design.

With this kind of questions I always have issues how to compose the answer... there are so much things to point to, that it is actually a two-stages problem - the first to explain what are all the issues (I'm afraid that at this point we' re not on the same page) and then to discuss about issue items one by one.

Anyway, let's start with this one: what is expected speed of this link ?


Best wishes, Ivan Zilic.

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 11:09 am
by smooth_jamie
Hi There,

I'll just point out that I am a still a novice and my understanding of signal processing in particular is limited to level 3/4, I know this is sometimes frustrating but I'm here to learn and I hope someone has the patients to offer advice :)

I'm not concerned with the speed of the link, I'm only interested in one way communication from the user to the controller (computer sends a signal, controller receives and responds). I think a 4bit signal will be enough since I want the numbers to represent depth in relation to pressure (in kPa) and this will potentially allow me to represent 256 different depths. The signal would have some sort of 'start' pulse to ask the module to listen, a payload, and a 'stop' pulse to indicate the end of the pulse train. I haven't considered exactly what frequency to use indicate a '0' or '1' but I think the carrier will be in the range of 20kHz.

Also I've been doing some further reading and as FLYFISH pointed out raw pulses aren't an option without modulation so I've accepted that fact and I've been looking at AM and FM. I imagine AM is easier to write a demodulation program in python than FM, although the amplitude may reduce over distance, while FM is more difficult as it requires python to time the spaces between the cycles. I've read that I can use interrupts on GPIO to do this.

So, based on some new understanding how would I go about writing a program in python to output a binary pulse on an FM acoustic signal from say a laptop, and a program running on the Pi to receive, and demodulate, that signal (I have already written a program to do something on receipt of a binary input).

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 11:43 am
by FLYFISH TECHNOLOGIES
Hi,
smooth_jamie wrote:I think a 4bit signal will be enough... 256 different depths.
You need 8 bits (+ redundancy).
smooth_jamie wrote:I haven't considered exactly what frequency to use indicate a '0' or '1' but I think the carrier will be in the range of 20kHz.
I'd believe that the most widely used is 40kHz. Be aware that the carrier frequency is to be set by elements' characteristics.


My suggestion for your very next steps: compose basic transmitter and receiver (their analog front end) and use any measurement device (oscilloscope) to observe what is actually going on during simple carrier on/off bursts. Afterwards, your perspective to this task will be dramatically different.


Best wishes, Ivan Zilic.

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 12:23 pm
by PiGraham
There's a lot to think about here.

1. Waterproof transducers. What are you going to use to vibrate the water?
Maybe you could use something like a pair of these (just the transducer bit)?
http://www.ebay.co.uk/itm/100M-Portable ... 19d665ec80

This might help:
http://en.wikipedia.org/wiki/Underwater_acoustics

You need to decide what transmission range you need. Short range (cm rather than m) is going to be much easier than long range.

You could use RS232 to modulate a carrier, just gating an oscillator, or a PWM output, but I doubt you will get much range from that.
At the reciever you could consider a bandpass filter tuned to the carrier frequency. Rectify and smooth the filter output and feed it into a GPIO (perhaps a serial Rx pin).

You will probably need a long preamble rather than RS232 start bit.

It might be worth looking at the 433MHz radio remote stuff. That's a noisy channel with a slow data rate. The fact that the carrier is much higher frequency doesn't matter to the data comms side.

You will certainly need to send more than just 8 data bits (for 256 levels). You will need some message identifier and error detection.

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 1:09 pm
by smooth_jamie
Hi PiGraham,
Yep alot to think about, I obviously got my maths very wrong there too :oops: ! Your reply was really helpful thank you, at least I have some options to investigate. The distance the transmission needs to travel doesn't need to travel more than 1m at most since I only really need to prove the principle (even if it is a few cm's).

The signal doesn't catagorically have to be ultrasonic. Could I simply lower the frequency to increase the signal distance, since low frequencies travel further? Also in terms of a 'long pre-amble' what should I use? Perhaps a single puretone lasting a few hundred milliseconds? I'm going to do some more research then I will probably post back with more annoying questions :lol:

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 1:23 pm
by Ravenous
Low frequency poses another problem: your transmitter needs to be physically big to produce it. Look at how big a whale's lungs (or other internal organs) are.

I think PiGraham's suggestion is best, go for some kind of pre-existing underwater gadget, and use it at whatever frequency it's designed for.

By the way I don't know if there are environmental considerations here. Affecting the normal behaviour of fish and other animals, unless you're just testing in a pool or something. I don't think it'll be a problem but it's probably best to at least think of this before you get the animal rights lot onto you!

Re: Ultrasound/ultrasonic data transfer

Posted: Thu Feb 27, 2014 2:37 pm
by PiGraham
The fish detectors should work well for a few metres, since that's what they are designed for.
At such short range it shouldn't be too difficult to get a working link.
I would try generating the carrier with a GPIOpin in PWM mode.
See http://abyz.co.uk/rpi/pigpio/cif.html#g ... Mfrequency

I would use another GPIO output to gate that signal by switching a FET.

It would be easy to experiment with using the Tx line to gate the carrier.
You could easilly move to using another pin.
If simple low baud rate (start with 50baud) UART doesn't work try VirtualWire or similar (usually used with 433MHz radios).

Build a tone detector to detect the presence of your carrier frequency and feed that into your receiver input, either UART Rx or GPIO.
Here, without any endorsement, is an example detector circuit.
http://www.scary-terry.com/more_stuff/t ... onedet.htm

Re: Ultrasound/ultrasonic data transfer

Posted: Sun Mar 16, 2014 10:18 pm
by smooth_jamie
Hi All,

Thanks for all the help so far. I've finished putting together the tone detector which works fine. Now I'm not sure how to properly integrate this into the Pi. I started writing a program to recognise the output of the circuit as 1's and 0's, using GPIO interrupts but not having alot of success. It's already been suggested I use the UART Rx pin for this purpose but not sure how to use those

Can anyone offer any suggestions as to how I can translate the signal into binary?

Re: Ultrasound/ultrasonic data transfer

Posted: Mon Mar 17, 2014 12:02 am
by FLYFISH TECHNOLOGIES
Hi,
smooth_jamie wrote:I've finished putting together the tone detector which works fine.
What is the carrier frequency ?
smooth_jamie wrote:Can anyone offer any suggestions as to how I can translate the signal into binary?
You need some creativity here... The easiest is on-off signaling (OOK) - when the bit is 0, you transmit a tone, when bit is 1, you don't transmit anything.
The important thing is bit-time (baudrate). It must be lower than the carrier frequency, a starting point could be something like 1/20 of it. Maybe this number is quite optimistic (limited mainly by tone detector properties and echoes).

So, when you'd like to send a data packet, you need sent a pattern first (like 01010101, to "warm up" the receiver and to synchronize the receiver clock). Then you need a separator (to distinguish sync sequence and actual data, because first bit or two could be lost), then send data and checksum. Acknowledge/Retry mechanism is recommended.

Ok, let's say that you always transmit 3 data bytes (therefore, no need to add length info), and the data to be transmitted is "ABC" (= 01000001 01000010 01000011), you calculate a checksum (depends on selected algorithm, let's say that the checksum is 11001100 11110011. Let's also say that the separator has 4 bits: 0011
So, you'd transmit 0101010100110100000101000010010000111100110011110011

On the receiver side, you wait for the carrier,... you start receiving 0101.. then you wait for 0011, and next 24 bits are data + 16 bits of checksum... verify checksum and send acknowledge (or be silent in case of error). The sender retransmits the packet if acknowledge is not received within predefined interval... and to prevent dead loop, let's repeat retry max 5 times.

The receiver sampling time should be synchronized with occurrence of the tone, then the sampling is performed at 2/3 of bit-time.


Best wishes, Ivan Zilic.