Manchester encoding

OK, here's the decode which ran on another PIC hooked to a radio receiver module. The 2 coded bytes were decoded to give a single output byte, referenced via a pointer ByteRx. This code should run on an AVR using a C compiler such as ICCV7, it's standard ANSI C. I stress I have no knowledge of AVRs myself though. You would need to code your own UART serial input/output routines to feed this data in/out of the micro, serial i/o on the AVR will differ from the PIC of course.

Steve

Code:

/* Decode the pair of Manchester encoded bytes and return single byte resulting */

/* Process 1st coded byte, gives 4 low bits of decoded byte */ for (ctr2=0;ctr2

My application did not need error correction, well not more than a resynch if one of the paired data bytes (16 bit data) was lost. Hence I wrote no error code. The only reason I used Manchester coding was to balance the data stream, which is of course necessary with typical radio data modules.

Steve

What is an algorithm for error correction? Send every byte 3 times, take best 2 out of 3? (300% overhead. Not real elegant, but might punch thru under certain conditions?)

For the same bitrate I'd prefer to send the same message 3 times to get some time diversity between them.

Use a CRC 16 at the end of the message. Easy to compute. error detection is 1 part in 2^16.

Blakely

Use a CRC 16 at the end of the message. Easy to compute. error detection is 1 part in 2^16. ======================================= Hi Blakely. How does the transmitter know if it got through? (one way comms usually, right?)

I hope your computer is better at arithmetic! 200% overhead.

Peter

A real communication protocol generally has the requirement of both error detection and error recovery. SDLC/HDLC uses numbered frames and can detect when frames are lost. Other protocols like I2C use an extension bit interval at the end of the message that is driven by the receiver and detected by the transmitter as a method of message validation.

Message timers are another way to detect the loss of a message. Bad packets are simply discarded. In the absence of a return response within a timed window, the originator simply resends the message.

In a pure one way system, you can only raise the statistical likelihood that a message got through. The likelihood is very high however. In a short and highly controlled link, you will do better than 1 part in 10^9. Uncontrolled links are a much different story. Then it becomes an issue of efficiency - total number of bits sent vs the actual information exchange rate. N redundant messages with N-n majority voting is one way.

The CRC method provides a means of efficient error detection, but not error correction. As you move to error correcting codes, the tradeoff is the overhead of error correction bits that are added. The type of code is used deep in the heart of your CD-ROM drive (which is a good analog to a one way channel - data flows in only one direction). A surface defect on a CD may destroy a bit field. But the lost data is recovered by use of an error correcting code.

Tannebaum's "Computer Networks" is a good read on the subject, as are some of William Stalling's works.

Blakely

PD: I hope your computer is better at arithmetic! 200% overhead. =============================================== Good catch. Have an opinion on error cirrection for an rf link?

A great deal depends on the consequences of missing a packet and of getting an incorrect packet.

If the costs of a missed packet are high then you should look into forward error correction algorithms.

If you can afford to miss a packet (or are able to request a retransmission) but the cost of incorrectly decoding a packet then look into CRC algorithms.

Wikipedia is a good place to start.

Manchester encodes a bit in half high and half low.

How do you handle 40% - 60% or 5% - 95% ? Spikes? Speed changes?

Error correction on a specific packet is rarely done in larger systems. A NAK followed by a resend is more likely. Wasting 2/3 of the bandwidth is not acceptable in many systems.

A small point to point system with a lot of spare bandwidth could use this approach, but it will also add latency to when you can send the next message which may or may not be acceptable

Ulf Samuelsson scrobe on the papyrus:

. .

. .

The OP was asking about radio with no return channel. How do you think he is going to get a NAK or even an ACK response.

"John B" skrev i meddelandet news: snipped-for-privacy@individual.net...

"BobG" did not mention anything about RF in his original post, to which I replied. I didn't say that it error correction is never done.