I'm in need of transmitting simple digital data(basically error codes) from some mobile devices up to a few hundred feet(lets say about 500ft max). The speed can be extremely slow as the error codes would be quite small(just a few bits). There will be multiple devices sending signals but at a very slow rate. Basically the devices will send error signals(one being a "no error") and are not critical. Probably something along of several mins per transmit.
Main thing I'm interested in is something very simple. What I'm more interested at is knowing what is a good frequency to use. How does one actually go about using something that isn't going to interfer with other wireless devices?
You might consider trying to use radio controlled car or airplane frequencies. You are not likely to cause too much mischief if you play around in one of these frequencies.
formatting link
I think there is stuff in the 47 MHz frequency band too.
These guys might have something right up your alley:
formatting link
Assuming you wanted unlicensed operation, there are actually surprisingly few frequencies to choose from to begin with. (And it varies by country, as you'd probably expect.) I don't personally have enough experience in the unlicensed bands to be able to comment on which are the most interference-free.
If you do use one of those modules from Linx (or similar), check to see if the module itself has a bandpass filter on-board -- many of them don't, and so depending on the IF used internally, unless you add your own bandpass filter you may find yourself getting an image response from a band that has many high-power transmitters blaring (also depends on how wideband your antenna is).
Yeah, I came across that page when I was looking. I have to spend a
How would I handle interferences from other devices that I have? Do I have to set every one up on a different frequency or can I have some type of very simple arbitration? My idea was to have a key sent, an id number, the error code, and a checksum. (maybe repeat the checksum and key at both ends) I can then simply have the different devices transmit in somewhat random intervals(say every 5 to 20 minutes) so that the likelyhood of two sending at the same time is pretty low. When two do transmit at the same time I would probably just get garbage and can ignore.
Not sure if that is a good way though as it is still possible to get a good signal if both transmit exactly at the same time. I guess I could encode the bit string with the id number and then decode by simply trying all the various codes(only about 10-20 so no big deal) and check against it's checksum(or better yet a CRC).
Since those are transcievers I probably could use some call/response which would solve all those problems. (the only problem really is that the devices may be off for a substantial amount of time and so I would have to look at some battery operation which might be more of a hassle than I want)
Assuming you don't have too many devices out there (so that there aren't too many collisions), this approach works fine -- each one transmits at a slightly different time, and if they collide... well, too bad, you'll get your data on the next go around.
I would suggest sitting down and writing up a quick simulation of this sort of time-division multiplexing (just creating a "timeline" and having each "transmitter" block out when it's transmitting and checking to see how much overlap there is) -- I recall an article in Circuit Cellar Ink, I think it was, where someone did such a simulation in something like Matlab, and it was somewhat illuminating to see the plots of the number of successful transmissions (i.e., no transmitters power up at the same time) vs. the number of transmitter out there.
Using different frequencies is has various pros and cons... on the plus side, at least in theory you don't have to worry about collisions with other transmitters, but on the minus side, to actually make that work if you only have one receiver if you have one strong (nearby) transmitter it will still "desense" the receiver from hearing weaker (further away) transmitters, so you need to insure you have enough dynamic range to account for this. Additionally you need to find out just how closely spaced your frequencies can be before one starts to interfere a little with another. Whlie this frequency-domain multiplexing approach is quite doable (and it is more of the "traditional" approach), the scalability (or lack thereof) of such a system isn't quite as obvious as it is with the TDM.
Hence, if you have few enough transmitters to get away with TDM, I'd suggest trying that first.
Definitely use some form of a checksum... the nature of RF transmissions is that you have to expect bits will be corrupted on a pretty regular basis. Even with a "good quality" signal, you can expect to see a bit every few hundred to few thousand to become corrupted.
Right. One way to help with the battery problem is that you have each transceiver just "wake up" on a known schedule to listen for your main transmitter to ask it to transmit and to synchronize with the master clock. Since over the span of some hours or days your microcontroller's clock won't drift by more than a second or so, you only lose a little bit of extra battery life by operating the receiver for a slightly larger window than would be necessary if all the clocks remained in perfect sync.
If your transmitters only need to operate in the field for, say, weeks at a time, if you're careful with your clock design, you might be able to guarantee that there won't be more than a few seconds drift and keep everything on a rigid schedule (with a few seconds of slack around each transmission period), and then you're back to only needing transmitters rather than transceivers.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Question for the group - one way I might do something like this is to throw a cheap wireless router pair (plus cantenna or whatever else is good) with a couple of terminal servers and Black Box boxes ( if needed ) to knock the data back to whatever it needs to be on the target. If there's USB, even better.
I'm a bit new here, and I realize that may be far too "McGyver" and COTS an approach for this audience.
Is this a true statement? Obviously, it's far too much bandwidth, but it's quick and, in terms of NRE, cheap.
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.