1. Home
  2. General Robotics Forum
  3. rf comms HW suggestions?

rf comms HW suggestions?

Hello all:

I've been working with PIC micros for a while, and am looking to get "untethered." I would like to transmit sensor data wirelessly over a distance of maybe around 20 meters, and possibly through (non-metallic) walls (and then maybe only 5 meters). The transmission would be one-way and relatively low duty cycle, at most several bytes (precoded) of sensor data once every few seconds. Since I don't need full-duplex, I could get away with simply an rf transmitter/receiver pair I think. Since PICs can handle RS-232 comms really easily, I was wondering if there are any inexpensive rf pairs that have built-in RS-232 comms support: Bacially, just write the data to be sent on the transmission side as if you were printing to the RS-232 port (the PIC Tx pin), and then on the receiving side just look for RS-232 data on the PIC Rx pin. Any fancy encoding required for the rf comms (like DC-free Manchester or whatever) would be transparent to the user, and coded/encoded by the transmit/receive modules. 1) Do such modules exist? I saw some describe in a Parallax Stamp app. note I think, but can't locate the modules in question. 2) Is the encoding/decoding overkill? Do I need DC-free codes for such low-duty cycle, low data rate channels? I thought that Manchester encoding was used when the clock needs to be embedded in the data; its not solely for the DC-free aspect. I am not experienced in this area, and when we covered it in school, I was sick that day..... Seems to me that getting the receiver "in synch" with the tramsmitter is much more important as far as reliable performance goes in the link I describe.

Any feedback suggestions links appreciated; I'll summarize my findings and report back.

Thanks very much, Bill T.

Reply to
Bill Turnip
Loading thread data ...

I dont think one-way (i.e. transmitter on robot and reciever near computer or something) would work with RS-232 as it requires timing bits and things to go between both hosts so they can synchronise etc.

I'd love to know if anyone has a solution to this as I sort of have/had a need for cheap and simple one-way telemetry transmission.

Reply to
Matt Dibb

I've done a bit of this. Technically, you're not really looking at RS-232 -- RS-232 includes an electrical specification, and is by definition done over wires. I think a more accurate term is just asynchronous serial IO to a transmitter (or receiver).

Lot's of PICS have a built in MSSP module, which can do asynch IO -- but this is probably not really required in your case.

I'd start with an inexpensive RF module -- these can be had from

formatting link
(see the TXL and RXL modules). I assume you don't need particularly high baud rates.

You can get away with just bit-banging serial data through these units, but using a manchester encoding scheme (or something similar) will vastly improve performance. All manchester encoding really involves is encoding logical 1s and 0s as state changes. In other words, to transmit a one, take the transmitter input from high to low (transmit 1 0 ). To encode a zero, take the transmitter input from low to high (transmit 0

1). You could also do the inverse. Looked at another way, just output the desired bit and it's complement (or visa versa).

The receiving end looks for these state changes to determine incoming 0s and ones. You should also encode a start bit of a longer duration to mark the beginning of a data byte. Note that you will effectively halve your baud rate using this scheme, but you get a certain amount of bit-level error correction built in, and you'll see much better reliability and range with most of the cheap RF hardware modules out there.

I have code somewhere (I think both PIC BASIC and CCS C) that does this on a 16F86. EMail me, and I'll try to find it when I get back into town (about a week or so).

Hope that helps -- taFkaks

Reply to
The Artist Formerly Known as K

That thing has near zero interference immunity. But that's OK for your application. Put a CRC on your data packets and send everything multiple times. Some of them will get lost, but that's OK.

John Nagle

Reply to
John Nagle

So, send the data several times with a CRC, and recheck the received data. If the CRC is OK, then assume the data is OK. Discard the data with the bad CRC. Sounds OK, but the overhead is enormous. Not that this matters in my case, but wow.....

Have you tried using the "Holtek" encoders/decoders? "Address" bits are added to the data you wish to transmit. If this address matches what the receiver expects, then the following data byte is considered valid and latched in to the decoder. In addition, a "valid" pin on the receiving decoder toggles to indicate the decoder saw something it liked. Of course, if the correct address is never received because of noise, then data is never latched in and the receiver just sits there..... It seems like using these just saves you writing firmware to check for a valid CRC.

Any comments? Bill

Reply to
Bill Turnip

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.