Wrong image values / strange rollover

[ItayKishon]

Hi,

I'm trying to read the complete 14 bit values, yet it seems there's a strange bug which somewhat corrupts the pixel values. While the 'usual' pixel value is supposed to be 8192 when the scene is at the same temperature as the Lepton (according to https://cdn.sparkfun.com/datasheets/Sensors/Infrared/FLIR_Lepton_Data_Brief.pdf, sec. 8.4.1), I'm getting about half of that. Yet, it's not just a simple bit shift. Something weirder is going on - there seem to be value rollovers, which means that the acquired image value are non-continuous. Here is an example, showing the decimal & binary values of a certain pixel, for a steadily & monotonically increasing temperature: (specifically, look at the rollovers of 3903->4032, and 4099->4348)

... 3901 00001111,00111101 3902 00001111,00111110 3903 00001111,00111111 4032 00001111,11000000 4033 00001111,11000001 4034 00001111,11000010 ... 4093 00001111,11111101 4094 00001111,11111110 4095 00001111,11111111 4096 00010000,00000000 4097 00010000,00000001 4098 00010000,00000010 4099 00010000,00000011 4348 00010000,11111100 4349 00010000,11111101 4350 00010000,11111110 4351 00010000,11111111 ...

The temperature itself ranged from a bit under room temperature (and that of the sensor), to a bit above it. That is - the values were supposed to be continuous, around 8192.

The problem is (mostly?) apparent in the low byte, which seems to act somewhat like 2's complement. That's weird, because looking at your code I found only use of uint16.

I know the camera is operating correctly as I've used the 'official' program from PureEngineering and it behaves exactly as expected.

Thanks. Your module is very useful! Itay

[kekiefer]

Thanks Itay, this is very interesting and odd. I presume that this something that happens during continuous capture? If you power off the module and do a single frame capture, does it return data as expected?

There's a line counter in there which returns values from 0-59 (in the LS first 12 of 16 bits of a line), and there's also a CRC that is computed against that counter (second 16 bits), and I wonder if that's what we're seeing here.

If not keeping up with real time demands of the module (which we are just barely now in Python), we can pretty easily get out of sync with the driver and start getting crazy data. For example I've had issues re-allocating the capture buffer every time.

Another thing I noticed the other day is that the SPI Mode is set wrong (0, which was not set in the original C program), where according to the docs, it is supposed to be 3 (CPOL=1, CPHA=1), so we could be clocking out data with the wrong polarity on the wrong edge, arg! Strangely an fortuitously, this setting must be ignored by the driver. It might be worth changing that though.

Please let me know if you learn any more. When I've got a chance soon I'll do some investigation too.

[ItayKishon]

Got it!

You're right, it was the SPI mode. I tried setting it at 3, but got garbage. The magic number is mode 1, i.e. the trailing edge.

I'll do some thorough testing tomorrow, but right now it seems to have solved this sync problem.

Thanks so much!

[kekiefer]

Are you on a Raspberry Pi or some other platform with spidev?

[ItayKishon]

I'm using RPi 2, running Raspbian 8 (Jessie). What would you like me to check?

[kekiefer]

Just checking. Please let me know if this continues working for you. Mode 2 is CPOL=1, CPHA=0, which isn't quite what the datasheet calls out. Considering that this was basically working with CPOL=0 before, I'm still a little confused by this.

[kekiefer]

Hey Itay, I pushed a couple fixes to improve throughput and reliability (just to avoid potential issues there) and set SPI mode 3. This is working well for me and I have values in the correct range. Please let me know if you are still having problems.