Reverse Engineering: Data Transfer of Standing Desk (SPI?)

[tim-hilt]

I want to understand the data-transfer between the control-panel and motor-controller of my standing-desk. The control-panel is connected to the motor-controller via an 8 wire cable that ends in an RJ45-plug. I connected a logic-analyzer (Saleae Logic Pro 8 ) to the wires and got to the following conclusion:

1: Chip Enable
2: MISO
3: Clock
4: 5V
5: GND
6: GND
7: 5V
8: 5V

So I'm pretty sure it's SPI and I already could decode the data via the Saleae Logic 2 software, but there are a few things, that I just don't understand:

• When the control-panel is idle (display off), the signal is about a 1000 times slower and chip-enable isn't low for an entire frame, but only briefly (see attachment). What is this mode called?
• The signals I observe aren't changing that much, when I heighten or lower the desk. They do change, when I press and release the buttons though. That's why I think wire 2 is MISO. But how does the display know which height to show? I can't imagine, that this is all done on the control panel
• Could it be, that I'm looking at another protocol that is working bi-directionally?

The attached images show:

• The transition from idle to active (idle-to-active.png)
• The "activation part" where the signal wakes up and seems to do some setup-stuff (activation.png)
• An active frame with no button pressed (active-frame.png)
• An active frame with button 2 pressed (button-pressed.png)
• My SPI settings

Please don't hesitate to tell me if I'm doing something wrong regarding the format of this post - it's my first post here.

[HwAoRrDk]

You're using the wrong clock phase on your decoding. It's obvious from the waveforms that the data is valid on the falling edge of the clock. At the moment you're sampling on the rising edge, which appears to actually come just before the data transition, so your decoded values will be wrong.

[jwet]

Agree with last poster, data is valid on negative edge of clock, otherwise there is no setup.  Your 52,85,0,7F  should be A1,85,0,7E.

Here are my guesses- play around once you get Salae capturing proper clock edge.

The A1 might be an address or a preamble- do all strings start this way?- "A"-1010 is somewhat common here.
The 85 is likely a command (up / down? )
The 0 is the data payload (one of the messages captured had a 20 here and 4th byte (cksum) changed by that amount.)
The 7E is a checksum though I don't know exactly where it starts and what gets summed- it seems to be a simple sum vs. a CRC, etc.

Map out how many "states" the controller can send by experimentation.

A few buttons and a 35 cent micro could and usually does implement something like this.

The slowing down of sending data is an "non active" or "idle mode", it lets all the power stuff just turn off and hold position to keep heat down.  If you're messing with the buttons, it will stay up but will then time out.  It could be that the first data with the zero payload is a "wakeup" and is ignored.

Notes-
5's and A's are generally good 4 bit numbers to use in binary protocols- they are 0101 and 1010 as binary nybbles.  AA,55,A5 and 5A are common.
The above can capture some common errors where the bits can't flip high and low at the right speed.
Zero's are often used for null data payloads and sync bytes esp with cksums - they're not great because they don't change... middle of packet only
The control scheme may send 0, positive or negative (2's comp) type values - "0" Wake Up, do nothing "+" Go Up x units "-" down x units

All just guesses- have fun.  Have you looked on line for anyone that may have hacked in the past?

[JustMeHere]

This might not be SPI.  Since it looks like there's a device address being sent, your "CS" might just be an interrupt.  This might be I2C.

[jwet]

I'm not seeing "start" and "stop" type I2C sequences- are you?

[JustMeHere]

I'm not seeing "start" and "stop" type I2C sequences- are you?

You're right, never mind.