rf encoders/decoders?

Hello -
I've been toying with Holtek encoders/decoders and Linx rf Tx/Rx modules for a short, low data rate, half-duplex rf link. I wish to transmit several
bytes of data every several seconds or so. The encoder/decoder can only transmit/receive one byte at a time. However, my data are more than a byte long, so I break up the data into several bytes on the Tx side and send it to the encoder for transmission - easy stuff. However, on the Rx side, these data bytes come in with no guaranteed order whatsoever, of course. So here is my question(s): 1) Can anyone suggest encoders/decoders that can handle multi-byte data and don't cost an arm and a leg (the Holteks are just over US$5/pair if you buy one pair only - quite reasonable). 2) If I must stay with single byte packets, any neat tricks to suggest for sending and reassembling the packets? I have Microchip micros on both sides of the link. Bytes to be sent are sent in parallel to the Holtek encoder, which then sends them on serially to the Linx Tx module. On the Rx side, the decoder gets the byte serially from the Linx rf receiver and sets a "valid data" pin high when data is ready for the micro to digest it.
Should I send "marker" bytes followed by the data byte and then reassemble/reorder the marker bytes to reconstruct the data bytes in order? What do people normally do in this case..... ?
Thanks very much for pointers! Bill
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hi Bill,
A few years back I did something similar with the Holtek 8-bit encoder/decoder setup and an AT89C2051 controller. I only used the encoder/decoder parts since the RF modules were a really cheap brand, and the receiver output a continuous noise pulse stream even when not receiving data. The encoder/decoder ICs helped decrease the firmware over-head.
I was only sending/receiving two byte packets, so I didn't need to include any data markers. I'm sure you could just use something like the ~ character (7Eh) to stuff a data marker into the packets for separation on the receiving end.
The problem with using the 8-bit encoder/decoder is that they slow things down quite a bit. The decoder has to receive two consecutive matches of address & data before it transfers data to the decoder output pins. It takes roughly 136mS to receive & decode two packets from the encoder. So about 70% of your data is made up of the synch period, synch bits, and address bits.
Which Linx RF modules are you using? You can probably get by with sending/receiving direct serial data with embedded controllers on both ends. Most of the Linx receivers have very stable data outputs.
I have a remote transmitter sending temperature, relay status, and several other variables to a receiver indoors (both PIC based) with the Linx RXM-433 / TXM-433 using just serial TX/RX. It's a low-speed 2400bps link, but much faster than using the 8-bit encoder decoder setup.
-Bruce http://www.rentron.com
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Bruce - My coworker has the hardware now, so I am not sure of the exact modules he has, but I remember they are rated for about 5 kbps and the carrier frequency is 433 MHz. The transmitter is "off" when no data is being sent and the receiver wakes up when it detects the carrier; the receiver serial output is low until data is sent. We did have good success sending data using RS-232 if the baud rate was low, but the link wasn't reliable if the distance was more than maybe 20 feet indoors. My friend (theoretically inclined) got the idea that maybe since RS-232 data isn't "balanced" (equal number of 1s and 0s in the bit stream) then you may have decoding errors. The Holteks improved the robustness of the link enormously, even though as you mentioned there is lots of overhead in the packets being sent. The thing I didn't like about the RS-232 approach was that the received pulses were distorted so that if you programmed the sending micro to send the data at 1200 baud, the resulting pulse widths were not all 0.83 msec (1/1200) wide. I think there is enough variation between the width of a 0 and a 1 and so the receiver may make mistakes. At least this is my guess. We were considering doing some type of encoding so that we could send any data we wanted. I wrote some code to do Manchester encoding for the transmitter and it looks good. But neither of us have enough experience or high enough IQs to write the code for the decoder! The only code we could find was assembler, which neither of us know.
For the short term (while I slowly do the Manchester decoder) I am going to try to tweak the Holteks. I plan to use the address pins to mark the byte being sent. For example, when I send data byte #1, I will select a certain address. On the Rx side, the micro will periodically set the various address pins and poll when a certain byte is detected by the Holtek Vt (valid data) pin. If I need to send 8 bytes, the receiver will scroll through 8 addresses and check Vt to associate the data with a byte number. But this is very inefficient.
Thanks for the advice!
Bill

modules
several
byte
it
So
just
must
and
which
"valid
order?
encoder/decoder
since
continuous
helped
any data

to stuff

down quite

data before it

receive & decode

synch
sending/receiving
Linx receivers have

other variables

using just serial

encoder decoder

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Bill Turnip wrote:

Why is this? How come what you send first doesn't arrive first?

Break your data into m (where m <8) bit long chunks and use the remaining 8-m bits as a chunk number. So you could send three bytes of data by using four bytes where each has six bit chunks and two bit chunk numbers. You could send five bytes of data by using eight bytes with five bit data chunks and three bit chunk numbers.
Mitch
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Mitch -
I send the data in order, but there is no guarantee the receiver will "wake up" when the first byte is sent and decode it correctly. And even if the receiver does wake up and grab the first data byte, it may not receive it error-free. In this case, the decoder will not generate a "valid data" pulse. So then, maybe the second or third data byte transmitted is the first byte received and decoded correctly. This is a problem especially with rf links, where there is all sorts of external interference, noise, etc. For hard-wired links, I have no problems at all with marking and receiving data correctly, even if I send it asynchronously over one wire.
I thought about embedding marker data with the actual data as you suggest, but this suffers from the same problem as above if you think about it. The decoding effort in software will be the same I think. I guess I should byte the bullet and code some type of buffer. Transmit a marker byte followed by say 4 data bytes. Transmit this 5 byte stream twice. Make the buffer long enough to grab the marker byte at least twice, or 10 bytes long. Find the marker bytes in the buffer, and check to be sure the two marker bytes are spaced 5 bytes apart. (If data byte 3 was not decoded correctly and dropped, then the marker bytes will by 4 bytes apart - data is no good.) If the marker bytes are indeed 5 bytes apart, then the four data bytes between the marker bytes will be considered valid.
I can probably also mark each data byte by preceeding each with pulses of different lengths that would indicate which byte is to arrive next. If the receiver sees a pulse 100 msec wide, its data byte one, if its 200 msec wide, its data byte 2, etc.
I think I am making this much too complicated!
Thanks for the advice and send more comments! Much appreciated!
Bill

using
chunks
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Bill Turnip wrote:

Then I don't understand what the "problem" is. Initially, I thought the problem was to identify the order of data in packets which could be received out of order. Now it looks like the problem is not being able to reliably receive the data at all. Also you allude to having to resort to using a buffer; I don't see how you could have been contemplating doing this without a buffer.
I think your first step should be to try to improve the reliability of your communications channel. There is plenty of information about this, but, to start with, you definitely need to be using a balanced code.
Mitch
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.