Approaches to a Manchester Decoder in Software

[Dabbot]

I've managed to get a one-way IR link between two chips using the usual Vishay TSOP series receiver and a simple custom Manchester protocol for data transmission.

The routine I've written is basically an interrupt driven state machine. It reads the data & re-clocks on each mid-bit edge, ignoring inter-bit edges and terminating reception if the mid-bit edge does not arrive within a window (currently 1/2 bit time either side of the expected edge).

It works well enough, but should I be:
 a) Re-clocking on the mid-bit edge entirely, instead of performing a smaller adjustment?
 b) Terminating reception entirely if it skips a beat, which would most likely just be a single bit error?
 c) Reading the data directly after the mid-bit edge?

[mskeete]

Is this similar to RC5?
You shouldn't need to reclock so often unless you have inaccurate clocks and or super long messages

[Dabbot]

Is this similar to RC5?
You shouldn't need to reclock so often unless you have inaccurate clocks and or super long messages

Somewhat similar. 38Khz carrier. 1.9KHz bit period. One start bit, 16 data bits.
As for re-clocking so often, my thinking was mitigating a wonky start bit and ISR latency jitter.

[mskeete]

many moons ago (1996) I wrote some code for a PIC 16C84 to decode RC5
The start bit was detected by polling in the main routine and then the interrupts were synchronised (by reloading the interrupt timer counter) to occur in the middle of the expected data bits.

If the half bits weren't 0,1 or 1,0 (Manchester encoding) then there's an error (dont care which type of error) and you reset and wait again.

That worked very well for me and the PIC was running form a 4Mhz resonator.
You're probably using something a lot faster with smaller latencies so if its working for you then i wouldn't worry too much
 

[Dabbot]

You're probably using something a lot faster with smaller latencies so if its working for you then i wouldn't worry too much

PIC12F1572 and TMR2 at 8MHz internal RC.

I'll give a slightly different method some thought. It'd be nice to read in each half of the bits into separate registers, then XOR them together for bit error detection.

[mskeete]

Attached is the code I wrote - complete with spelling mistakes.
It's written in assembler.

It was for a remote controlled audio preamplifier so there's a load of code in there for controlling a LMC1983 and storing stuff in EEPROM which you can ignore.

[Dabbot]

Nicely done. I rewrote my code to take a similar approach to you, just letting the timer fire in the middle of every half bit.

It works well! Just for fun, I brought it up on the scope. One trace for the IR receiver output, one trace for a micro output that blips when the timer fires. It gets a bit close to the edge of the half bits at the end of the transmission, but not bad.

[wrynczuk]

There is another interesting and neat approach:
https://www.clearwater.com.au/code/rc5

Believe it or not, but I implemented the algorithm successfully (yet few years ago) on an industrial PLC using the ladder language. Definitely, it is a good solution for low-end devices.

[GeorgeOfTheJungle]

Somewhat similar. 38Khz carrier. 1.9KHz bit period. One start bit, 16 data bits.
As for re-clocking so often, my thinking was mitigating a wonky start bit and ISR latency jitter.

PIC12F1572 and TMR2 at 8MHz internal RC.

I wrote a decoder all in software (polling, no interrupts, no timers), it's for a 6502 @ 1MHz. It self syncs and can decode manchester streams of between 13 and 15 kbits/s in packets of up to 256 bytes maximum.

https://gist.github.com/xk/1f455af5c9017150b8d6234743e9c2a3

The routine I've written is basically an interrupt driven state machine. It reads the data & re-clocks on each mid-bit edge, ignoring inter-bit edges and terminating reception if the mid-bit edge does not arrive within a window (currently 1/2 bit time either side of the expected edge).

It works well enough, but should I be:
 a) Re-clocking on the mid-bit edge entirely, instead of performing a smaller adjustment?
 b) Terminating reception entirely if it skips a beat, which would most likely just be a single bit error?
 c) Reading the data directly after the mid-bit edge?

Mine resyncs at every mid-bit edge, terminates at the first missing mid-bit edge, and it's an err unless the missing mid-bit edge happens just after a complete byte, in which case it means an end of packet which is ok.

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

[Dabbot]

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

The interrupt is generated by the edge (interrupt on change), so the ISR reads the value of the pin to determine what the edge was.

Yes, the mid-bit edge is the data. And so is the state of the pin before (inverted) and after said edge within the bit period.

[GeorgeOfTheJungle]

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

The interrupt is generated by the edge (interrupt on change), so the ISR reads the value of the pin to determine what the edge was.

Yes, the mid-bit edge is the data. And so is the state of the pin before (inverted) and after said edge within the bit period.

Oh, ok. Isn't there a race condition?

[Dabbot]

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

The interrupt is generated by the edge (interrupt on change), so the ISR reads the value of the pin to determine what the edge was.

Yes, the mid-bit edge is the data. And so is the state of the pin before (inverted) and after said edge within the bit period.

Oh, ok. Isn't there a race condition?

No race condition. The IOC peripheral raises an interrupt when there's a transition on the pin, so the CPU executes the ISR. The ISR checks the source of the interrupt and, if it was from the IOC, reads the value on the pin.

[GeorgeOfTheJungle]

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

The interrupt is generated by the edge (interrupt on change), so the ISR reads the value of the pin to determine what the edge was.

Yes, the mid-bit edge is the data. And so is the state of the pin before (inverted) and after said edge within the bit period.

Oh, ok. Isn't there a race condition?

No race condition. The IOC peripheral raises an interrupt when there's a transition on the pin, so the CPU executes the ISR. The ISR checks the source of the interrupt and, if it was from the IOC, reads the value on the pin.

And, if the pin has flipped again before the ISR gets to read the value? Say it was a glitch, a 5ns pulse for example?

[mskeete]

I think you'd have to be very unlucky to get a set of glitches compatible with Manchester encoding.

[mikeselectricstuff]

Use a capture peripheral to capture and interrupt on every edge, filter noise by rejecting any gap that's too long or short, classify into long or short gaps and decode with a state machine.

[Kjelt]

IIRC on my work we oversampled 16x the signal.
So just sample 16x the bittime and store in a queue and process when you have the time or the queue is getting full.
8x also worked, 4x was not fullproof IIRC (long time ago)

[GeorgeOfTheJungle]

Ok, that PIC does not tell you if it's been a rising or falling edge. So you can either use two pins tied together, one configured to interrupt on rising edges and the other on falling edges, or do as you're doing with a single pin and look at the pin's value upon entry to the ISR. Hopefully, if it was a glitch and there's been two edges, the ISR will be immediately triggered again upon rti? (If not you've got a problem) And you'll see the timing as not ok on the second invocation of the ISR and abort?

[SiliconWizard]

Hopefully, if it was a glitch and there's been two edges, the ISR will be immediately triggered again upon rti? (If not you've got a problem) And you'll see the timing as not ok on the second invocation of the ISR and abort?

I would not necessarily count on that, but additionally checking that every edge detected leads to a different state should at least ensure that you won't make a decoding error?

[GeorgeOfTheJungle]

Yes, that's a good idea. Problem solved!

[nctnico]

What do you mean with "Reading the data directly after the mid-bit edge"? The mid-bit edge (direction) is the data, isn't it?

The interrupt is generated by the edge (interrupt on change), so the ISR reads the value of the pin to determine what the edge was.

Yes, the mid-bit edge is the data. And so is the state of the pin before (inverted) and after said edge within the bit period.

Don't implement it like that. Having interrupts fire on GPIOs is asking for trouble. If something goes wrong in the hardware a GPIO interrupt can easely swamp your processor and at least cause an uneven / fluctuating / erratic processing load causing hard to reproduce problems and worst case crash the whole thing.
What I always do to decode manchester like streams is use a timer interrupt at around 6 times the bitrate (in your case it would be 11.4kHz) and sample the input from the timer interrupt. When you detect a change in the signal you can check how many timer interrupts ago the previous edge occured. Between 2 and 3 ticks is a short pulse, between 4 and 7 ticks is a long pulse.

[Kjelt]

That's how we did it but then with 8x or even 16x oversampling. The int serv routine is only sample the pin and store the boolean or bit in a ringbuffer aka the queue and exit.
When there is time to process or the queue is full you read the queue and write the decoded bits in a different buffer. Then when it is complete you decode the buffer and execute the command or whatever needs to be done.

The only exception is when you're processor has absolutely nothing else to do, if it is a dedicated decoder like the old SAA3049 RC5 decoder back in the day.
In all the other cases first do the RMA analysis.

[GeorgeOfTheJungle]

To each his own.

[mikeselectricstuff]

Also bear in mind that Manchester code is polarity-ambivolent so you don't actually need to know the polarity of the edges as long as you detect all of them

[nctnico]

That's how we did it but then with 8x or even 16x oversampling. The int serv routine is only sample the pin and store the boolean or bit in a ringbuffer aka the queue and exit.
When there is time to process or the queue is full you read the queue and write the decoded bits in a different buffer. Then when it is complete you decode the buffer and execute the command or whatever needs to be done.

That is rather cumbersome because of the overhead of buffering and this way also brings non-deterministic code execution. You'll need the processor time anyway and it takes less CPU cycles to do the job when the data enters the system. Life becomes much simpler if you view the interrupt controller as a hardware based time slicing OS.

[Kjelt]

That is rather cumbersome because of the overhead of buffering and this way also brings non-deterministic code execution. You'll need the processor time anyway and it takes less CPU cycles to do the job when the data enters the system. Life becomes much simpler if you view the interrupt controller as a hardware based time slicing OS.

It all depends on the other processes and priorities that need to be executed. If there are processes running that are time critical you don't want to get stuck too long in your interrupt service routine.
In the end we had multiple signals that needed sampling so we made a RMA to balance the load. We did not have an RTOS back then (8 bitter) and just made our own version handling the tasks according to priorities. IIRC the "jitter" on the rc5 decoding was less than 3ms since it was a human interface well within specifications, I don't know the max response time to human interfaces anymore but believe it was something in the order of 50-100ms or thereabout.