Reverse engineer SeekThermal protocol

[frenky]

So following this post about seek internals I have more intresting news.
https://www.eevblog.com/forum/thermal-imaging/yet-another-cheap-thermal-imager-incoming/msg963201/#msg963201

Today I captured stream (with Saleae) on both data lines from mcu to seek sensor.

As you can see at beginning some instructions are going into seek sensor (channel 0) and after that sensor is returning a lot of data (channel 1):



Control line goes high every 31.0715ms (32fps) and then sensor returns a short block of data followed by 156 bigger blocks of data. This are sensor horizontal lines for sure:



Each block (sensor line; 208 pixels) looks like this:

Total duration of this block is: 97500ns.

Single pulse length on average is 66,875ns.

So 97500ns/208=468,75 ns for a single pixel
468,75 ns / 66,875 ns = 7 bits of data?

Perhaps because sensor sends out 32fps that sensors values are cut in half? So it sends first 7bits of data in one frame and another 7bits in second frame?
I haven't gotten to the point of decoding data jet.

Here are a few first five seconds of data (Saleae format): https://www.dropbox.com/s/y1bfvrziilsa6cs/fromstart.7z?dl=0

Any help decoding this would be greatly appreciated. 

[joe-c]

Looks interesting,
but you note 3 Lines before:
- pin 8 goes to J2 and J4 (general IO)
- pin 9 goes to K2 (general IO)
- pin 12 goes to K3 (clock)
is Channel 2 the K3 line? i see nothing happens on channel 2...

btw: you may have a older version, here is the new:
https://www.saleae.com/downloads

[frenky]

Looks interesting,
but you note 3 Lines before:
- pin 8 goes to J2 and J4 (general IO)
- pin 9 goes to K2 (general IO)
- pin 12 goes to K3 (clock)
is Channel 2 the K3 line? i see nothing happens on channel 2...

btw: you may have a older version, here is the new:
https://www.saleae.com/downloads

I connected only two interesting lines because clock I guess is only a clock signal, so I did not bother to solder a bond wire to a really tiny trace which is really hard to reach and solder to.

- pin 8 goes to J2 and J4 (general IO) --> channel 0 in my Saleae capture; sensor input
- pin 9 goes to K2 (general IO)  --> channel 1 in my Saleae capture; sensor output

I know Saleae has a new version, but this one was already on my PC...   

[frenky]

Some more digging into data.

So I assumed that chunks of data are 7bit long.

This are first four lines of sensor data decoded with inkscape (manual labor). 


Chunks of 7bits with interesting (repeating) sequence selected: 

(I added one 0 in front of first line because it seems that it is missing...)

Looks familiar?

Of course it does...
Seek patent pixels:


Top left corner enlarged:


Getting very close to reading values directly from sensor.

[frenky]

I let seek stabilise for half an hour then captured data at approx the same time on pc app and on logic analyser:
https://www.dropbox.com/s/4p0v9npqto2dzx4/stable.7z?dl=0

I can't find relation between captured data and data that shows up in the app...

First 11pixels of lines 1, 2 and 3 from saleae:

0000001 0111111 1001001 0110101 0110111 1000001 0110111 1000011 1000101 0111000 0000001
0101111 0110011 0110001 0101011 0011101 0110000 0000001 0111011 0110111 0110111 0110001
0101001 0101100 0000001 0101011 0111101 0101111 0111001 0101111 0111101 0111001 0110001

Data received in app:

8280;3258;7093;8769;9052;6971;8006;6747;7668;7215;3
8496;6941;8506;8730;8248;7649;0;8404;6995;8452;7889
8456;8063;0;6981;7120;8430;7813;8950;8971;9020;8681

I tried to convert this numbers to binary to see if any 7 bits match 7 bit segments from sensor but no luck...

In last line there are values:
8456 (binary: 10000100001000) and sensor output: 0101001
8063 (binary: 01111101111111) and sensor output: 0101100
I inverted bits, reversed order... no match.

[joe-c]

...Control line goes high every 31.0715ms (32fps)...

maybe they send a MSB Frame and then a LSB frame, 7 Bytes each frame with 32FPS -> 14 Bytes Frames with 16FPS.

just a crazy idea 

[frenky]

I thought that too, but this data is just weird.
I took a look at data representing first line of 6 sequenced frames and then first line after 10 seconds and the data is always the same. It makes absolutely no sense...

In latest 10 seconds capture all first lines are the same, all second lines are the same, all third lines are the same.... wtf...
It's like seek was sending the same (7bit) frames for 10 seconds.

Perhaps I somehow missed third data line on pcb ?

[frenky]

Ok this is embarrassing.. 

I re-watched Mike's teardown video to find any missing information and found this:
https://www.youtube.com/watch?v=8Cr8oZck5m8&feature=youtu.be&t=1440

[frenky]

And found real data signal:



It's on the via that doesn't go anyhere?

(red arrows)

[joe-c]

And found real data signal:

could you decode something?

[mikeselectricstuff]

Ok this is embarrassing.. 

I re-watched Mike's teardown video to find any missing information and found this:
https://www.youtube.com/watch?v=8Cr8oZck5m8&feature=youtu.be&t=1440

Bear in mind that stream could be data going to the sensor- you'd need to insert a resistor inline to verify.

[frenky]

could you decode something?

I connected it to the scope to see which is least significant bit (it changes all the time) and came to conclusion that the first word is 12bit long and the following are 14 bits long.

But when I put my finger in front of seek the values did not seem to change noticeably.

So as Mike said this cold be line going into the sensor. It is very had soldering wires to seek.
Just for a reference...
Vias are 0.5mm in diameter and often only 0.1mm apart. And traces are about 0.1mm thick.