Electronic – Decoding a Two-Wire SPI-esque Serial Protocol

oscilloscopeprotocolreverse-engineeringserialspi

I'm working on a project that involves the optical sensor from a mouse. I've got the original control PCB (still populated, save for the optical sensor itself), and I've got the optical sensor on my custom PCB, supposed to be controlled by an nrf51822. I've wired the clock + data pins (it's a two-wire interface) to both boards, driven by the original control board (I've set my clock and data pins as inputs with no pulling resistors).

I'm trying to capture traffic to determine what signals are being sent, but I'm not having a lot of luck – I suspect my clock rate is too low. As quickly as possible (just inside a while true loop), I'm scanning my clock pin and my data pin, then printing them both to my console output over UART at 1M baud. Running this loop empty for 5 seconds results in ~4000 cycles, meaning I'm getting >1ms run time for each loop – which I think is my main problem.

As it is, I capture (in roughly 700 scans) 100 groups of alternating "clock 1 and data 1" and "clock 0 and data 0" – each group is 4-9 items (that is, 4-9 "1s" on both, followed by 4-9 "0s" on both). Then, about 400 scans later (~0.5 seconds) I get the same thing, but 54 groups. At that point I stopped scanning.

Is there any way to either:
A) Speed up my scan cycle so I can capture the traffic more accurately?
or
B) Decode what I already have (doubtful)?

Do I need to consider an alternate route? I haven't found any access to an oscilloscope, which is… unfortunate.

I'd appreciate any advice. Thanks.

Best Answer

As Chris Stratton indicated in his comments to the other answer you need to change the way your software works.

There are two options:

Option 1:
Run in a tight loop polling the pins and recording a timestamp into a buffer when they change state. If the value hasn't changed don't do anything.
Once the buffer is full output the times recorded over the serial link.

Option 2:
Use the serial and clock line inputs as interrupts. When the pins change record to a buffer a timestamp for the transition and the new state of the pin.
Have a background loop send the logged data out on the serial port keeping up with the data as best it can while indicating if the buffer has overflowed.

Both of them solve the big issue that you have that you are trying to output serial data from within a time critical piece of code, printf is slow and serial ports run at a glacial pace, never do them in a section of code that you need to run quickly. Option 1 is simpler and will probably cope with slightly higher frequencies but will only record for as long as you have space to buffer and could possibly report two edges very close together as being in the wrong order. Option 2 outputs while it's running and so should be able to run for longer (whether it's 1 edge more or keeps up and runs indefinably depends on the speeds of the edges and the serial port) but due to the interrupt overhead will have a lower top speed and is more complex to code.

The other obvious solution is to borrow / rent an oscilloscope or logic analyser from someone.

Related Solutions

Electronic – Transmitting ASCII ‘A’ over SPI Protocol

SPI devices also typically have a chip-select signal (sometimes referred to as a frame sync) that is used to multiplex devices on a single SPI bus. Thus, SPI is often referred to as a 3-wire or 4-wire interface (MISO, MOSI, CS, and CLK; for unidirectional devices, either MISO or MOSI can be omitted). A frame is typically assumed to start at the first bit after the chip-select signal is asserted, but every device has its own protocol. You'll need to adhere to whatever the other side of the link expects.

Electronic – Determining command constants for serial protocol design

The word is Hamming Distance, which is the number of symbols different between any two codes. If you would use any possible combination of an 8-bit code your Hamming Distance is 1: a change of just 1 bit will give you new valid code. That means that even 1-bit errors can't be detected, less corrected.

Now take the Hamming cube:

enter image description here

Here there are only 2 valid 3-bit codes: 000 and 111. The Hamming Distance is 3, which means that less than 3 bit-errors can be detected. Single-bit errors can even be corrected: if the code should be 000 and you have 001, that's a single bit. If you measure the distance in the cube to the two valid codes you'll have to follow 2 edges to arrive at 111, but only 1 edge for 000. So it's either a single-bit error, and then you can correct it, or a multiple-bit error, like, which you can detect (because it's not a valid code) but not correct (you don't know if it should be 000 or 111).

A long time ago a watched a BBC Open University program on coding where they explained how a Hadamard Matrix provides a list of codes with a Hamming Distance of n for a 2\$^n\$ \$\times \$ 2\$^n\$ matrix. The construction of a Hadamard matrix is interesting in itself, and a nice programming exercise. Start with a single bit:

now you make a matrix of 2 by 2 bit, following this rule: copy the 1 in all quadrants, except bottom right, where you place the inverse:

1 1
1 0

Next level (this is a recursive algorithm) you apply the same rule to the 2 by 2 matrix, so that you get a 4 by 4 matrix. In each quadrant you copy the previous matrix, except the bottom right where you invert it:

And so on. At the next level we'll have 8 codes (lines) with a Hamming Distance of 3:

1 1 1 1   1 1 1 1
1 0 1 0   1 0 1 0
1 1 0 0   1 1 0 0
1 0 0 1   1 0 0 1

1 1 1 1   0 0 0 0
1 0 1 0   0 1 0 1
1 1 0 0   0 0 1 1
1 0 0 1   0 1 1 0

You can extend the Hadamard Matrix as far as you want. If you want to detect up to 6 bit errors you'll have a 64 by 64 matrix. This kind of forward error coding is used for instance in space communication, where the distance of the spacecraft may be so large that the signal becomes extremely noisy. The fact that there is only a limited number of valid codes, despite a long code length, allows detection of a signal below the noise floor.

Best Answer

Related Solutions

Electronic – Transmitting ASCII ‘A’ over SPI Protocol

Electronic – Determining command constants for serial protocol design

Related Topic