Author Topic: Approaches to a Manchester Decoder in Software  (Read 2229 times)

0 Members and 1 Guest are viewing this topic.

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Approaches to a Manchester Decoder in Software
« on: July 14, 2019, 03:48:45 am »
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?
 

Offline mskeete

  • Contributor
  • Posts: 20
  • Country: gb
Re: Approaches to a Manchester Decoder in Software
« Reply #1 on: July 14, 2019, 04:40:51 am »
Is this similar to RC5?
You shouldn't need to reclock so often unless you have inaccurate clocks and or super long messages
 

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Re: Approaches to a Manchester Decoder in Software
« Reply #2 on: July 14, 2019, 04:58:23 am »
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.
 

Offline mskeete

  • Contributor
  • Posts: 20
  • Country: gb
Re: Approaches to a Manchester Decoder in Software
« Reply #3 on: July 14, 2019, 10:40:31 am »
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
 
 

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Re: Approaches to a Manchester Decoder in Software
« Reply #4 on: July 14, 2019, 11:01:26 am »
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.
 

Offline mskeete

  • Contributor
  • Posts: 20
  • Country: gb
Re: Approaches to a Manchester Decoder in Software
« Reply #5 on: July 14, 2019, 11:22:15 am »
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.

 

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Re: Approaches to a Manchester Decoder in Software
« Reply #6 on: July 15, 2019, 11:07:22 am »
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.
 

Offline wrynczuk

  • Contributor
  • Posts: 7
  • Country: pl
Re: Approaches to a Manchester Decoder in Software
« Reply #7 on: July 16, 2019, 11:39:47 am »
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #8 on: July 16, 2019, 01:54:51 pm »
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?
« Last Edit: July 19, 2019, 08:04:17 pm by GeorgeOfTheJungle »
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Re: Approaches to a Manchester Decoder in Software
« Reply #9 on: July 16, 2019, 09:37:54 pm »
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #10 on: July 17, 2019, 10:57:59 am »
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?
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Online Dabbot

  • Regular Contributor
  • *
  • Posts: 74
  • Country: au
Re: Approaches to a Manchester Decoder in Software
« Reply #11 on: July 17, 2019, 11:17:42 am »
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.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #12 on: July 17, 2019, 01:54:30 pm »
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?
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Offline mskeete

  • Contributor
  • Posts: 20
  • Country: gb
Re: Approaches to a Manchester Decoder in Software
« Reply #13 on: July 17, 2019, 02:40:27 pm »
I think you'd have to be very unlucky to get a set of glitches compatible with Manchester encoding.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: Approaches to a Manchester Decoder in Software
« Reply #14 on: July 17, 2019, 02:53:55 pm »
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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Approaches to a Manchester Decoder in Software
« Reply #15 on: July 17, 2019, 03:09:16 pm »
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)
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #16 on: July 17, 2019, 04:08:31 pm »
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?
« Last Edit: July 17, 2019, 04:11:40 pm by GeorgeOfTheJungle »
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5345
  • Country: fr
Re: Approaches to a Manchester Decoder in Software
« Reply #17 on: July 17, 2019, 04:40:51 pm »
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?
 
The following users thanked this post: GeorgeOfTheJungle

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #18 on: July 17, 2019, 04:48:18 pm »
Yes, that's a good idea. Problem solved!
« Last Edit: July 17, 2019, 05:02:20 pm by GeorgeOfTheJungle »
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 19755
  • Country: nl
    • NCT Developments
Re: Approaches to a Manchester Decoder in Software
« Reply #19 on: July 17, 2019, 07:36:35 pm »
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.
« Last Edit: July 17, 2019, 07:39:36 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Approaches to a Manchester Decoder in Software
« Reply #20 on: July 17, 2019, 08:26:02 pm »
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.
« Last Edit: July 17, 2019, 08:29:41 pm by Kjelt »
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • Posts: 2494
  • Country: tr
Re: Approaches to a Manchester Decoder in Software
« Reply #21 on: July 17, 2019, 08:32:22 pm »
To each his own.
http://brave.com <- BETTER AND FASTER BROWSER. YOUTUBE W/O ADS/INTERRUPTIONS.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: Approaches to a Manchester Decoder in Software
« Reply #22 on: July 17, 2019, 10:42:16 pm »
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
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: Kjelt

Online nctnico

  • Super Contributor
  • ***
  • Posts: 19755
  • Country: nl
    • NCT Developments
Re: Approaches to a Manchester Decoder in Software
« Reply #23 on: July 17, 2019, 11:01:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: nl
Re: Approaches to a Manchester Decoder in Software
« Reply #24 on: July 18, 2019, 07:07:22 am »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf