PDA

View Full Version : Help with RF transmittions



mbw123
- 9th December 2006, 17:55
Hello,
I have posted much on this subject before (RF) but I need to clarify a few questions I have.

My receiver has a maximum rate of 4800bps. Does that mean the baud rate cannot go higher than 4800? Or are the two not related?

My project works without the RF modules (http://www.futurlec.com/Radio.shtml, first two modules) but when I hook them up, it no longer works. I am pretty sure my schematic is correct as well as my code (I have synchronization bytes and such) but I think this is somehow related to the baud rate I am using over these modules, which is 9600.

I appreciate any help offered.

-Mike

Ron Marcus
- 9th December 2006, 18:06
4800 bps is 4800 baud. You would do well to slow it to 2400 baud, get it working, then increase the rate until it becomes too unreliable.

Ron

skimask
- 9th December 2006, 19:58
4800 bps is 4800 baud. You would do well to slow it to 2400 baud, get it working, then increase the rate until it becomes too unreliable.

Ron


Those are the 2 modules that www.rentron.com sells and I've been using them for a few years now. I've used them successfully and continuously at 9600 baud for quite awhile.
If I would have to quantify the reliability at various baud rates off the top of my head, I think this is what I'd get:

300 baud - almost 0% - too slow, the data slicer loses it's mind since each bit is over 3ms long, each byte 33ms. Even with manchester encoding.

1200 baud - > 90% - if the data coming in is manchester encoding and is continuous, the data slicer doesn't lose it's mind. If there is any pauses between characters, the number goes down.

2400 baud - better than 1200, but you can tolerate a bit longer pause between characters, and again, must be manchester encoded.

4800 baud - > 90% - same reasons as 2400, but now the transmitter is getting bit harder to turn on/off reliably.

9600 baud - about 75% - getting a bit too fast for the receiver now. Although I had one project that would only run at 9600 baud for some reason and had good range, > 200ft. And I found that if you sync the RX with a bunch of $55 first, you could send raw data (not manchester encoded) for quite awhile before the data slicer in the RX forgot where it was.

19200 baud - same as 9600 with reduced range.

Anything higher than 19200 baud would fail almost completely.

If you're still having problems, look at this recent thread I had with lerameur ( http://www.picbasic.co.uk/forum/showthread.php?t=5144 ). We went from start to finish and got it working. The key is manchester encoding when working with these modules.
JDG

mbw123
- 9th December 2006, 21:42
Great, thanks.

If I use it at 2400 baud then, I must use Manchester?

What if I just send a synch byte, like "hserout [$A5,"~",Data]" while at the receiving end I use "Hserin [WAIT("~"),Data"? Will that work or should I revert to Manchester?

Once again, thank you for the posts.

-Mike

skimask
- 10th December 2006, 06:13
Great, thanks.

If I use it at 2400 baud then, I must use Manchester?

What if I just send a synch byte, like "hserout [$A5,"~",Data]" while at the receiving end I use "Hserin [WAIT("~"),Data"? Will that work or should I revert to Manchester?

Once again, thank you for the posts.

-Mike



If you'll look a bit closer, you'll find that your sync character, $A5 (%10100101) , is actually a manchester encoded $A (% 1010 ). That's why the sync character works, it's doing the training for the receiver. However, at 2400 baud, you'll need more than one character to handle the training. See that other thread again.
Just go manchester all the way. It's kept me out of trouble for a few years now and it's reliable.
JDG

mbw123
- 10th December 2006, 17:04
"Just go Manchester all the way."

I will. Thank you for your time and patience.

-Mike

skimask
- 11th December 2006, 04:09
"Just go Manchester all the way."

I will. Thank you for your time and patience.

-Mike


That's my thoughts when using the RF modules. I know there's a dozen different ways of doing the encoding/decoding. As for me, to keep it simple, I just set up a couple of tables at the TX and RX end to do the encoding/decoding for me. On the TX end, send the byte to the subroutine, it kicks me back 2 bytes. At the RX end, send 2 bytes to the subroutine and it kicks back a byte. Simple enough. There are a few 'formulas' out there, I just find the table option to be the easiest.
And don't forget about the 'training' the receiver part. That's the key in my mind. And who knows... Maybe your circuit is a bit less sensitive than mine have always been. Maybe yours can handle straight serial data without encoding. Mine have always been a bit on the sloppy side...electrically and physically... :)
JDG