I want to have 4 sensors transmitting information to a microcontroller ie
4-bit Encoder -> Transmitter >>>>>>>>>>>> Receiver - > Decoder -> MCU
The problem I have is that if I use 4 transmitters and one receiver it will not be possible to alternatively get data from each sensor because there will be no easy way ( or at least it seems ) to make the transmitters transmit in turns.On the other hand if I use 4 transmitters and 4 receivers the 4 transmitter/receivers will interfere because they will be trying to transmit on at the same frequency and I would also have the problem of having to use 16 I/O ports on just getting sensor data into the MCU.Does anyone have an idea on the best/easiest way to solve this problem?
The problem is similar to this one, except that I want to transmit data from 4 different locations and not only one.
Answer
The suggestions about retries are good ones. With RF generally one can never count upon a clear channel free of noise so that there will always be a finite probability of a missed transmission at the receiver due to interference or noise.
Having the transmitter use of FEC (generally better probability of reception per bit sent) but more complex) and/or unconditional retransmissions (worse than a well designed FEC though good against RF interference that may overpower the channel for longer than a packet duration) allow a unidirectional link a high probability of success. You can also use some kind of unique spreading code such as FHSS DSSS or similar to create CDMA channels for your transmitters such that they will not interfere even if they all transmit at the same time. That can be done in the baseband or at RF carrier frequency.
Use of TDMA techniques is often a simple expedient whereby you assign time slots such as A = 0s...15s, B = 15s...30s, C=30s...45s, D = 45s...60s out of 1 minute (for instance, though of course you can scale the time slot frequency and duration arbitrarily) and use a clock within each transmitter to schedule its periodic transmission windows such that it'll never transmit at the same time as its peers. Going slower e.g. 0...15 minutes etc. out of the hour would work even better. The problem with half duplex scheduled transmissions is clock drift between the transmitters. 10 days is very approximately roundable to 1,000,000 seconds. So a 20ppm clock drift will equal about 20 seconds maximum error over 10 days, so if your devices are to transmit for months on a schedule, you can see that over time their clocks will become off by up to minutes magnitude. Applying first order compensation for measured crystal frequency offsets at the center of the expected operating temperature range will enable to get low single digit PPM clock accuracy in practice with a reasonably accurate and stable 32kHz crystal oscillator timebase. Applying a temperature compensation to the clock rate will help too if your operating temperature drift and range are large enough to warrant it.
Of course if you have bidirectional (RX as well as TX) capability at the nodes you can use packet acknowledgements as well as listen-before-talk synchronication and synchronization / time broadcasts to help the communication succeed.
If you use FDM you'll also be able to have unidirectional transmitters broadcast independently of each other, though some possibility for external interference / noise related errors will still exist.
If you can transmit audio bandwidth baseband you can just use FDM in the baseband by assigning different subcarrier frequencies like 697Hz, 770Hz, 852Hz, 1209Hz to the different transmitters and recovering the information by a DFT or Goertzel resonator bank at the receiver.
You can use common CDMA ICs like car lock / alarm transmitters or garage door openers or similar so that you get the benefit of the CDMA circuitry's interference suppression as well as the inexpensive hardware due to mass production.
If you use a protocol like Bluetooth Low Energy or Zigbee for the communications you'll get the "built in" layers of reliability, error detection/correction, transmission reliability, protocol implementation, modem integration, et. al. They're intended for low energy sensor networks and take all your stated needs into account, and though they're probably excessive for your needs, the benefits of an highly optimized, highly efficient, highly reliable, off the shelf, inexpensive solution sometimes make them attractive for the simplest of needs.
As for there being no easy way to get the transmitters to transmit in turns, well, a small RTC or $0.50 8/16 bit MCU could help a lot there to implement TDM or LBT (listen before talk) or a reliable transmission protocol, but that's up to your implementation. At the least if you're not using FDM you'll probably need to send unique IDs / node serial numbers or unique codes from each otherwise identical node so the receiver knows which 'identical' node the transmission came from. Typically for low power battery powered nodes you'd have to only activate their transmitters at a low duty cycle such that they're saving power most of the time and transmitting only so many times per minute / hour / day / week. If that is the case then coordinating the transmissions may be architecturally not that far removed from the existing scheduling algorithms/circuitry.
The final option I'll mention could involve using directional antennas at the receiver pointed to each node to make it less likely that other nodes or interfering fixed transmitters will cause problems in a given reception. Of course that adds complexity to the receiver setup but can be quite effective depending on one's system design and environment. I'd possibly do this in conjunction with other techniques, not usually instead of them.
No comments:
Post a Comment