Serial rf communication

[tazntex]

Hello everyone,
I been doing a little reading about problems with serial communication using rf modules. Most replies have suggested using Manchester Encoding and I still do not quite get how its done. I am experimenting with the Linx rf modules, the TWS and RWS 418Mhz. Anyhow most all of the threads I have read recommend a Preamble, I know that I must add that to the Pic that is transmitting the data but do I also add that to the receiver pic? Thanks for all of you who spend countless hours reading post like mine and make the time to lend a hand.

[mackrackit]

The sending PIC sends the preamble and then a character say 9.
All the receiving PIC looks for is 9, using WAIT. Then when 9 is received the next characters are used.

So no, the receiving PIC does not get a preamble coded to it, it will ignore it.

[BrianT]

The reason for encoding your data is to eliminate long runs of ones or zeros which will cause the data slicer at the receiver to drift off and to provide sufficient data transitions to allow clock recovery. Common wisdom is to use Manchester code on RF links but there is an alternative that can be much better in many cases.

Manchester encodes a 1 with a dibit of 01. It encodes a zero with the opposite dibit 10.
What might have been, before encoding, 11010100 becomes 0101100110011010.

Now think about what happens if the receiver loses or gains a single bit due to noise which is pretty common in RF systems. The receiver will now be out of sync and all ones turn into zeros, all zeros become ones and the data is totally scrambled. The receiver will stay out of sync indefinitely and some external synchronisation scheme is needed to recover. This is typically the transmitter shutting off and carrier detect going low but on a noisy channel the Carrier Detect may never drop, or at least not start and stop cleanly.

An alternative is biphase which is the mainstay of the short haul cable modem business. Here a string of ones is shown by a polarity change at each bit boundary. Zeros are indicated by a change at the cell boundary PLUS a change in the cell centre. The great advantage of biphase is that a single bit error remains just a single bit error. Subsequent ones and zeroes will be correctly decoded. The disadvantage of biphase is frequency spread. Manchester with its 01 and 10 pairs has a spectrum very much centred at the data rate. The receive filters can be fairly tight.

Biphase on the other hand has two distinct tones at the data rate (zeros) and half the data rate for ones.

The software effort is very nearly the same for either system. The RF link can use the same strategy as for a short haul controlled carrier modem. Here the transmitter is off while Request To Send (RTS) is low. When the sending party wants to transmit, RTS is raised and the modem immediately starts sending a string of ones. The far end uses these ones to condition the data slicer and to synchronise clocks. After a brief delay, the sending modem grants Clear To Send (CTS) to the sending device and the data flow begins. The RTS/CTS delay can be set to suit the channel conditions. This becomes the preamble you need to send on the RF link anyway.

The receiver is forced back into sync every time a 1 bit is sent. For long runs of zeros the system can get half a bit out of sync but this throws up only one bit error not a continuous stream of errors as with Manchester.

The same message as above, before encoding, 11010100, becomes high, low, hilo, high, lohi, low, hilo, hilo. The periods of high, low, hilo and lohi are all identical.

At 4800 bps the modem sends a 2400 Hz MARK signal where each zero crossing spells a bit boundary from which clock and data can be extracted. For each SPACE the modem sends one full cycle of 4800 Hz and the zero crossing in the centre of the bit period is easily detected.

HTH
Brian

[Angus Anderson]

Hi Brian-

That's a very clear explanation.

Many thanks for it

Angus

[dhouston]

I am experimenting with the Linx rf modules, the TWS and RWS 418Mhz.

There are some excellent application notes on the Linx website. You should add them to your reading list.

• http://www.linxtechnologies.com/Supp...ication-Notes/

Bruce Reynolds also has some useful wireless tutorials & projects on his website.

• http://www.rentron.com/remote.htm

For small payloads, I prefer using the protocol that NEC introduced many years ago with their IR remote controls. It and slight variations have been used by many others over the years both with IR and RF. It's a bit easier to understand than manchester and other encoding schemes, is simple to implement, has built-in error detection and, because it sends an equal number of ones and zeroes, has good DC-balance over the length of the (relatively short) messages. It also illustrates the use of a different type of preamble to set the AGC/ATC in the receiver and alert the receiver that a message follows. There's an implementation I've used extensively with TWS/RWS modules in the Code Examples forum. See http://www.picbasic.co.uk/forum/showthread.php?t=6261

[tazntex]

I've been experimenting using N2400, Should I use SERIN, SEROUT, or SERIN2, SEROUT2, and since I am sending at N2400 driven inverted, what is the difference if I used T2400, OT2400, or ON2400? Does it matter? Thanks again

[Bruce]

It matters quite a bit which serial mode you use. Most RF transmitters need logic 0 on the
data input pin during idle periods to supress the RF carrier. A logic 1 turns ON the carrier.

A logic 0 turns it OFF. You want a logic 0 on the data inut during idle periods, so inverted
mode is for sure the way to go.

With PBP, DEBUG compiles to the least amount of code, so if you're not familiar with using
DEBUG, it's worth the effort to learn it.

The OT2400 mode returns the serial output pin to high impedance. I.E. it makes the TX pin
an input just after sending serial data. The T part means TRUE mode, which just means
data is transmitted in non-inverted logic. 1=high, 0=low.

ON2400 transmits in INVERTED mode, and leaves the TX pin as a high impedance input
once data is transmitted. I wouldn't use either of these with RF.

N2400, N9600, etc are best, but DEBUG is still one of the best options since it offers the
same data modifiers SEROUT2 does, but produces tighter code.

Serial communications with RF is really pretty easy once you get the hang of it. One of the
easiest ways is to just send the same data payload several times, compare each packet,
and if one or more doesn't match, just ignore it.

Send a long pulse to start. I.E. a 2mS high going pulse, follow it with a few bytes that are
an equal number of 1's and 0's, a synch byte (you can lock onto this with a WAIT option)
then follow-up with the data payload.

[tazntex]

Thanks Bruce, I was looking in the manual at debug, and I also want to learn more about INTERRUPT. when I search the forum these keywords bring me other peoples post of their code with those words in there. Would you suggest where I may find more examples of using these? By the way, I sure hope your about done with your book, or at least still working on it, I am looking forward to purchasing a copy. Again, Thanks

[mackrackit]

Interrupts are not all that difficult, but I do not know of a good list of examples for all that you can do with them and the different types. Melabs web site has some examples.

What do you have in mind to use an interrupt with (type of application) and we can get you started with something basic you can build on.