rf encoders/decoders?

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

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

"Bruce" wrote in message news:5_6dnZWVkvp-r7 snipped-for-privacy@bresnan.com...

encoder/decoder

Linx receivers have

other variables

encoder decoder

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

Break your data into m (where m

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

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