Serial protocol decoding

[MrVee]

Hi There,

Who is up for a game of guess the serial protocol? I am hoping someone might recognize or be familiar with this synchronous serial protocol on the Oscilloscope screen shots attached. My initial though was I2C, however the clock should be high when not running is my understanding. It isn't SPI as there is no chip select wire (just clock and data).

[TK]

What is the frequency of the clock?

[MrVee]

It is quite slow ...(not that it helps  )
Around 400hz if I remember seeing correctly? I will check that in the morning.

[Rerouter]

Not I2C, that would idle high.

I would say spi with a hard wired select line.

[MattHollands]

Some context may be useful.

1. Which two chips does this bus connect? Some protocols are application specific, eg. protocols for controlling power management chips
2. What is the product? If it's some cheap toy then it may just be a made up protocol
3. Are there other devices on the bus? If there are multiple devices on the bus then there must either be some kind of address included in the packet, or a chip select wire (which you say there isn't). Another option, if this is a daisy chained system where the message is passed along.

[MrVee]

Thanks for replies,

Matt,
Its a load cell indicator with clock & data output pins that would normally connect to the manufacturers peripherals such as a printer or a data-logger. The indicator also has a 0-5v analog output that we normally use however the idea here is that I would be able to use the digital data for my own datalogger. At this stage I am not prepared to open the case as the unit is very expensive and not mine... so I don't know what chip is driving this output. (Normally its the first thing I do, pull the case off, but with this one I have to be careful).

The only data I do have is the pinouts of the rear connector of the unit (Data Out and Clock), so definitely no chip select. Normally this data and clock would wire into a printer or other proprietary peripherals but I do not own or have access to any of these devices.

Unfortunately my hands are tied in some ways on this project as I can't dig in too much and am limited to sniffing the output. I do realize this may be a proprietary serial interface, in any case if this isn't doesn't jump out at anyone... I'll have to take a different approach.

[MattHollands]

Even if it isn't a standard serial interface, you can probably figure it out. In the two screen shots you've given, neither the first 6 bits nor most of the second half changes. Is this a consistent thing?
Can you correlate the remaining bits with the data being sent? Ie, if you put more load onto the load cell, does this binary number increase?

[MrVee]

Okay so here is the deal

The first 6 bits and the last half doesn't change.

You notice on the second screenshot, the pulses after the first 6 bits are: 0000100001000010001...etc (evenly spaced highs), in this instance the load cell is indicating 0. In the first screen shot it is indicating 578.

Now when you increase the load by 1 unit you get the following changing sequence (the bits after the first 6 bits):

For 0 Bin = XXXXXX 00001 00001 00001 00001 ...
For 1 Bin = XXXXXX 10111 00001 00001 00001 ...
For 2 Bin = XXXXXX 00010 00001 00001 00001 ...
For 3 Bin = XXXXXX 00110 00001 00001 00001 ...
For 4 Bin = XXXXXX 10100 00001 00001 00001 ...
For 5 Bin = XXXXXX 01100 00001 00001 00001 ...
For 6 Bin = XXXXXX 01000 00001 00001 00001 ... 
For 7 Bin = XXXXXX 00111 00001 00001 00001 ...

Very strange sequence

[MattHollands]

\i don't recognise the pattern, but seeing as there are only 5 bits it won't be hard to put that in a look up table. Assuming the following groups of 5 bits also follow that pattern you can decode those the same

[Rerouter]

It looks like your slightly off. Data changes on the rising edge and is likely read on the falling edge.

Image 2
011111 00000 00111 01100 00001 00101 0000010111

So image 3
011111 00001 00001 00001 00001 00101 0000010111

Now at a guess image 3 is unloaded and image 2 has some midscale weight on it.

At a guess i would say you have 2 bytes in the middle that mean anything. Drop the last bit from each block of 4. And arrange them into a 16 bit integer.

Some more screenshots at know weights would be more telling. E.g. how much does your bin weigh.

[MrVee]

Rerouter, I think you are right, since the data is stable on the falling edge.

TK, I can confirm clock speed is 400hz.

I have attached some images at various weights.

So, I think we can all agree that the first 6 bits are junk or an address that doesn't change. The next 20 bits are interesting. At 0LB indicated they are 4x sets of '00001'. As Rerouter mentioned if the 1 is removed then you get 16 bits which would make sense as an unsigned integer (I say unsigned because this will only ever indicate positive numbers by design, negative numbers are indicated as 0LB). When I played with certain settings such as damping it would change the remaining bits so they must give certain settings.

Changing from KG to LB didn't change the output, so this means that if the screen is showing 100kg or lb it is just printing 100.

[MrVee]

I just noticed,
|Ones | Tens |H'rds|Thou's|
00001 00001 00001 00001 = 0
10111 00001 00001 00001 = 1
00010 00001 00001 00001 = 2
00110 00001 00001 00001 = 3
10100 00001 00001 00001 = 4
01100 00001 00001 00001 = 5

00001 00001 00001 00001 = 0
00001 00001 10111 00001  = 100
00001 00001 10100 00001 = 400
10111 00001 01100 00001 = 501

00001 10111 00001 00001 = 10
10111 10111 00001 00001 = 11
00010 10111 00001 00001 = 12
00001 01100 00001 00001 = 50

I don't understand what the thinking is behind the bit arrangement... with 4 bits you could easily represent 0 - 9  using binary counting