How would I software-decode this 260KHz serial stream?

Question

I've probed this serial stream coming out of a scoreboard controller and it seems like a proprietary protocol. How would I go about trying to software-decode this?

The start bit is 7.8us long. All the data bits are about 3.85us, giving a bus speed of around 260KHz. A logic HIGH bit starts with a 3.1us HIGH period then a ~800ns LOW. A logic LOW bit is the same but the periods are switched. Each packet is made of 255 bits, so about one packet is sent every millisecond.

I've thought of triggering on the rising edge and then reading the pin level after a short delay, but I don't think an interrupt-driven scheme would work that well because of the overhead.

Any ideas?

Answer 1

You say that the overhead of interrupt handling would be too high, but I don't think that's necessarily true. A cheap microcontroller may not be able to do much useful processing of the data stream, but it should be powerful enough to serve as an ad-hoc converter.

Let's take an AVR chip as an example: the ATmega328P that serves as the core of the Arduino dev board. At the maximum clock rate of 20MHz, you get 77 clock cycles per bit. According to the datasheet (page 15) it takes about 7 clock cycles to enter an ISR and 4 cycles to exit.

Assuming you spend half of each data bit in a spin-loop waiting for the right time to sample the input, you're left with about 27 cycles per bit outside of the interrupt handler. Most AVR instructions are single-cycle, so that should be plenty of time to frame the bits into bytes and shove them onto an SPI link to your host processor.

(I've glossed over the problem of detecting start bits. One option is to reset one of the built-in timers at the beginning of every bit, and use the output compare to determine whether the interval between two rising edges exceeds a threshold.)

Answer 2

I've decoded signals like this with AVRs. I did it with a pin change interrupt and a free-running timer. You could also do it with a capture input on the timer, but I was also waking on the data so I needed the asynchronous detection capability.

Basically what I did was every time I got a pin change interrupt, I looked at the time and the state of the pin. I could then say "the pin was 3us high" or "the pin was 3us low" and shift the 1 or 0 into an input data word. I used a @#define@ to determine the threshold time of a high or low and empirically determined a good value to use. My received data words were 33 bits long, so after I counted 33 bits I flagged the reception as complete and flagged the main routine to actually verify and decode the data word.

For robustness, I also reset a timer which had a period of about 10ms. If that interrupt fired it meant that I should reset my receive subsystem since there wasn't any data coming in and my bit counter hadn't counted enough data to consider the message complete.

Answer 3

One way to decode this would be to invert it and then feed it to a UART that's set for 2.6 Mbps (a bit extreme, but some UARTs can be set this high).

The rising edge of each pulse would become a falling edge — a start bit — for the UART, and each type of pulse would produce a unique data pattern in the UART receiver: a "1" would become 0x80, a "0" would become 0xFE, and a "start bit" would become 0x00 (and possibly cause an "overrun" error). The firmware would convert these byte values into bits and then decode the protocol as appropriate.

It's possible that you could set the UART to 1.3 Mbps and receive two of the signal pulses per byte — the decoding gets a little trickier, but you'd have only half the interrupt rate to deal with.

• 0x00 → start pulse
• 0x7F → 0 followed by 0
• 0x0F → 0 followed by 1
• 0x74 → 1 followed by 0
• 0x04 → 1 followed by 1

---

A completely different approach would be to use a pair of retriggerable monostable multivibrators. One would be set to a period of about 1.9 µs; it would create a clock edge in the center of each bit. The other would be set to a period of about 5 µs; it would detect the "start" pulse.

You would then connect these signals to a SPI slave port on your micro: the original data signal to MOSI, the clock signal to SCLK, and the start signal to SSEL. The SPI interface would collect 8 bits at a time, and deliver them to the firmware at a rate of about 32 kB/sec.