Decoding unkown signal

[Eheran]

I want to read data off the ADC in a 6000g scale. It only has a date stamp on it, so no further information there.
The microcontroller (MA801AE) has a mostly chinese datasheet...
The ADC goes in Pin 8 "ECI/T0/P3.4" and Pin 9 "CEX1/T1/P3.5".
I would like to decode it with my arduino to get external data-logging but i was unable to decode the signal with my scope.
Take a look at various screenshots with (mostly) no load as well as 2x ~4000g.
If you have ideas how to decode this please tell me all about it.
Or generally toss some information on how to decode unkown signals.

[2N3055]

Two lines, probably I2C protocol or some proprietary data/clock protocol... 
If it is bidirectional, probably something like I2C..

[Eheran]

Since I²C is in the scope and i tryed that... i dont think so.
The "decode line" is not even showing up there at all (the green B1 line), so i gues its a total mismatch.

[Andy Watson]

Can you change the output value by one bit and compare the change?

I think the chip is one of these:
http://www.megawin.com.tw/en-global/support/downloadDocument/136/296
But that probably isn't much help !

[2N3055]

It seems it is connected to timer-counter  or PCA module...
But it looks like SPI but with only   MISO data line...

[Eheran]

Change it by one bit? What do u mean?

[rstofer]

Add a dime to the weight...

[Brumby]

I want to read data off the ADC in a 6000g scale.

.....

I would like to decode it with my arduino to get external data-logging

I had exactly the same idea.  My scale was a 5000g one and I wanted to trigger data capture with a bar code scanner.  The idea being - put an item on the scale and scan it's bar code with the resultant UPC code and weight being captured and sent to the host.  On hand was an Arduino compatible 2560 ADK - and that's what I used

My approach, however, was somewhat less direct.  I monitored the LCD drive signals, worked out the scanning matrix and derived the display values from that.  The end result - it works!  I send data which I can capture using the serial monitor.

I really wanted to get data coming through as keyboard input, or possibly an application specific data stream, but other priorities got in the way - and I haven't looked at it for a couple of years now.

[Eheran]

I could read the data to the LCD driver and from there to the LCD too. But the first is a 3 channel signal that seems to be harder to decode (out of pins 12, 13 and 14, see picture). How to decode the actual data going to the LCD... no idea.

Add a dime to the weight...

The reading changes with or without any change in weight "all the time". This makes sense as the ADC has to have a higher resolution - otherwise the readings would be jumpy. 4 of these captured signals are without any weight on it, "no" disturbance, but tons of bits change.

Edit:
Removed 2 pictures, see my next post.

[Rerouter]

The data on those 2 is the exact same by my eye, what it looks like is I2C clock stretching, shift the image to make the second set of clock signals line up and it should look almost identical.

[hamster_nz]

Ok, completely blue skys thinking here.

Data bits are captured on falling edge. of the bottom signal (clock).

First image gives 00000001 10010011 10000011  1, last image gives 00000001 11000001 11010101  1

The last seems to be be a stop bit or something.

Convert the first 24 bits into a 24 bit number, most significant bit first.

First image 0x01 9383 
Last image 0x01 C1D5

Assuming the scale reads from 0 to 5000g in 0.1g steps it needs 16 bits of precision. The first byte doesn't seem to change. how about assuming that the first byte is an address word, that should give the middle bytes as the readings. That makes sense as most scales I've seen give a raw and net reading.

First image 0x9383 = 37763 decimal
Last image 0xC1D5 = 49621 decimal

Were the readings 3,776.3g and 4,962.1g?

If so, success!

If not, back to the drawing board for me...

[hamster_nz]

Oh, the other option is that 0x0193xx is the unloaded weight and 0x1c1d5 is the loaded weight, the difference being 11844 decimal (each count being about 0.33 of a gram)

I wonder if a ~2kg weight would give 0x01AAAC?

[Eheran]

Only the 4th picture was under load of that size.... The first had "no" load, only the scale structure itself.
Its 6000g at 0,1g resolution, so 16 bit is to be expected, yes.

The data on those 2 is the exact same by my eye, what it looks like is I2C clock stretching

Sorry, wrong time scale. Those were just the start-bits... 
Here is the actual reading, twice with "no" load and once (the third) with >1kg.

[hamster_nz]

Those messages look to be 20 bytes long (give or take),but given the small spikes on the third trace it could actually be multiple transactions. The data is too squashed up to tell much...

[Eheran]

I stitched 5 screenshots together, hope thats not too small now.

[matkar]

Make the readings for 0,1,2,3,4,5... kg and then compare if any of the data between packets changes linearly. Use a PC and a logic analyzer instead of oscilloscope since it will be easier to compare the decimal values directly. Make an excel table and plot some graphs to see the correlation between weight and readings.
Also experiment with different SPI modes, LSB/MSB first...