IM looking for some advice on how to create a reliable wireless communications system.
Im using two Xbee 2.5 modules as serial line replacements between two µCs.
Currently what I was thinking I would do is use the following packet system to send/receive data;
The sending µC will construct and send the follow to the Xbee: ….
The receiving µC will buffer all of this, do a CRC itself and compare it to the sent CRC. If it’s a good match it will send an ACK, if bad it will request a resend.
If the transmitting µC receives an ACK it will move on. If it receives a resend request it will do so. If it receives nothing after X amount of time it will also resend.
Does this sound like a good system? Too complicated? Not complicated enough? There is not a lot of data to be sent so im more interested in accuracy than speed. Thanks!
That sounds like a pretty good plan to me. You might want to incorporate a <PACKET_ID> also. This way you can send the packet multiple times before receiving an ACK from the other end. If the other end receives the same PACKET_ID multiple times, it can discard them as duplicates and ACK each time. This also negates the need for a “resend request”. It seems less efficient, but it usually makes for a more reliable low-level link in my experience.
Chupa:
Does this sound like a good system? Too complicated? Not complicated enough? There is not a lot of data to be sent so im more interested in accuracy than speed. Thanks!
That kind of depends on your application and protocol. Can you have a missing packet in the sequence? If not, then you have to keep sending the same packet until you receive an ACK. Upon receiving an ACK, you can increment the PACKET_ID. Incrementing the PACKET_ID lets the other side know that this is the next packet in the sequence. If you need a streaming type of protocol where missing packets are OK, then maybe you only send the packet once or twice and hope the other side gets it before moving on to the next packet.
If you are using a session oriented protocol like TCP/IP at the higher levels, it will take care of the sequence and retries. You probably would still want to send the packet multiple times at the lower level a certain number of times anyway for more reliability.
I don’t know anything about the modules you are using, but I would assume that they already take care of retries and ACKS with some kind of configurable settings?
Chupa:
so basically just keep sending the same packet out until an ACK is received?
packet loss is not an option. Each packet needs to get there. So I will do constant sending until an ACK is received.
Im not too sure about the advanced features of the Xbee modules, maybe it does take care of all this stuff in a more advanced configuration. In the simple mode im using them in now they are just serial line replacements. And some early experimenting ive done with them some data never made it to the other side, which is why im trying to come up with a way to prevent that if possible.
If you have a PC attached to either side of this serial line replacement, don’t forget that you might need some form of handshaking as well. Hardware handshaking for RS-232 is done with RTS/CTS. You can also you XON/XOFF software handshaking if you only have 3-wire serial. This way you can tell the PC or other RS-232 device to wait until you are done getting the packet through the RF link.
Chupa:
packet loss is not an option. Each packet needs to get there. So I will do constant sending until an ACK is received.
Chupa:
IM looking for some advice on how to create a reliable wireless communications system.
Im using two Xbee 2.5 modules as serial line replacements between two µCs.
Currently what I was thinking I would do is use the following packet system to send/receive data;
The sending µC will construct and send the follow to the Xbee: ….
The receiving µC will buffer all of this, do a CRC itself and compare it to the sent CRC. If it’s a good match it will send an ACK, if bad it will request a resend.
If the transmitting µC receives an ACK it will move on. If it receives a resend request it will do so. If it receives nothing after X amount of time it will also resend.
Does this sound like a good system? Too complicated? Not complicated enough? There is not a lot of data to be sent so im more interested in accuracy than speed. Thanks!
Need packet sequence numbering too. To detect lost packets.
If this payload data will not go into yet another transport network, say, IP, then you don’t need CRC checking, as this is an oft-used option in 802.15.4. If the MAC layer CRC is wrong, the receiving unit will not do a MAC layer ACK, the sender will time out and re-send, up to n times. This is per '15.4. MAC layer CRC can be disabled though. Also, '15.4 has an option for frame sequence numbering and checking; I think few vendors implement it.
The problem with 15.4 auto-ACKs is if you’re trying to operate in a CSMA/CA mode (as opposed a purely scheduled transmission mode), you need to be aware that ACK packets are NOT addressed. If two devices start up, and start with seq = 0, and transmit at the same relative frequency, it is possible for one data packet to get lost while both senders think the packet has been acknowledged since the sequence number was the same.
There are ways to work around this. A good random generator can reduce the chance of this happening to 1/255, even in the pathological condition of all devices starting at the same time. You of course need to seed this PRNG from somewhere.
Also, unless you add some sort of frequency agility to the system, it is possible for communication to completely degrade in the presence of other 2.4GHz device. Even with frequency agility, the high gain 2.4GHz receivers may just be drowned in broad-band noise from things like wireless access points, and will be unable to receive anything.
this thread has gone over my head, lol. But maybe that’s a good thing.
Ive scene discovered with these Xbee modules that i can use API mode which takes some work off the µC, allowing the Xbee module itself to deal with ACKs and retry. Also it allows for the full function of a Xbee network instead of just transparent serial line replacement.
I do have a question, hopefully some of you can answer it for me, I think its specific to the Xbee product though. What is the difference between a ZNET 2.5 network and a Zigbee network? I have the option to run both types with these modules but cant seem to find much information describing what ZNET is exactly. At first glance it seems like Zigbee Light, but im not sure.
The retries and acks within the module will definitely help with link reliability, but since you mentioned you cannot have any data loss, you need to do a little more work on your end. You have not mentioned what type of data yet. Does it matter if packets are out of sequence? For example, are they small data packets that will fit within the modules min RF packet size? Do the packets contain a time stamp that can resolve sequencing latter? Are these large files that need to show up intact on the other end. If the data you need to transfer is larger than the modules RF packet size, then you will need a more complex protocol to ensure correct delivery. A very well known/tested protocol of this nature is TCP. This Wiki page describes it well and has references to the original RFCs at the end. It can be a bit overwhelming at first though… It might give you some good ideas for your implementation.
If you don’t need something this complex, you might look at some other simple protocols like x-modem. This is way easier to implement than TCP/IP and is very effective at transfering files.
On the other hand, if you are just transferring small data records that fit within a single RF packet, then you might be better off just implementing your own protocol. The main thing to remember with RF, is that it is good to assume that many of your transmitted packets will not make it to the other side.
Chupa:
this thread has gone over my head, lol. But maybe that’s a good thing.
its not complex at all. Im just trying to make a wireless jeopardy buzzer system. There is a console with an LCD to display who clocked in first and and allow the system to be reset for the next round. And there is a control box which will be listening for button presses by contestants. Both the console and the control system will have a Xbee and a µC. The control µC will just keep track of whos clocked in first, what order, and what time (in mS), and transfer that data to the console system. Not much data at all, <50 bytes per transmission, it just all needed to get there.
theatrus:
… you need to be aware that ACK packets are NOT addressed. If two devices start up, and start with seq = 0, and transmit at the same relative frequency, it is possible for one data packet to get lost while both senders think the packet has been acknowledged since the sequence number was the same
The SRC address of the (MAC Layer) ACK is given though. So the node expecting the ACK can/should keep track. If that ACK is garbled/lost, well, you know, that’s why we have reliable datagram protocols. Or applications that do error detection and optionally error correction, as I’ve done in my code, while avoiding the complexity of ZigBee or TCP.
I recall that in a non-GTS PAN, i.e., use of CSMA/CA rather than time slots, the ACK shall be sent immediately (like 200uSec or so) after the receipt of the error-free data frame. A delayed ACK scenario can be implemented but opens Pandora’s box.
stevech:
The SRC address of the (MAC Layer) ACK is given though. So the node expecting the ACK can/should keep track. If that ACK is garbled/lost, well, you know, that’s why we have reliable datagram protocols. Or applications that do error detection and optionally error correction, as I’ve done in my code, while avoiding the complexity of ZigBee or TCP.
Not much help if you’re using a data collection network with one primary sink. But in small networks this could be used. It starts to become a problem at the 200+ scale.
Sounds like you could definitely get away with a very simple protocol. I would just attach a crc to the end of your 50 byte packet from the control box and send it to the console until you get an ack indicating reception and validation of the crc. I’m guessing 50 bytes is less than the max packet size for your modules, but I’m not familiar with them.
Chupa:
…The control µC will just keep track of whos clocked in first, what order, and what time (in mS), and transfer that data to the console system. Not much data at all, <50 bytes per transmission, it just all needed to get there.
From my experience, I’ve had MAC layer CRCs fail in 802.15.4. If you must have data integrity, turn on CBC-MAC mode and share a signing key. More protocol overhead, but bad CRC computation probability is much improved.