Can someone suggest an appropriate product for my needs?
I need to have two separate input devices talking to a third master device. There isn’t any strict need for communication from the master back to the input devices, but it could be a nice thing to have for acknowledgment and retry scenarios.
The devices will be used outdoors, clear line of sight, maximum of 50 feet separation (more like 25).
Ideally, the devices would all be run off of batteries to remove any cords from the project.
Each of the three devices will have a microcontroller to handle the input sensing and message creation and processing.
I’d like to keep the costs as low as possible. I’ve looked at some of the zigbee stuff, but I don’t want to start out at $60 for three modules before adding in any of my other parts.
You will want to turn off the transmitter when not in use to conserve battery power.
You will need to do your own encoding/decoding but it’s not too hard and some one just posted availability of code that sounds like a good fit. viewtopic.php?t=6662 manchester receive and decode is the hardest part.
If the sparkfun modules don’t meet your needs, rentron has a broader offering - http://www.rentron.com/ - including encode/decode chips for really small amounts of data.
To answer your questions, yes, the data volume will be extremely low, and speed is not a factor. Security is also not important.
I had checked out the RF Link products that you linked to. They looked like they’d do the job, but I was concerned as to what would happen if I had two transmitters and one receiver and both transmitters transmitted at the same time? This is probably not a likely scenario, but it’s something I’d like to understand before jumping in and buying parts.
Also, in this situation I’d need two transmitters and only one receiver, so I’d be buying a receiver that I’m not using.
Edit: I now see that Reynolds sells the same transmitters and receivers individually, so I could get exactly what I needed.
that’s easy - use a checksum in your transmission packet (which includes the machine ID, size and data). If the check sum test fails at the receiver, toss the packet. That could have been two transmitting at once or some other interference. keep track of the error rate, if only for debugging.
Now set your transmitters up so they transmit at slightly different periods. so, if they step on each other once, the next one will be ok. make the transmit period long enough so you don’t waste a lot of power (power down in between) but often enough so you can accurately track the phenomena you are measuring.
That’s exactly what I had planned, but the transmission would then be lost.
The transmissions would be human-triggered, so I can’t really enforce the idea of trying to keep the two transmitters from transmitting at the same time. Fortunately, like I said, most of the time the two transmitters wouldn’t be running at the same time, unless people are being idiots.
Basically, I’m building a wireless scoreboard for a number of games (think table tennis), so I want to have buttons at each end to increase each player’s score, and a scoreboard in the middle that displays the current scoring. If a transmission was missed or interfered with, someone could just press the button again. Not the end of the world.
Perhaps the right answer here is going to be to just try to make things work with the simple tx/rx pair, and if that turns out to not work, upgrade to something more sophisticated.
I think you don’t understand RF transmission - you WILL get noise that effects reception. Even if the two devices don’t step on each other, you WILL eventually lose packets. I did a little test with the tx/rx set I pointed out and in my environment, I got about 2% error rate sending packets every 100 mS. That was with just 1 tx and 1 rx.
You need a way to handle these inevitable errors. I’d probably put a sequence number in the packet and transmit a number of times. With sequence numbers, you can detect redundant transmissions. I would also consider transmitting the previous N events in the packet. N determined experimentally. Multiple layers of redundancy will improve the reliability of your system. Think defensive.
Of course, if you used transceivers, you could build a TCP style reliable transmission mechanism. But that adds cost, complexity and current draw. I’m sure you can build a pretty reliable system with out them.
I understand what you’re saying. I hadn’t considered the idea of multiple redundant transmissions. When you said “set your transmitters up so they transmit at slightly different periods,” I incorrectly assumed that you thought I would be having continuous transmissions and was trying to avoid having them transmit at the same time.
I think, for my purposes, sending the same information a few times will be sufficient, and I’ll have each transmitter retransmit on a slightly different relatively prime period to help keep them from talking over each other.
To handle environmental noise, I’ve started looking into different encodings that will help me detect and/or correct errors.
You know, the umirf2s (from those amazing Spark Fun people!)with the nRF24L01s would be perfect. Set up one as a receiver, and set up the two transmitters with different transmit addresses. The receiver has six data “pipes”. Each pipe has a unique address, with a size up to 32 Bytes maximum. When the receiver gets a packet, it acknowledges with an “ack” to the transmitter, an interrupt flag, and the pipe number of the received packet in the status byte. If the transmitter does not get an “ack”, it will retransmit until it does, or let you know there was a failure. How cool is that?!?
I have solid range with the cute little chip antennas out to 80 feet…and don’t get me started on power efficiency!
captain_dingo:
To handle environmental noise, I’ve started looking into different encodings that will help me detect and/or correct errors.
Thanks!
I probably wouldn’t waste time doing correction as the errors are often burst in nature and very hard to correct with out significantly increasing the amount of redundancy in your packet. That increases size and thus increases the probability of interference and thus increases the error rate. I would just keep the packets as small as possible.
You’re right, except that the transceiver solution will triple the cost of the wireless component of this project with very little gained.
What you suggested looks like it’s around $75 for the three transceivers required, versus approximately $24 for a pair of 434MHz tx/rx pairs.
For this application, considering that a guaranteed delivery isn’t absolutely required (but will cause a bit of user frustration), I don’t think the cost is justified. I think I’ll just do what I can in software to account for interference.
Captain Dingo, you may not need any encoding if all you’re recording is a single button push. Write your software to do two different transmit pulses. So, say 2-3ms for player 1, 4-5ms for player 2. No fancy encoding, you’d only need to run a timer and watch for change on the input pin. This pulse coding should factor out noise, car alarm coding interference, but still keep it simple. Simple tolerances (minimum low time, etc) will help to avoid false positives.
SKU#: WRL-00705 The mirf v2 for 14.95. If you want to build it, the chips go for just a few bucks. I have the version with the chip antenna, and get 80 feet very reliably in a noisy area. Having the auto retransmit feature is extremely cool. If you don’t want to have an SMA antenna, just sweat it off, or ask if SF will supply them without.
I’ll second RonnyM on the MiRF-v2 boards. I have 3 of them, and they work very well and are easy to interface. You can check out the driver library (in C) that I have written to interface to these chips if you should decide to pick one up (I have linked to it in this forum, so a quick search will turn it up).