I want to trigger an interrupt in 16 microcontrollers at the same time (+/- 10 microseconds).
The microcontrollers are indoors, within 20 meters of each other.
Is this possible using inexpensive RF parts (Linx, Micrel, RF Monolithics)?
Thanks, Roger
time
That timing is pretty tight.. you might have trouble due to component tolerances.
schreef in bericht news: snipped-for-privacy@o13g2000cwo.googlegroups.com...
You could have the slaves transmit a signal that is transmitted back by the master, and thus figuring out what the delay is, then calibrate the receivers with the measured delays, so that the real trigger fires a software one-shot, and all modules start their routine at exactly the same moment. This can all be done in software, automatically.
If a delay between master and slaves can not be tolerated, your specification is actually a bit more than just "all at the same time", it is in fact "all at the same time with no delay". Give or take a few microseconds.
In that case you need transmitters and receivers with a lot higher bandwidth, like the ones suitable for video. There are cheap 2.4 GHz transmitters/receivers. But false and missed triggers are probably not to be tolerated as well. So I would not recommend that, unless your environment is guarranteed to be free from of all possible noise sources.
Is there really no way to use a cable, or perhaps something optical?
-- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)
As an alternative to RF, you might consider a high-power IR LED and detectors. Driving 10 pulses of 1 uSec should be no problem. Getting detectors that will reject noise and ambient light with reasonable (and matched) phase delays might require a bit of engineering.
Mark Borgerson
Probably, especially if you use a tiny uC to also help with the time-sync. Simplest design would use the fast RSSI output available from some devices. Smarter design would use a RF uC, for keyless entry/remote control ( eg Atmel do some RF+AVRs ). You would send a data frame, and use every edge to improve the time-precision. With a tiny uC, you could also calibrate system delays, on a CAL fixture once.
-jg
Some kind of CW or OOK system, probably in the low AM band for cost reasons, would seem ideal for quick response as well as inexpensive parts. For slightly more money, but slightly better detector sensitivity and noise rejection, an FM/FSK part also be possible.
The theory with CW or OOK being that you simply have the slaves listening for presense of absence of the radio wave. When the master starts transmitting, the RSSI line of the receivers should go high fairly quick. How quick will depend on the low pass filter that the RSSI is subjected to inside the reciver. The radio wave itself travels at what is essentially the speed of light, so over 20m the delay from that will be as close to nothing as you can get.
The only downside I see immediately to this kind of setup is that if there's sufficient stray radio noise in the same band as you're using, the receivers are going to fire falsely. Two ways around that I can think of off the top of my head. One, use a radio band that's rarely used so the chances of accidental interference will be small - and then cross your fingers. Two, modulate the carrier with some sort of unique signal. Downside to this is that then you have to wait not just to hear some signal, you actually have to decode the signal and compare with the correct signal. This takes more time - time that you perhaps do not have.
I looked around and couldn't find a pre-built module that would bring its RSSI high in ~10uS. However, this Maxim receiver chip seems close:
(More info at
Page 3, near the bottom, quotes the maximum data filter bandwidth as 100 kHz, which will means the fastest the data output could go from off to on would be 10 uS. Note, this is an ASK part - it uses how strong the incoming signal is, rather than whether it's there or not. But I didn't hunt very hard, so there may be an OOK/CW part similiar to this somwhere. ASK might be beneficial however - the output would only be high when there's A) signal in the air and B) a data "1" going into the transmitter. However, this option will eat more power. If you're running off batteries it could be enough to matter.
The above nonwithstanding, I would recommend you dig deeper and try and find a prebuilt module that will do almost everything for you, instead of trying to roll your own RF circuitry. RF is tricky business, and all sorts of crazy shit happens that most people versed in only digital logic would never expect or be able to troubleshoot. Unless you have successfully built RF systems before, or have a lot of time on your hands, you're almost always better off letting someone else deal with the difficult parts of RF design.
Like the other posters to this thread, I'm curious... how come you can't run a wire to each uC? Or bette, a twisted pair of wires, RS-485 style. Better noise immunity, lower cost, easier to build. Slightly more hassle to install, but if you're plugging this thing into the wall anyway it ought to be trivial.
-Ben
-- I am Ben Cantrick. I still think the AnimEigo BGC dubs suck. To foil spammers, no e-mail adress will be given here. (Spammers also suck.) If you want to e-mail me, remove any African animals in my e-mail address. Anime: Drugs would be cheaper.
This doesn't seem to guarantee RSSI high in any particular amount of time, but it does do 100k data rates. You could send a byte of data consisting of the bits "00000001". The data line sould go high at the last bit, which in theory ought to be very close to the same time at all receivers.
-Ben
-- I am Ben Cantrick. I still think the AnimEigo BGC dubs suck. To foil spammers, no e-mail adress will be given here. (Spammers also suck.) If you want to e-mail me, remove any African animals in my e-mail address. "I'm not senile, I'm a fanboy." -http://www.goats.com
In practice, it isn't though - either due to temperature variations, or simple ol' component tolerances in the slicers. I spend my time at my day job jumping through various hoops to make realtime protocols work properly over radio links. Nothing is simple.
Wish I could say I was surprised to hear that. But, do you think they'll all fall within 10 uS of each other?
-Ben
-- I am Ben Cantrick. I still think the AnimEigo BGC dubs suck. To foil spammers, no e-mail adress will be given here. (Spammers also suck.) If you want to e-mail me, remove any African animals in my e-mail address. Computers are useless. They can only give you answers.
For microsecond timing, a wide-band signal is needed. The current practice to do it reliably without excessive pulse power, is to use a pseudo-noise signal and a correlator like GPS uses.
However, for many users, this is not more simple.
-- Tauno Voipio tauno voipio (at) iki fi
or
my
work
I've tried to translate a wired protocol with 25ms timing constraints in it, and failed to get it to work reliably systemwide. The system in question is a 10kHz ASK transceiver using a simple comparator+RC slicer. Part of the problem is that the absolute RSSI voltage out of the receiver IC is not guaranteed; only the relative value (vs. two input signals "n" dB apart) is characterized - this causes a noticeable batchwise variance. I haven't really analyzed what was going on in great detail, because I had to try to get it to work with existing designs and components - since that was impossible, other methods had to be chosen.
Thus, you would need a baseband signal with a rise time less than 20 us. This would require about 15 kHz baseband bandwidth. If an RF carrier is gated with this kind of baseband signal, this is basically amplitude modulation, producing two sidebands and occupying a 30 kHz bandwidth. The receiver filters should be wider than this to allow for any frequency errors in the transmitter and each individual receiver.
Getting a legal unused channel that wide might be a problem.
Paul
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.