Hey all,
First off I want to apologize if this is in the wrong forum. This is a pretty unique project and I didn't really see where else my question might fit. Please move it if necessary.
Essentially what I'm hoping to do is build a cheap device that will transmit a programmable 32 bit integer via inaudible high frequency audio. The device should have a built in speaker capable of playing such a frequency, although it doesn't need to be loud at all. A distance of < 1 foot from the speaker to the receiver (a PC with a microphone) is fine.
So far I have imagined the components consisting of a frequency generator IC, a speaker, a very low-power amplifier (if I even need one?) and—I'm assuming—a microprocessor that can be programmed with the 32 bit integer and control playback of the tones. I need to be able to easily program the 32 bit integer for each device (I'm building multiple), but once I program it it probably won't change.
In hopes of keeping things simple and reliable on the receiver's software, I imagined the transmitter producing a bit-by-bit audio representation of the integer by means of two alternating frequencies. I was thinking of using a third frequency to play in between repetitions of the audio signal.
It should also be noted that my resources are limited, so I'm trying to keep costs low.
I come to you for your knowledge and advice on this project. The solutions mentioned above are just what I came up with as an amateur and I'm open to suggestions regarding the design and execution, so long as the original goal is kept in mind (transmission of an integer). I really appreciate your time.
Thanks in advance,
Bloudermilk
First off I want to apologize if this is in the wrong forum. This is a pretty unique project and I didn't really see where else my question might fit. Please move it if necessary.
Essentially what I'm hoping to do is build a cheap device that will transmit a programmable 32 bit integer via inaudible high frequency audio. The device should have a built in speaker capable of playing such a frequency, although it doesn't need to be loud at all. A distance of < 1 foot from the speaker to the receiver (a PC with a microphone) is fine.
So far I have imagined the components consisting of a frequency generator IC, a speaker, a very low-power amplifier (if I even need one?) and—I'm assuming—a microprocessor that can be programmed with the 32 bit integer and control playback of the tones. I need to be able to easily program the 32 bit integer for each device (I'm building multiple), but once I program it it probably won't change.
In hopes of keeping things simple and reliable on the receiver's software, I imagined the transmitter producing a bit-by-bit audio representation of the integer by means of two alternating frequencies. I was thinking of using a third frequency to play in between repetitions of the audio signal.
It should also be noted that my resources are limited, so I'm trying to keep costs low.
I come to you for your knowledge and advice on this project. The solutions mentioned above are just what I came up with as an amateur and I'm open to suggestions regarding the design and execution, so long as the original goal is kept in mind (transmission of an integer). I really appreciate your time.
Thanks in advance,
Bloudermilk
Hi,
II has basically all been done before in the form of ultrasonic remote controls,
so the parts are out there, but very old, infrared remotes now dominate.
Why you want to use ultrasonic audio over a distance of 1ft is beyond me.
Yourr asking for trouble expecting a PC microphone to do ultrasonics.
Laptops's have Bluetooth (10 metres) and infrared (1m line of site)
for this sort of stuff, though an electret ultrasonic transducer
could be plugged into the microphone input, you would also
need a a high sampling rate (96kHz) (integrated) soundcard.
rgds, sreten.
Your 32bit integer would be represented as four hexadecimal characters
in many audio based encoding schemes, including DTMF, representation
of digital values is not bit by bit in analogue encoding schemes, multiple
bits are encoded in parallel, otherwise it would be far too slow.
II has basically all been done before in the form of ultrasonic remote controls,
so the parts are out there, but very old, infrared remotes now dominate.
Why you want to use ultrasonic audio over a distance of 1ft is beyond me.
Yourr asking for trouble expecting a PC microphone to do ultrasonics.
Laptops's have Bluetooth (10 metres) and infrared (1m line of site)
for this sort of stuff, though an electret ultrasonic transducer
could be plugged into the microphone input, you would also
need a a high sampling rate (96kHz) (integrated) soundcard.
rgds, sreten.
Your 32bit integer would be represented as four hexadecimal characters
in many audio based encoding schemes, including DTMF, representation
of digital values is not bit by bit in analogue encoding schemes, multiple
bits are encoded in parallel, otherwise it would be far too slow.
Last edited:
Sounds interesting...
For starters I think you'd be best off using purpose built piezoelectric transmitters and recievers - they're designed for this kind of thing. As sreten says, you can't really expect a PC to digitise the ultrasound - even a card sampling at 96k might struggle. Much better to do it all in hardware!
My aproach would be to try to use standard UARTs to control the transmission - assuming you can get them to run slowly enough (you'd probably be limited to a few hundred bits per second, maybe slower to begin with). I'd use a simple tone/no tone encoding, with the tramsmitting UART just switching the drive to the transmitter.
On the recieve end (the duificult bit), start by filtering out the frequency you're interested in as tightly as possible. Then rectify, with a bit of smoothing to avoid false triggers due to noise, and detect transitions in level. Detecting the transitions should help mitigate the effects of background noise and varying signal levels; however it might prove a bit tricky so you might have to resort to just looking for a level threshold.
Whichever way, once you've detected the tone (or absence of it), and got back to logic levels, feed that into the revieving UART just the same as if it where any other serial link.
You could have a uC at both ends, or interface the recieving UART directly to the PC (or even use the serial port UART directly?).
Working this way, you can break the problem down into 2 smaller problems:
1) The digital problem, of building an asynchronous serial connection between uC an PC. This should be fairly trivial, but you can verify that this bit works before moving on to;
2) The analogue problem, of turning the logic 1 or 0 into tone, through the air, and then back again to 1 and 0, reliably.
Good luck and let us know how it works out.
For starters I think you'd be best off using purpose built piezoelectric transmitters and recievers - they're designed for this kind of thing. As sreten says, you can't really expect a PC to digitise the ultrasound - even a card sampling at 96k might struggle. Much better to do it all in hardware!
My aproach would be to try to use standard UARTs to control the transmission - assuming you can get them to run slowly enough (you'd probably be limited to a few hundred bits per second, maybe slower to begin with). I'd use a simple tone/no tone encoding, with the tramsmitting UART just switching the drive to the transmitter.
On the recieve end (the duificult bit), start by filtering out the frequency you're interested in as tightly as possible. Then rectify, with a bit of smoothing to avoid false triggers due to noise, and detect transitions in level. Detecting the transitions should help mitigate the effects of background noise and varying signal levels; however it might prove a bit tricky so you might have to resort to just looking for a level threshold.
Whichever way, once you've detected the tone (or absence of it), and got back to logic levels, feed that into the revieving UART just the same as if it where any other serial link.
You could have a uC at both ends, or interface the recieving UART directly to the PC (or even use the serial port UART directly?).
Working this way, you can break the problem down into 2 smaller problems:
1) The digital problem, of building an asynchronous serial connection between uC an PC. This should be fairly trivial, but you can verify that this bit works before moving on to;
2) The analogue problem, of turning the logic 1 or 0 into tone, through the air, and then back again to 1 and 0, reliably.
Good luck and let us know how it works out.
It's fairly trivial to do this. On-off keying and a narrow bandpass filter, 2 UART ICs (probably use a couple of PICs with built-in UARTs). It's just a question of suitable transducers then.
I'd go with a visible light LED (you can make it blink faster than the eye can see) or an infra-red if it must be invisible. Transmit multiple times for redundancy. You can do ultrasonic but the transducers will be more problematic.
Part of the problem is reading the signal into the PC. Serial ports are increasingly uncommon, but if it's a desktop you can put a card in it. This will do away with one of the UARTs. Otherwise you need a USB interface. Either way, some piece of software must respond to the incoming signal. Who's going to write this?
If it's one-time-programming a PIC is ideal in many ways. The frequency control need not be very accurate, so you can use one with a built-in oscillator to generate this. You can program the identity through an ISP header.
If you tell us a bit more...
w
I'd go with a visible light LED (you can make it blink faster than the eye can see) or an infra-red if it must be invisible. Transmit multiple times for redundancy. You can do ultrasonic but the transducers will be more problematic.
Part of the problem is reading the signal into the PC. Serial ports are increasingly uncommon, but if it's a desktop you can put a card in it. This will do away with one of the UARTs. Otherwise you need a USB interface. Either way, some piece of software must respond to the incoming signal. Who's going to write this?
If it's one-time-programming a PIC is ideal in many ways. The frequency control need not be very accurate, so you can use one with a built-in oscillator to generate this. You can program the identity through an ISP header.
If you tell us a bit more...
w
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.