Viewing 11 posts - 1 through 11 (of 11 total)
June 19, 2018 at 10:05 am
I am attempting to enable a Lepton 3.5 to output 8-bit data from the AGC processor. I am using a PJRC Teensy 3.2 as the test platform and have ported the LeptonSDKEmb32OEM I2C driver to it (primarily dealing with the fact that the default Teensy compiler settings treat the enums used by the library as 8-bit instead of the assumed 32-bit). I have a reliable VoSPI connection using VSYNC on GPIO3.
I believe I am correctly communicating commands over I2C since I am able to enable the non-default VSYNC and I always read back what I write and the response matches the expected value. I can successfully get non-AGC data, however I do not seem to be able to enable AGC. Whenever I try, I still get 16-bit data.
My question is what, specifically, needs to be done to enable AGC with 8-bit output (either AGC algorithm) from the default state?
I am currently doing the following, but the data remains 16-bits:
– LEP_SetVidFocusCalcEnableState(portDescP, LEP_VID_FOCUS_CALC_DISABLE)
– LEP_SetAgcEnableState(portDescP, LEP_AGC_ENABLE)
– LEP_SetAgcPolicy(portDescP, LEP_AGC_HEQ)
– LEP_SetAgcHeqScaleFactor(portDescP, LEP_AGC_SCALE_TO_8_BITS)
– LEP_SetAgcCalcEnableState(portDescP, LEP_AGC_ENABLE)
– LEP_SetOemGpioMode(portDescP, LEP_OEM_GPIO_MODE_VSYNC)
from the specification (4.4.1 in 110-0144-04 Rev 200), I understand I must disable Focus calculations to enable AGC. I am setting some other values (such as SCALE) that seem to already be default settings.
I also ran a subsequent experiment where I enabled RGB888 output (and resized buffers accordingly). The data was incorrect *but* did seem to be affected in an expected way by changing the LUT in the Lepton (e.g. although the data displayed on an LCD was garbled, the overall colors matched the LUT).
I feel I must be missing some simple thing required to enable AGC. Anyone have experience with AGC?
June 19, 2018 at 2:29 pmParticipant
The datasheet says that even with 8 bit data the video format is 16 bits wide. Are you getting 16 bit values greater than 255?
June 20, 2018 at 8:29 am
I am still getting 16-bit Tlinear data. The upper byte contains valid data. Either I am not setting the correct value to enable AGC or (I wonder if) I am missing some additional setup required to enable it.
June 28, 2018 at 2:24 pm
I’ve been combing through documentation and the only thing I’ve seen that wasn’t already mentioned here is that T-Linear data is related to the RAD state.
From the IDD:
“4.7.9 RAD T-Linear Enable State
These functions either get or set the T-Linear output enable state. When enabled, the video output represents
temperature in Kelvin with some scale factor defined by the T-linear Resolution parameter. T-Linear mode requires
radiometry mode (temperature stable output) to also be enabled. “
LLEP_SetRadTLinearEnableState (LEP_CAMERA_PORT_DESC_T_PTR portDescPtr, LEP_RAD_ENABLE_E enableState)
with the enableState LEP_RAD_DISABLE will affect the data you’re seeing.
Here’s a link to the latest IDD for further reference: https://www.flir.com/globalassets/imported-assets/document/flir-lepton-software-interface-description-document.pdf
Section 4.7 contains information about RAD commands and may prove helpful.
July 1, 2018 at 11:20 pm
I tried the TLinear Enable control, both disabled (as you suggested) and enabled, seemingly without any effect (still 16-bit data coming out, and it appears the same in both cases). The spec claims the Lepton 3.5 has this disabled by default.
I will reread the IDD carefully again and see if I’ve missed something.
I think I will also add a feature to let me write any set of values with any length via the I2C in case [probably unlikely] the spec is wrong about the location and/or size of some parameter.
Do you know if the Lepton changes its operation immediately when a value is changed via the I2C interface? Watching the VSYNC signal come alive immediately after writing the OEM GPIO mode makes me think this is true, however perhaps other operational mode changes need some sort of trigger.
July 6, 2018 at 9:51 am
I will work on making sure, but I believe the Lepton changes its operation basically immediately when a value is changed via the I2C interface.
I’m a little stumped why you’re still getting 16-bit data. The only other thing I can think of, though unlikely that this is your issue, is that when reading from the camera Lepton registers are all 16-bits wide so only 16-bit transfers are allowed. Thus for 8-bit data, the first 8 bits are set to 0 while the remaining 8 bits carry meaningful data. Is it at all possible for something in your set up is somehow reading this in as meaningful 16-bit data?
I think your idea of adding a feature to let you write any set of values with any length via the I2C may help you troubleshoot better at this point.
I’ll continue to look into this and hopefully, we’ll be able to get you meaningful 8-bit data soon.
July 6, 2018 at 10:21 am
Thank you for continuing to research. I figured it out, but because of the holiday hadn’t updated the forum yet. Poking at the various commands was useful. It turns out, at least with the Radiometric Lepton 3.5, you have to turn off the Radiometric processing:
As soon as I did this, with AGC enabled, I got good 8-bit data. I was also able to switch on the RGB output processed through the built-in LUTs.
One additional question I have for you is what is the difference, if any, between enabling RGB888 output with the VID module as opposed to the OEM module?
Both successfully enabled output of RGB data.
July 6, 2018 at 10:39 am
Thanks for the update and I’m glad you got it working!
As for the difference between VID and OEM modules for video output format, to be honest, I don’t believe there’s a difference, though I will follow up and make sure of that.
The documentation seems to generally lean towards using OEM for setting video output format, but as you’ve discovered, they both work equally well.
July 6, 2018 at 10:58 amParticipant
Good to hear that you are up and running. I believe that both the video output format functions you cite are handled the same inside the camera. Looking at the enums in the SW IDD though, only the OEM version lists _RGB888 as supported. Being a stickler for detail, I’d probably stick with the OEM version.
July 7, 2018 at 7:35 am
Good points. OEM it is.
July 31, 2020 at 11:10 pm
Viewing 11 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic.