LEPTON 3. Broken segment id in row data?

[Konstantin Shabalovski]

Good day. I wirked with "Lepton 3" on board based on IMX6.

Of the manual writen "For video packets, the header includes a 2-byte ID and a 2-byte CRC. The ID field encodes the segment

number (1, 2, 3, or 4) and the packet number, both of which are required to determine where the packet

belongs in relation to the final 160 x 120 image (or 160x122 if telemetry is enabled)."

But I am try read raw data and found that: not al data have segment id in range 1..4. Most of data have segment id = 0. Segment id read from 20th packet of segemnt. Tracelog:

p=20 s=0

p=20 s=0

p=20 s=1

p=20 s=2

p=20 s=3

p=20 s=4

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=1

p=20 s=2

p=20 s=3

p=20 s=4

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=1

p=20 s=2

p=20 s=3

p=20 s=4

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=1

p=20 s=2

p=20 s=3

p=20 s=4

And my framerate slow down to 8.3 FPS. May be that from this (by manual):

"The segment rate is approximately 106 Hz, which equates to a frame rate of ~ 26.5 Hz. However, the rate of unique and valid

frames is just below 9 Hz to comply with US export restrictions. For each unique frame, two partial and invalid

frames comprised of segment 3 and 4follow in the VoSPI stream."

I guess correctly?

[sa...@pureengineering.com]

images are repeated 3 times, so the extra 2/3 data can be thrown away, but this data still needs to be read out without getting out of sync.  It is key not to get behind and drop even a single image, if you do so, you will get out of sync and see 0's like you are seeing, you have to resync if this occurs with a 185ms dead time. 

A number of things could cause this, especially if you are using an OS such as linux. For example running garbage collection could be enough to push timing so that you go out of sync. I would look at using pthreads and verifying you have RT scheduling enabled so you don't get swapped out at the wrong time. I think you can call set_realtime_priority(); in a pthread to get real time scheduling. 

[Konstantin Shabalovski]

I resoved my problem. Conclusions:

1.  Only each 3-th frame - have right segment index. On other frames number segment - zero.

2.  Writed spi driver for hardware (IMX6). And have  0...5 droped(corrupted) frames on 5 minutes. It is be less, but need analys IRQ. May be MMC dirver too long hanlde IRQ.

3. Real framerate  is ~8,7 FPS.

[Termografi-ekspert Henrik Quist]

[Henrik Quist]

Hi Konstantin,

We are seeing the same problem - can you share your solution, please

[Myzhar]

Try my code:
https://github.com/Myzhar/Lepton3_BBB

it's a project for BeagleBone Blue, but you can use it on any other Embedded ARM Linux board

I can save MPEG video at 9 FPS without losing sync.

Walter

[Menno Smits]

On Tuesday, September 12, 2017 at 9:51:43 PM UTC+12, Henrik Quist wrote:

Hi Konstantin,

We are seeing the same problem - can you share your solution, please

As per the reply from Pure Engineering, the pattern of segment numbers described in the original email is completely expected. Any segment with a number of 0 needs to be ignored. This is documented in the data sheet.

- Menno

[Henrik Quist]

Thank you for sharing - we will test ;-)

[Thomas Søhus]

Hi Walter,

Thanks for sharing your code. We need to update the SDK to use a different I2C port, which requires access to the SDK source. We used the SDK downloaded from FLIR, but it seems to have some missing functionality like get/set AGC, Radiometry etc. Do you kwno where I can get the most recent Lepton SDK which enables me to update the SDK to match your code?

Thanks,

Thomas

Den onsdag den 13. september 2017 kl. 11.25.04 UTC+2 skrev Myzhar:

[Walter Lucetti]

Hi Thomas,

I updated it yesterday evening for the same reasons. I downloaded the latest SDK 32bit with radiometry, then I removed all the references to "Windows" files and added the code to access to BeagleBone I2C driver.

The SDK is available here: 
https://lepton.flir.com/sdk/

You need to register to download.

To compile the code you need to remove the files:
aardvark.dll
aardvark.c

ftd2xx.h
aardvark.h
libMPSSE_definitions.c
libMPSSE_i2c.h

You also need to modify "Makefile" removing 
$(OUTDIR)/aardvark.o
$(OUTDIR)/FLIR_I2C.o 
$(OUTDIR)/libMPSSE_definitions.o
and adding the code for your "I2C" driver.


To use your "I2C driver" you must remove 
#include "FLIR_I2C.h"
in the file "LEPTON_I2C_Service.c"
and include the I2C command of your board

The functions to be implemented are the same as in "FLIR_I2C.h"... you can get them looking at these repositories:
Rasberry: https://github.com/groupgets/LeptonModule/tree/master/software/raspberrypi_libs/leptonSDKEmb32PUB (raspi_I2C.h raspi_I2C.c)
BeagleBone: https://github.com/groupgets/LeptonModule/tree/master/software/beagleboneblack_video/leptonSDKEmb32PUB (bbb_I2C.h bbb_I2C.c)

Let me know...

Walter

--
You received this message because you are subscribed to the Google Groups "Flir Lepton" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flir-lepton+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/flir-lepton.
To view this discussion on the web visit https://groups.google.com/d/msgid/flir-lepton/87fca609-9d54-414f-98cd-c90914f6b612%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Walter Lucetti

email: myz...@gmail.com
web: www.robot-home.it

project:  http://myzharbot.robot-home.it

[Thomas Søhus]

Thanks Walter - I got it to work right out of the box following your instructions :-). 

To unsubscribe from this group and stop receiving emails from it, send an email to flir-lepton...@googlegroups.com.

Visit this group at https://groups.google.com/group/flir-lepton.
To view this discussion on the web visit https://groups.google.com/d/msgid/flir-lepton/87fca609-9d54-414f-98cd-c90914f6b612%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henrik Quist]

Hi Walter,

We have been working for some time with your code on Variscite DART-6 Imx6 board, but we keep missing 25% valid- and dummy segments . I think we have tried everything now. We only have a CPU load of 10-15%. There is absolutely no system in the missed segments - it is totally random.

Do you have an idea of things to try?

Best regards 

Henrik Quist

Den onsdag den 13. september 2017 kl. 11.25.04 UTC+2 skrev Myzhar:

[Konstantin Shabalovski]

Do you tried to measure timeout between id? Do you tried to check if there is  data loss ?

I writed v4l2 module over spi. Module code see in attachment. This code works in kernel mode - so it maybe is faster then your code.

All interesting is in the file: 

spi_imx_lepton.c

For init this need add  this in apropriate arch init file(for example):

static struct platform_device runway_lepton = {

.name = "LEPTON3",

.id = 0,

};

static struct fsl_mxc_spi_capture_platform_data spi_v4l_ptalform_data = {

.cs_gpio = IMX_GPIO_NR(3, 20),

.max_speed_hz = 20e6, /* max spi clock (SCK) speed in HZ */

.bus_num = 3,

.chip_select = 0,

.mode = SPI_MODE_0,

.clock_name = "imx6q-ecspi.3", // Имя генертора . троечка в конце говорит о том, что это для SPI #3. Можно было бы это название генерировать, но мне проще сгененрировать

};

static const __initdata iomux_v3_cfg_t runway_spi_itt_pads[] = {

// MX6DL_PAD_EIM_D20__ECSPI4_SS0,

MX6DL_PAD_SD3_RST__GPIO_7_8,

#define  ECSPI_SS0_GPIO IMX_GPIO_NR(3, 20)

MX6DL_PAD_EIM_D20__GPIO_3_20,

MX6DL_PAD_EIM_D21__ECSPI4_SCLK,

MX6DL_PAD_EIM_D22__ECSPI4_MISO,

MX6DL_PAD_EIM_D28__ECSPI4_MOSI,

};

#define imx6q_add_ecspi_v4l(id_caprure,id, pdata) \

imx_add_spi_imx_v4l(id_caprure, &imx6q_ecspi_data_v4l[id], pdata)

 mxc_iomux_v3_setup_multiple_pads((runway_spi_itt_pads), ARRAY_SIZE(runway_spi_itt_pads))

imx6q_add_ecspi_v4l(1, spi_v4l_ptalform_data.bus_num, (void*)&spi_v4l_ptalform_data);

mxc_register_device(&runway_lepton,&spi_v4l_ptalform_data);

[Henrik Quist]

Hi Konstantin,

Thank you so much for sharing.

We have tried a lot of things, but the error rate is very stable and independent of clock rate for instance. We will try to use your solution.

Brg. Henrik

[Konstantin Shabalovski]

I recomend you  to get all raw data from sensor and save in file. 

Then try parse on  computer or  device. This help you to  discard or confirm the assumption that you are losing data.

[Konstantin Shabalovski]

Have you resolved the problem? May I help you? If you share your code (BSP) I'll try to help you.

среда, 15 ноября 2017 г., 16:25:08 UTC+3 пользователь Henrik Quist написал:

[Myles Syverud]

Thanks all for info so far. 

I am seeing segments roll in fairly random.. 002040001030. This is on a rpi3 so I am assuming I am running in and out of sync. I have the 185ms delay if out of sync but it is strange that when I sync it starts on a random package (not 1). 

Most of the time when the program starts it grabs all 4 ... 1234 but then after that it falls apart. 

I guess until I am seeing something as consistent as below I can assume I am falling out of timing correct? I will look into the pthreads library

Any advice appreciated

p=20 s=0

p=20 s=1

p=20 s=2

p=20 s=3

p=20 s=4

p=20 s=0

p=20 s=0

p=20 s=0

p=20 s=0

[Menno Finlay-Smits]

We've had plenty of problems getting the Lepton 3 working on the Raspberry Pi as well. A few things:

* It is not uncommon for the first packet you see when connecting to not be 1. Your software needs to handle this.

* It is not uncommon for the first segment you see when first connecting to not be 1. Your software needs to handle this too.

* It's normal to see segments with a segment number of 0. These need to be discarded.

* Are you aware that on the Raspberry Pi, the SPI clock speed varies with the CPU clock speed? When the CPU is running at its turbo frequency (1.2GHz) the SPI clock speed is something like 1.6x what you asked for. This means if you've requested a SPI clock at or near 20 MHz the actual SPI clock can end up going beyond what the camera is capable of.

* We found that SPI to the camera is much more stable when we fixed the CPU clock at it's lowest speed. Our /boot/config.txt looks like this: https://github.com/TheCacophonyProject/saltops/blob/master/salt/pi/config.txt

Finally, we've noticed some questionable behaviour of the SPI CLK line when looking at an oscilloscope. There's a discussion ongoing here: https://github.com/raspberrypi/linux/issues/2354

For reference our code to talk to the Lepton 3 (written in Go) is here:

https://github.com/TheCacophonyProject/lepton3  (library to talk to the Lepton 3)

https://github.com/TheCacophonyProject/thermal-recorder (consumer of the library to make recordings)

Hope that helps,

Menno

--
You received this message because you are subscribed to the Google Groups "Flir Lepton" group.

To unsubscribe from this group and stop receiving emails from it, send an email to flir-lepton+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/flir-lepton.

To view this discussion on the web visit https://groups.google.com/d/msgid/flir-lepton/ee3cabfa-11d9-4d63-9f61-57165ee3139f%40googlegroups.com.

[Myles Syverud]

@menno thank you for the information. The clock speed information was especially interesting. I too have set my clock speed as you have (I don't know if this was required). 

I am actually using simulink to deploy code that reads the lepton3 spi frames. I am currently reading up on exactly how it does this on this target, but a discrete time step is set for code that is generated and it is actually doing quite well. The segments are behaving and coming in as 0001234 and I am not losing sink now. Obviously this is a linux system, but without anything else running (still using desktop) I am only at 7% CPU load. 

A few timing themes I saw in implementation.. most code had some form of...

• small delay of ~1000 micro seconds if the header reads 0xf
• big delay of ~190000 micro seconds if that header error reads a certain amount of times (assumed loss of sync)

This helped me get the system humming!

To unsubscribe from this group and stop receiving emails from it, send an email to flir-lepton...@googlegroups.com.

[ddwa...@gmail.com]

Exactly how did you guys handle these problems, I'm seeing these same issues as well.  Thanks in advance for the details.

To unsubscribe from this group and stop receiving emails from it, send an email to flir-lepton...@googlegroups.com.

[Konstantin Shabalovski]

Hi. Actually it was problem with SPI. And delays.

For example at one of the project my SPI had pretty enough speed but it had only 128 Bytes to get the data. Then if I have not had time to read data, SPI bus had a delay. So buffer on Lepton side is overflowed (IMHO).

So to get uncorrupted data your SPI bus must work at least at low speed (~10MHZ) but it must  work without GAPS and delays.

вторник, 17 декабря 2024 г. в 14:29:58 UTC+3, ddwa...@gmail.com: