RFM Packet loss

[cheerio]

Hi,
i develop a CAN-Bus RFM bridge. I use the RFM70 (http://www.hoperf.com/upload/rf/rfm70.pdf) Module because i need only small distance coverage.
Here is what my problem is. I have a packet loss of ~0.017% in optimal conditions. I tried to pin down the problem but i could not find the reason of this packet loss.
The buffers where never full, the SPI speed did not influence it, the position of the Modules did not change anything (currently 50cm distance).
WTF is going on? What can i still check to find the error? It is kinda random and does not occur at the same package count.

[kam]

New project???  I've lost count...

Check this out:
http://guap.ru/guap/nids/pdf_2010/barge.pdf

Several studies have investigated different aspects of Bluetooth packet loss. One study looked at packet loss at the MAC sublayer and monitored performance [11]. The study suggested that as distance between Bluetooth piconets decreased, the packet loss increased. At a very close range of 0.5 meter, packet loss was up to 60 percent. As the distance between piconets was increased to 2 meters, packet loss decreased to 18 percent. The unexpected appearances of wireless devices can severely impact the existing surrounding wireless environment

I checked some other links, all talked about packet loss, so it is normal and you must handle it.

[cheerio]

bachelor thesis. but not really a new project as it is a module for the water management system ^^
actually i do not know how to handle it. It is a broadcast system that does not know how many receivers there are. In my application it is not a real problem as i have only 2 modules talking to each other and the module has an automatic retransmit function for this case. But a packet loss of  0.017% w/o auto ACK and in optimal conditions is not very satisfying... maybe it is just the German talking in me ^^

[kam]

Yep, if 0.017% is the case, then doch,ist der Deutsche...
What you wanna do is use some sort of error correction. The Hamming code i think fits nicely to your project. I tried it once and worked fine for me (for testing only).

[cheerio]

Thank you! I think i will go for parity because i have some bytes per packet yet unused.

[_pike]

May i ask???  How many bytes do you send? And what means a 0.017% to the data?it means that you loose for example a byte?

[cheerio]

it is ~ 13bytes per packet. I lose the whole packet once in a while. 0.017% means that i lose approximately 1 packet out of 5000.
I realized that i cannot go for parity since i do not send data in multiple packages. 1 package contains all the data

I did a nasty embarrassing workaround for now. I just send every packet twice and filter the duplicate packages out on the receiver. Losing two packages in a row is not very likely with 0.017% packet loss. But it is not a solution that is satisfying.

[kam]

I did a nasty embarrassing workaround for now. I just send every packet twice and filter the duplicate packages out on the receiver. Losing two packages in a row is not very likely with 0.017% packet loss. But it is not a solution that is satisfying.

No it is not nasty nor embarrassing! Repetition is often used in commercial products! There are RC protocols based on repetition and some on repetition AND inversion (the same data but inverted).
With the hamming code, an 8-bit byte is turned into a 12-bit (4 control bits are added). Maybe you should consider split data in half, add some error correction and send them. This way you have again the same result with repetition, as well as error correction. Only advantage with hamming code over repetition is that with hamming code you can correct the error on the receiver while with the repetition the code must be resent (you cannot tell which one is the correct one).

[George]

To go with using the parity bit, have a look at the old ACK NAK protocol, it's basic handshaking protocol for serial data

[cheerio]

Cannot go for ACK because i use a CAN Bus like specification. Every packet is a broadcast and the number of receivers can change. The packet can be lost for one receiver but all the others receive it and say ACK. Another problem is the ACK spam that the receivers send. It slows the bandwidth down significantly.
On CAN Bus the ACK is used to detect if smth is wrong with the transmitter. If no ACK is sent then the receiver repeats to send the packet for a fixed number of times and shuts into listen only mode after reaching the limit. This prevents the Bus from being blocked. This procedure makes sense because you don't get random packet loss on the wired Bus.

No it is not nasty nor embarrassing! Repetition is often used in commercial products! There are RC protocols based on repetition and some on repetition AND inversion (the same data but inverted).
With the hamming code, an 8-bit byte is turned into a 12-bit (4 control bits are added). Maybe you should consider split data in half, add some error correction and send them. This way you have again the same result with repetition, as well as error correction. Only advantage with hamming code over repetition is that with hamming code you can correct the error on the receiver while with the repetition the code must be resent (you cannot tell which one is the correct one).

It IS embarrassing because the bandwidth is half the bandwidth before and if the conditions get worse it will not prevent packet loss. To split the packets and add parity is smth i was thinking about too. I ran some tests and my double send method has still 0.0047% packet loss. Wireless can be so painful :/

The module has itself a CRC check included. If a packet is bad then it will not be saved as received.


For now i do not bother with the packet loss anymore. I have to hurry and put the collision avoidance together. I want to finish this sucker before Christmas

[cheerio]

maybe this should be moved to the communication/protocols section.

I want to read your opinion on my collision avoidance and sanity check implementation.

All messages are broadcasts with an ID that identifies the Data. A lower ID is a higher priority.
for ex.
ID=0 -> emergency stop
ID=100 -> current-sensor data
ID=200 -> temperature-sensor data

and so on.

every module can send and receive. No id may be the same on 2 different modules.

The collision avoidance procedure needs 2 timers:
RX_TIMER > RTS_TIMER
To prevent collisions the procedure is as follows.

If a module A wants to send smth it sends a RTS package that includes the ID of the package to be sent. Then it listens for RTS_TIMER duration

The other modules receive the RTS and check if they need to send smth too. If that is the case they check if their ID is lower (higher prio).
Lower ID -> send RTS (same procedure like the one in module A is startet)
Higher ID -> listen for RX_TIMER duration


If module A listened for RTS_TIMER duration w/o receiving a RTS package with a lower ID it sends the data package.
If it DID receive a RTS package in that time it quits all transmit efforts and listens for RX_TIMER duration


Sporadically there was still a collision that overlapped 2 packages. They still came through the crc check (wtf?) and where accepted. To prevent this i added 5 Byte to all transmitted packages. I use 5 fixed reference Bytes, sanity[0] to sanity[4]. When i append them i do packetID%sanity[0...4] (% -> modulo)
so i can check whether the sanity bytes belong to the package ID.


edit:
i still get overlapped packages. though they became VERY rarely. But this is not accaptable and this drives me %"()/§$ crazy!

[kam]

So, obviously there is a "big" delay somewhere between the transmission command and the actual transmission? Probably....

Why don't you do something else? Why don't you have a "maestro" transceiver which will "ask" all modules one by one... Each module can transmit only within a predefined time period after being asked by the maestro.

[George]

Cherio check out 802.5 token ring protocol, in particular, listening before transmission, and a variable delay timer, to allow for multiple devices trying to transmit at same time

[cheerio]

Cherio check out 802.5 token ring protocol, in particular, listening before transmission, and a variable delay timer, to allow for multiple devices trying to transmit at same time

I do listen before talk and i have a variable delay for "counter" rts transmit.  The delay is shorter for lower ids and higher for higher ids so the bus is not spammed so much. Unfortunately the Carrier Detect needs ~120us to detect a signal and i am certain that is the time window where everything messes up.

Token ring is not applicable for this network. There is no destination address of a package. All receivers are valid receivers. Check out "CAN Bus" too see how this is working.

So, obviously there is a "big" delay somewhere between the transmission command and the actual transmission? Probably....

Why don't you do something else? Why don't you have a "maestro" transceiver which will "ask" all modules one by one... Each module can transmit only within a predefined time period after being asked by the maestro.

Having this kind of access point would be a coding and memory overhead. i want to finish this soon.

I found out that the overlapping that changed the id of the package did not occur anymore. And the overlappings that still happen have a length of 0 Bytes. This is impossible as i add 5 bytes ALWAYS. I think i can make it work very easy now.

[cheerio]

This is the program flow regarding collision avoidance. I think words are not very good to explain smth like this.

RX-Timing > RTS-Timing > TX-Timing