Is there a description of the known SPI issues?

[PeterAJansen]

Thanks for creating this fantastic resource!

The readme lists known SPI issues that would be ironed out in a 1.0 release. Is there a description of what these issues are? I just gave this a try on the ESP32 Arduino port and don't appear to be receiving image data, and I'm trying to figure out where to start debugging from.

thanks

[djl62490]

I'm having the same issue as PeterAJansen.

When attempting to write to an SD card I get the following errors:

LeptonFLiR::readNextFrame Failure allocating telemetryData.
LeptonFLiR::readNextFrame AGC-8bit: enabled, Telemetry: disabled
LeptonFLiR::readNextFrame Maximum resync retries reached. Aborting.

Do you have any suggestions where to start looking to debug?

[NachtRaveVL]

Hey, thanks for commenting everyone. =)

This was actually the best that I was able to originally do with the microcontrollers available at the time, of which the fastest I had access to was the Arduino Due. The error that you're seeing is basically a de-sync, in which the SPI data transfer did not succeed in the time allotted for a single frame.

The issue is mainly because of the way I had originally coded this, which, in the end, proved to be a failure. =(

The reality is that the exact second that you know you have the start of the actual data frame (i.e. when you 'sync'), you need to get that SPI data transfer going ASAP, and reading for not just that single frame packet, but the total number of expected packets (based on a variety of factors, such as telemetry mode, color mode, etc.).

The current implementation is to just read a single data packet at a time, which proved to just be too slow to successfully do on anything that isn't in the realm of ESP32 / Teensy 3+, and more recently the Teensy 4.

Additionally, the v1.4 breakout for these cameras missed a vital pin that can enhance this process of 'syncing', in which the newer v2 breakout includes a pin that can act as an interrupt line to instruct the chip to begin the SPI transfer process. Such an ISR would actually be quite useful in trimming the amount of time the processor has to otherwise spend cycling SPI data discard packets waiting to sync (or defined more precisely, when the ID tag (first two bytes) on the data packet doesn't come back 0xFFFF).

I additionally didn't code this in a way that fully understood the image requirements, in particular that the LUT modes, which change the frame-packet size, was originally set to just the standard 164 bytes and not as a dynamic function of color mode. With the LUT tables, and additionally now with the v3 and v3.5 cameras that have 2x the image size, the transfer mechanism there has only gotten more complicated, and will need to be completely re-written.

Once I finally reached coding in the extra i2c functionality, couldn't get more than half-a-frame of data before it would de-sync, and I saw that I would have to go back and change a lot of the way I had originally did things, I abandoned the library and hadn't really considered doing much on it.

More recently though, especially with the release of the 600 MHz Teensy 4 (apologies, I'm probably late to the game on this - life and all), I feel that the SPI data transfer speed have probably caught up, and we might be able to start seeing an actual data transfer succeed. I've picked the library back up in my spare time, and will probably do a bit more work on it when I have the spare time.

Hopefully this provides a lot more detail as to what the issue was and what the situation with this library has been for quite some time.

[NachtRaveVL]

Oh, one more thing I forgot to mention...

Another thing you have to contend with is the way in which the SPI data transfer speed is selected, and the eventual way the speed is selected. Since this usually means that you’re dividing the clock processor speed divided by factors of 2, the speed the SPI transfer comes down to also plays a role.

The maximum SPI clock speed of the FLiR is 20MHz, so if you try to calculate out the first clock divisor that’s a factor of 2, and at or under the 20MHz, you wind up with a rather unique set of values that doesn’t always make faster = better.

For instance, Arduino Due has an 84MHz clock, and if you keep dividing that by 2, you eventually will land at 10.5MHz being the first factor of 2 divisor that is under 20MHz. That is, of course, literally half the maximum speed, which means it’s going to take twice as long as the maximum speed would imply. However, say you go to a 72MHz chip, like Teensy 3.2, the SPI speed you’ll land on is 18MHz, which is a far shot ahead of the Due despite the overall clock speed being lower. Likewise the faster 96MHz setting of the Teensy will divide down to a slower 12MHz. The 600MHz Teensy 4 will however divide down to 18.5MHz, which is even closer to that 20MHz. Likewise the 240MHz ESP32+ divides down to 15MHz, while the 180MHz ESP32/Teensy 3.5/3.6 line divides down to 11.25MHz.

So as you can see, there is a bit more complication with this all due to clock divisors and the way the Arduino subsystem there works.

(Supposedly the Due was suppose to offer a custom SPI interface whereby clock divisors didn’t need to be factors of 2, rather just consecutive integers, which would had allowed its SPI speed to be set to /5=16.8MHz, but it seems that that support was weirdly messed up or not working when I was doing my testing way back when, I think around the time they started doing the SPISettings struct to determine SPI speed - again, another thing that I had to neglect at the time since it was failing to build properly)

[ZePedro80]

Hi there. How can you use this library (https://github.com/NachtRaveVL/Lepton-FLiR-Arduino) in a Lepton 3.x (160x120), if it only treats 80x60 pixels?

[NachtRaveVL]

Hi there. How can you use this library (https://github.com/NachtRaveVL/Lepton-FLiR-Arduino) in a Lepton 3.x (160x120), if it only treats 80x60 pixels?

I'll look into it in #14. I wouldn't think it would, but take that response with a very large grain of salt.