Flir Lepton 3 Camera SW and temperature measurement

[TomH]

Hi. all,

I'm using Flir Lepton 3 with Pi 0. The SDK is LeptonSDKEmb64PUB posted around July 2017.

I pack a set of 160x120 pixel value read from valid segment into a linear array called  frame buffer[19680].

This frame buffer should contain the individual pixel value above or below 8192, according to the sdk and datasheet. Using best curve fitting mechanism, some users have come up with a best curve fitting equation to derive a coefficient of about 0.0217. This will help plot out a series of pixel values. And the equation for converting the pixel value into a temperature in Celsius that I adapt to use is:

compensated_tempC = 0.0217 * (frameBuffer[i] - 8192) +

                                                   (k_temp/100) - 272.15)                                         

For example, 0.0217 * (8290-8291) + 304 - 272.15 = 2.126 + 304 - 272.15 = 33.98 degree C.

0.0217 is the curve fitting coefficient. The index 'i' is the location of the pixel within a frame.

In the second term, k_temp is the camera temperature (in scale of 100) obtained from sdk function LEP_GetSysFpaTemperatureKelvin(). And it subtracts the constant value to get Kelvin to Celsius conversion (1K ~= -272.15 C). ie., k_temp of 30400 represents 304 Kelvin.

Now I point the camera centered to the dull grey color target having a temperature about 36 C measured by an external temperature gauge. And I observed over an hour. The k_temp varies around 30250 +/- 70. And the frameBuffer[i] value varies around 8250 +/- 70.

Ideally I should see the result of this equation rendering 36 C +- 1 degree (that's a precision I care). Well, the result from the equation is only 34 degree C!

For every 80 seconds I call the sdk to do FFC calibration.

Nevertheless, I don't know if the frameBuffer[I] or the k_temp value or both is off for some reason that might have cause to render lower result value. Any takers to explain?

Tom

 

 

[TomH]

Sorry. there was a typo and I correct it as followed:

For example, 0.0217 * (8290-8192) + 304 - 272.15 = 2.126 + 304 - 272.15 = 33.98 degree C.

( it was 8290-8291)

dah!

[Myzhar]

Hi Tom,

first of all I must say that you should replace "272.15" with "273.16" that is the correct value for the "Absolute Zero".

Have you tried to perform the same calibration enabling the Radiometry?
When you are in Radiometry mode the sensor values should not depend on environmental temperature, so you can get a better accuracy.

The formula you are using is valid for sensor without radiometry, since you have a Lepton3 you can use this useful mode.

[TomH]

Hi. Myzhar,

Good to hear from you again. I reviewed the data sheet and sdk source files further more. Enabling Radiometry mode is rather involved with OEM, licensing, etc..., and requires a special sdk. One user from github mentions about radiometry as well.

Tom

[Myzhar]

You can enable radiometry without using the SDK, simply writing your code to send the "I2C" command to the camera. 

This is a good starting point:
https://github.com/lukevanhorn/Lepton3/blob/d47266f9e047a1af826e1a9f218695b592b780b1/control/control.c

[TomH]

Well, I use control.c and did:

writeData(LEP_MOD_RAD, 0x10, tx_data, 2);     // the cmd ID is 0x10, per Lepton SW IDD note

readData(LEP_MOD_RAD, 0x10, 2);

   but   printf("RAD state: %d\n", rx_data[3]);    has  0 (not enabled) in rx_data[3]

T...

[Ben Kluwe]

Hi Tom,

does your code set the "dirty" oem bit according to section 4.7.1 in the SW IDD?

Best Regards,
Ben

[TomH]

Yes. Ben,

line 198 in control.c has this to set the OEM bit:

/* set the oem bit if necessary */ if (mod == LEP_MOD_OEM || MOD == LEP_MOD_RAD) { command[2] |= 0x40; } Monday, I'll peek into the TWI line to see the command stream of 4 bytes. But I wonder if the author of the file has tested at least the code like that in the main.c I simplified the control.c so that it does the job of enabling Radiometry mode only. Tom

[Ben Kluwe]

Hi Tom,

if you copy pasted that code and no formatting or anything else was applied then I've spotted a small problem, once you use mod and once MOD in the if statement. Seeing as you are trying to turn on the radiometry mode, MOD might not be set and therefore it will never equal LEP_MOD_RAD, therefore never setting the oem bit?

Otherwise it may also be possible that the txdata contains a 0 instead of a 1 due to endianess?

Ben

[TomH]

Sorry. Ben,

I had a typo (suppose to be 'mod', not MOD). I rewrote the if statement and did not copy and paste from the original code to this post. 

I had a function that calls the original writedata(). The first argument is 'mod' that has a #define for the module ID 0xE0.

Then the if statement is inside the writedata() function to check the command ID 0xE0 given. If matches then it set the OEM bit that I have identified its position in the datasheet.

I'll scope out the line and see if I can read back the entire register content to check the OEM and RAD bit.

Thanks for the reply. I'll post my findings later.

Tom

[Davide Aguiari]

@TomH:

I'm using Myzhar's code at the moment that supposed to use the last SDK.

I turned Radiometry on with enableRadiometry(true) that uses LEP_SetRadEnableState( ... ).

So the loop uses raw2data16() since AGC is disabled BUT when I read uint16_t value = frameBuffer[i], those are around 3000-4000 and not around 8000. Do you know why? :/

Actually I'm still wondering if Lepton3 has actually radiometry in order to read temperature...
According to the specifications (http://flir.com/cores/lepton/) Lepton3 has N/A radiometry accuracy. Even in DIY-Thermocamera github they say "When using a radiometric Lepton (Lepton2.5 only at the moment), the spot sensor is not required.". Really?! Did FLIR remove radiometry from the newer Lepton3? This guy (https://groups.google.com/forum/#!topic/flir-lepton/rw02hxnCJ4A) claims he succeded in getting temperature with Lepton3 but he didn't share the code..

[Ben Kluwe]

Hi Davide

if the values are between 3000-4000 and AGC is disabled then you have radiometry on, divide the number by 100 to get degrees celsius. As far as I can remember thats what it is. If you don't trust the data you should make a gui where you can manually en- and disable the radiometry mode and read out a pixel area/the center pixel with every image and see what happens to the value.

Maybe this could also be interesting for Tom because it could be that the lepton isnt reporting its radiometry state correctly, maybe @TomH should check the actual values and see if the range changes. I recall that for the reboot command, the leptonsdk returns -26 or 0, i.e. Everthing ok or an Error, but the sensor reboots and is works regardless.

Ben

[TomH]

Ok. Guys,

I'm well aware of the OEM bit and big Endianess mentioned in the Lepton datasheet.

I might as well use the SDK that has a function LEP_SetRadEnableState(&_port, LEP_RAD_ENABLE). And it works!

Once I know that I can scope out the data line for the command stream. This way I can compare the command stream with that from the control.c.

The raw data value reading from the frame buffer is just what you guys found -- 3000 to 4000 depending on the heat source. Attached is an image snapshot of my camera setup. (I still need to calibrate the color bar later).

As in my previous design, once the data stream is out of sync I make an attempt to reset the camera. This used to work when the radiometry is not enabled. But now upon detected the out-of-sync, I do the sequence -- close SPI, next reboot, then disconnect then reconnect TWI and SPI, finally call SetRadEnableState() again (needed after camera reboot). Well, the SetRadEnableState() DOES NOT RETURN!

Perhaps it's time to use the GPIO3 as a signal for reading data stream synchronization...

Tom

[TomH]

More trouble about the reboot...

Since I set the OEM bit when enabling the radiometry. I take it that the bit stays set. So I tried the LEP_RunOemReboot() but it returns error -26 (LEP_ERROR_I2C_FAIL defined in error.h).

Then I tried OemPowerDown() that returns 0, that's good.

Some small delay later I do OemPowerOn() that returns -1: camera general error.

Then I tried LEP_RunOemBit() that I don't it returns the bit value.

More about the temperature value -- I use a close-loop variable controlled uniform heat source on a dull grey plane. In radiometry mode the frame buffer output is about 3 degree C higher.

I wonder if I should run the LEP_RunOemFFCNormalization...

Tom  

[Ben Kluwe]

Hi Tom,

I suggest you search this forum a bit more for how the temperature calibration is done and the reboot command, several topics about this already exist. For example, the function LEP_RunOemReboot returning -26 is normal, the lepton does actually reboot, I have gotten this to work in the past and written a few posts about it.

Ben