Sending packets of data through RF UART

[paulstreats]

Hi,

 You got it all working which is good, even with a delay im sure that you can use the system.


1) Im not sure why this is. Maybe Dunk will know better. Maybe its the receive end not being ready, or maybe its the uart buffer on the transmit end?

2)It is reliable from my point of view. This is only needed because of the raw radio modules. With a hard wired system you could do without the start bit and for non critical applications even the checksum could be eliminated.

3)2400baud/8 = 300 bytes per second theoretically. Correct!

4)In a computer wired system 99.99 - 100% is to be expected these days (there is quite often a bit phase difference depending on the clock speed of the device), microcontroller to microcontroller can range between 90% - 99.99% but those radio modules you should be aiming for about 80%

5)The baud rate is device dependant. If all devices support a higher baud rate then no risk of error should be present. The radio modules say that they transmit readily at 4800 baud so there should be no problem in increasing this. If they were 4800baud maximum transfer speed then you should be prepared for more errors. Also if you look at you microcontroller datasheet, It should give you the baud rate verses crystal speed lookup table. There will be %error included on the table. It can be surprising that a mid range baud rate can yield more errors than a high speed baud rate.

Remember that computers etc.. that receive bad packets with bad checksums can send a message back saying they havent received it correctly and that it should be sent again. With your 1 way radio system you cant do this so you are going to have to accept some bad data eventually. Its either accept occasional bad data or send each packet 3 times and if 1 messes up then you can compare them all. If 2 of the packets are the same then that is the correct data.

[dunk]

1. how come with no delay I get those screwy packets?

1) Im not sure why this is. Maybe Dunk will know better.

i wonder if the RF modules are optimised for more stop bits than your microcontroller sends by default?
i'm guessing though.
i'd not worry about it if i were you as long as you have a workable solution.

when it comes to encoding,
as Paul says, nothing is 100% reliable.
sooner or later you are going to send a mangled set of bytes and by coincidence the checksum will be mangled in a way that makes the packet valid.

probably the simplest checksum to implement if you are not short on bandwidth is just send the data twice. if the 2 copies match then the chances of corruption occurring is fairly small.


dunk.

[airman00]

thanks paulstreats

I understand what you are saying with the one way transmission but after doing tests it seems like I get almost no noise at all once the transmitter is on. Meaning once the transmitter has power , the receiver will not output any byte at all - no noise at all ( well ok once in a while I'll get an occasional bad byte)  .
Would it be safe to use my packet system and just send each packet twice? (chances are that the receiver will receive at least one of those packets).

As for the checksum business:  In my application there are 20 receivers all tuned to the same channel . Each receiver has two addresses. So thats a total of 40 addresses. Meaning if I want to control all 40 addresses at the same time ( which is unlikely in my application) - then I have to send 40 packets. That's half as many packets per second as I get now at 2400 baud. My worry is that if one of the bytes in a packet is corrupted then I'm screwed. (55,56,95) results in a different action then (55,56,59).

If anything I could remove the start bit and have it check for addresses right away. But I guess I can keep it , I mean I already have the system functioning two times as good as I need it . I only need 40 packets a second and I get 80 bytes a second. ( which is good )

Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later.  Right?

By the way I'm getting exactly 80% - 240/300 . I guess I could get higher if that damn delay wasn't needed.
I'll up it to 4800 baud and do some tests and see how it goes.

[dunk]

Would it be safe to use my packet system and just send each packet twice? (chances are that the receiver will receive at least one of those packets).

that depends on what accuracy you need.
if it's just a simple RC system for example you wouldn't need to worry about the occasional bad packet as the next good packet will arrive a few ms later and overwrite any damage done.

As for the checksum business:  In my application there are 20 receivers all tuned to the same channel . Each receiver has two addresses. So thats a total of 40 addresses. Meaning if I want to control all 40 addresses at the same time ( which is unlikely in my application) - then I have to send 40 packets. That's half as many packets per second as I get now at 2400 baud. My worry is that if one of the bytes in a packet is corrupted then I'm screwed. (55,56,95) results in a different action then (55,56,59).

i just want to check something...
you only intend to have 20 receivers powered on at once not the TX modules as well right?
when the TX modules are powered on they "transmit" a "0" as well as a "1". so even when you are not sending something out of one microcontroller's UART, if it's RF module is powered on it is going to interfere with the signal of the others.
if you have 20 of transmitters all powered on at the same time on the same channel you are going to have issues.

if you need multiple transmitters as well you might be better looking into something like the RF modules i'm working with at the moment:
http://media.digikey.com/pdf/Data%20Sheets/Unigen%20PDFs/UGWJ4USHN33A.pdf
far more complicated to use than UART modules but 2-way data flow, huge data rate and over 1000m range...


dunk.

[airman00]

20 receivers all controlled from only one transmitter

what about this part of my question

Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later.  Right?

thanks

[airman00]

Maybe i need to Manchester Encode the checksum only? I was thinking about it and it seems that a non-manchester checksum would cause trouble. Chances are the sum of two manchester encoded bytes ( address and data) are a non manchester encoded byte.

[dunk]

Also as dunk said I could send the packet twice each time. I guess that could work but it would halve my bandwidth. I might have to do it because I was thinking - if the checksum is NOT manchester encoded(which will usually be the case) then it could screw up the reading of the other bytes that are coming in later.  Right?

i'm afraid i have no idea what you are talking about.
why would that "screw up the reading of the other bytes that are coming in later"?

with manchester encoding you are sending each bit twice. once normal and once inverted then check that every other bit is the opposite of it's predecessor.
this way each byte takes 16 "normal" bits to transmit.

with your RF modules if you send the byte twice and compare them at the end you achieve the same reliability as manchester encoding. ie, each bit gets transmitted twice and compared. it's just the point at which they are compared that changes.

also a checksum does not guarantee there has been no corruption.
it is possible for 2 completely different packets to have the same checksum.
you just have to do the maths and work out what chance of corruption you find acceptable.

so, yea, i'm going off on a tangent again...
hopefully i hit the answer to your question...


dunk.

[airman00]

right now I am not doing manchester encoding, rather I am sending manchester style bytes ( bytes with equal numbers of 1s and 0s that were prerwritten in the code). The checksum would not have an equal number of 1s and 0s and that would cause problems , right?

So I guess my best bet is to send each byte twice and only if they are equal to each other is the reading considered good. I assume I will need some sort of timeout that will stop looking for the second byte after a certain amount of time.

[dunk]

are you sure you need to manchester encode at all?
i had presumed the problem was with your UART not with the encoding method all along.

but, yes. sending twice and comparing the results with a suitable timeout will work.


dunk.

[airman00]

are you sure you need to manchester encode at all?

Well the Rx has a ranging comparator so I need manchester encode , right?


I'll do tests with no Manchester Encode and see what happens.