RF Packet / Reliability Trade off

[col_implant]

Hey,

I'm designing a unidirectional RF system for use in an implant.

We are transmitting 255 bytes of data + a few info byes, using manchester encoding, all comms software written in PIC assembly. 433 MHz using a stripline loop antenna inside the body and a proper lamda/4 antenna outside. Our range is very short 1.5m max, so transmission power is a minimum. We have the hardware more or less finalized and have been conducting tests transmitting from within a container of saline solution to mimic in-vivo conditions.

At first we transmitted single byte packets (or 2 manchester bytes in respect of RF) and our reliability was excellent. Now I have gone to the other extream transmitting 255 byte packets and the reciever is correct about 75% of the time (at 1m from container). From a power perspective bigger packets are better but since or communications are unidirectional reliability is also a must.

Does anyone know if there is any guides or rules of thumb on packet sizes / reliability tradeoff?? And any simple error correcting codes (bear in mind assembly)? Obviously im a bit of a newbie in terms of RF.

Tanx

 

[JimB]

There may be some formula which relates packet length to error rate, but I am not aware of it.
However, from practical experience I can state that error rate is inversly proportional to signal to noise ratio. As you are using a low transmitter power, any external noise will affect your error rate.

433 Mhz is not a quiet frequency, there will be many "low power" devices on the same nominal frequency, and a number of much higher power transmitters (licenced authorised users) on nearby frequencies to which your simple (I assume) reciever will be susceptible.

As I dont know your final application, my recomendation is that you bring the receiver nearer to the transmitter thus increasing the received signal level.

You also state that you are using "a proper lamda/4 antenna", a quarter wave antenna cannot be considered "proper" unless you consider the associated ground plane (earth). I assume that this quarter wave antenna is mounted directly on the receiver module, it may be better to use a half wave dipole remote from the receiver and connected to it by a coax cable.

JimB

 

[RadioRon]

If you are indeed suffering from interference or some other source of noise, then it follows that a tiny packet of a few bits sent at a high rate have a much better chance of sneaking through between noise spikes than a long packet. Statistically speaking, the longer the packet length for a given data rate, the more chance of errors in a noisy environment. The typical Bit Error Rate curve looks something like the diagram in this article:
http://sss-mag.com/ebn0.html

the x scale is linear in dB, while the vertical scale is logarithmic. It demonstrates that you get really big improvement in error rate for fairly modest increase in Eb/No (or in SNR).

 

[quixotron]

yes. i remember this problem in digital communications.


you are referring to shannon's channel capacity theorem. it dictates how much information you can send at some reliable/probable rate given a SNR/ tx and Rx power levels.

link

read up on it. its not real hard but you have to do some homework, i'd help you some more, but i left my communicaton books at my dads house, 400 miles away. i only brought my rf books. if you really need help, let me read up on it and i'll get back to you.

 

[col_implant]

Thanks a lot, some great suggestions there.

From my intial tests, 255 byte packets within the saline filled vessel, in the lab (so considerable noise) is appears that bit errors are very rare... instead my software encounters pulses which it thinks are too long or too short and de'syncronises resulting in the loss of the entire packet. Is this is the nature of any/most errors in manchester coded RF data??? Perhapps I need more intelligent software to recover from invalid pulses, maybe a byte separator would be good to syncronise to.

Yes, I will dust off my old 'digital comms' notes over the weekend and look into it

Cheers!

 

[quixotron]

Thanks a lot, some great suggestions there.

From my intial tests, 255 byte packets within the saline filled vessel, in the lab (so considerable noise) is appears that bit errors are very rare... instead my software encounters pulses which it thinks are too long or too short and de'syncronises resulting in the loss of the entire packet. Is this is the nature of any/most errors in manchester coded RF data??? Perhapps I need more intelligent software to recover from invalid pulses, maybe a byte separator would be good to syncronise to.

Yes, I will dust off my old 'digital comms' notes over the weekend and look into it

Cheers!

sounds good. i'll look into it as well. i wanted to be comm but i decided to go rf.

 

[Blueteeth]

Does you RF reciever output ttl? or raw analogue? A dataslicer might be a better idea.

Also even if it is digital you can get rid off quite a few noise spikes by over sampling the incoming data. I'm not sure if this will solve your problem but there are many things one can do to improve RF comms, I'm just starting with simple things to try (like NOT buying a new TX/RX pair ).

Providing you know the data rate, which you do....you can sample the data very quickly, perhaps 16-32 times in the chiprate...then take a majority vote. Often when an analogue signal is sliced into ttl...the noise spikes make it jitter, so you can filter them out digitally.

Also I assume your 'packet' is a common format?
<Preamble><sync><header><data><control> type thing.. Obviously 'data' and 'control' are just random names but a preamble is a must...it'll allow your RF reciever AND the digital clock recovery logic (be it software, PLL, CMOS) to syncronise well enough for the whole packet.

With a few lil cheap 433Mhz RF modules I've used, I got good results just using a hardware UART on the PIC, and manchester encoding using a look-up table. The start and stop bits between every byte are handy for byte syncronisation too.

Also as someone has already pointed out....'burst' communications can help a lot. Max datarate, blast out the bytes, then sleep. As it is unidireciotnal, you're limited to either sending the data three times (longer packet, more chance of errors) or...forward error correction. FEC is though on a PIC, unless the datarate is really low, but it can be done.

I would first 'ignore' the error correction part, and start with a long preamble, a sync, then some dummy bytes - 'in system'! Once you have the most reliable RF comms you can get, start making the packets longer and longer, until you get to your 255. Debugging comms can be a bit of a bugger :/

Blueteeth