Question about FLIR One for Android

[aund]

Ah thank you. When I switched the video ref in ffmpeg I can see the optical image.

So assuming I have the LT is it just a case of changing the right variables to match?

[Inflex]

Ah thank you. When I switched the video ref in ffmpeg I can see the optical image.
So assuming I have the LT is it just a case of changing the right variables to match?

Yes, it'll be a very small output frame (80x60 + 8 at the bottom if you want the text, and only 13 characters).

[aund]

It is indeed the LT model.

I've tried a few things now to get up and running

1) Changing the VIDEO_DEVICE2 resolutions to match

Code: [Select]

#define VIDEO_DEVICE2 "/dev/video3" // colorized thermal image
#define FRAME_WIDTH2  80
#define FRAME_HEIGHT2 60

This yields the attached pic which is my hand (just legible). I don't have extreme frost byte so I think the colour range is off somewhere.  There are various hard coded references to what I assume is fixed height and width through the code (i.e. 160, 120  & 128).

2) I've tried changes all references of 160 -> 80, 120 -> 60 & 128 - > 64. This is obviously quite a bad stab in the dark which shows how little I understand of how the image is put together and unsurprisingly just results in errors when trying to run.

I think I'm a little of of my depth so I'm going to see if I can get my hands on the non LT model instead.

Thanks again for all your help.

[Inflex]

Hello Aund,

   I'm just cleaning up the workshop and then I'll come back and have a look at the IR data block that you sent through last night; did you want to send me a copy of your code that you're using and I'll try see if I can spot something obvious (or attach it here, just the main C file)

[aund]

Here you go - thanks!

Do you need an updated frame dump with the new resolutions in place? I did try that but ffmpeg now errors with "[video4linux2,v4l2 @ 0x23ad2b0] ioctl(VIDIOC_G_FMT): Invalid argument
/dev/video3: Invalid argument" when I put the framedump code in place, so it's commented out for now.

[Inflex]

Here you go - thanks!

   All good - just getting in late now (02H28) after cleaning up in the workshop, I'll have a look at the code in the morning.

Paul.

[Mowj]

I want to thank all those who shared information on FLIR One here. It really made my work possible. I would also like to share some more info that I gained about the usb software interface. Some (most?) of the info below are repeated from the previous posts for the sake of completeness.

All messages are preceded by a header.
All headers are comprised of 32-bit words in little-endian order.
Headers of config endpoints have 4 words, those of file endpoints have 6 words, and those of frame endpoints are 7 words.
The first word is always the magic number (0x1cc for config, 0x5510 for file, 0xbeef for frame).
The second word appears to be always one. I'm still not sure about its meaning.
The third word is always the payload (message) size in bytes.
The last word is always the CRC-32 of all but the last word of header with the following parameters (this is the conventional CRC-32):
Polynomial: 0x04C11DB7,  Init: 0xFFFFFFFF,  Reflect Input: true,  Reflect Output: true,  XOR Output: 0xFFFFFFFF

For file headers:
The fourth word is the stream identifier.
The fifth word is the conventional CRC-32 of the file itself.

For frame headers:
The fourth word is the size of thermal image.
The fifth word is the size of visual (jpeg) image.
The sixth word is the size of status string.

After issuing a command to the config endpoint, you can query it for a response.
For commands of type 'setOption', the response is of type 'setOptionStatus' and indicates the new value of the option (-1 if the option does not exist).
For commands of type 'openFile', the response is of type 'openFileStatus' and indicates the stream identifier of the opened file. The stream identifier is essentially the return value of the fopen function. Negative values indicate different error codes. Non-negative values could be used by a readFile command to read the opened file.
Analysis of the sdk binary reveals that there are also 'reboot' and 'upgradeFirmware' commands with corresponding responses 'rebootStatus' and 'upgradeFirmwareStatus'. But I haven't worked out the required arguments for these commands.

[da-nie]

I created new Flir One Gen 2 control programm for Linux.

Programm used Qt5 and libusb (Run through "sudo" if you do not have sufficient user rights.).

[mojpismonosa]

Hi everyone!

Thanks for hard work in enabling this little thermal cam to be used on systems other than the manufacturer itself cared to!

I've been using the 'clean code' version from github (https://github.com/fnoop/flirone-v4l2), been stuck on "invalid argument" thing for a while, and got it that it is a thing of the v4l2loopback kernel module, not the code itself. After compiling latest version like https://www.dpin.de/nf/thermal-camera-on-linux-flir-one-pro/ did (from https://github.com/umlaeute/v4l2loopback/releases) and running the ./flirone as superuser (sudo or root user, couldn't get it to work otherwise using udev rules no matter what) on kernel 5.x, Ubuntu 18.04, it's been working flawlessly!

The question I have is -
Is the some way one could trigger the Non-uniform-calibration (NUC) as Android app (the stock one from FLIR) can? Or, at least detect (from frames) when the NUC is happening or did happen?

Thank you very much!

[victorffs]

Hi guys!
Firs I would like to congratulate everyone that helped on this post. That's an amazing initiative and you are awesome!
I'm would like to know if someone could get the Flir One Pro LT version working with Linux.
I'm trying to use the Pro LT with an raspberry Pi 4 but i'm having some issues. Here is some comments about:

1 - The Pro LT didnt work with the V4L on RPI4 but I could workaround using the MJPEG Streamer as suggested by @thomas123 before
2 - The normal camera (real.jpg) is working fine, but I cant get the image from the thermal camera (thermal.jpg). I get the same issues that some guys replied here before, an image with some colored glitches:

(obs. I've covered the thermal camera with my fingers and noticed some changes on the glitches patterns, so probably the image is being received but need to be correctly decoded)
3 - I've tried to change the the references for resolution on the source code from 160x120 to 80x60 but still getting the same issue.

I've saw that @aund could put the Pro LT version to work, but I cant do the same here.
Is there any other changes that I should do beyond the resolution?

Please, someone could help me?
Thank you in advance!

[aund]

Hi Victorffs,

I actually gave up on trying to change the source code to fit the dimensions of the FLIR1 as I simply don't have enough knowledge of how the video stream is put together (coupled with not being a C programmer).

@Inflex might be able to give you some pointers as he very kindly pointed me in the right direction with some of this.

I only got as about as far as you are now, sorry I couldn't be more help and good luck!

[victorffs]

Thanks for your answer @aund!
I'm considering change my version LT to the PRO, but its more expensive and isn't available for now at my distributor (he said that probably on 1th july will be available)
So, I'll try to keep using the LT until july, if not works I will try to change the camera.
@Inflex do you have some suggestions to make the LT work?

Regards!

[Propretor]

Guys, and who has not tried to run the Flir One Pro Gen3 without a battery?
First, supply power to Type-C and connect to a smartphone without a battery.
If everything is OK, then you can make one connection internally between the Type-C charger and micro-USB / Type-C data.
Alteration will make a siktermal out of flir
I haven't used flirting for about a year and the battery has completely run out. Now the flir cannot even charge the built-in battery to 100% - the green LED does not stop blinking for 6 hours, and then the orange one turns on. Nevertheless, there is still 10-20 percent of the previous capacity in the battery. And the thermal imager does not work for long.
The question is in the vandal-free analysis of the subject.
Is there a parsing order in pictures or videos?

[soumitra.kbc@gmail.com]

Could obtain the stream (both Thermal & Visual) from FLIR Pro for Android to the Raspberry Pi following the blog. Thanks all for the contribution. But how to obtain the temperature matrix for further analysis of the obtained Thermal images?

[luporl]

Hello,

I was trying to make a Flir One Gen3 camera work on Linux and I ended up finding this forum thread and the code in https://github.com/fnoop/flirone-v4l2.

Unfortunately it didn't work and I got results similar to those that tried to use it with the Pro LT version.

But after spending some time experimenting with the code, I've managed to get a version that works with the Flir One Gen3 camera, that have a sensor with 80x60 resolution.
As this is the same resolution of the Pro LT models, maybe it will work with them too.

So, if anyone wants to try it out, here it is: https://github.com/luporl/flirone-v4l2

Best regards!

[anthonymg]

Hi,

Thanks for that @luporl, I was also trying to adapt the code to work with the FLIR ONE GEN 3. However, I still have a persistent problem. Some of the frames in the transmission appear similar to the attached image and consequently the temperature values are nan values or incorrect values. Currently, I am stuck on this. In your adaptation have you been able to overcome this problem?

[anthonymg]

Hi,
After a few weeks trying to find the bug. I have noticed that inside the loop where libusb_bulk_transfer is called to get the data in the buffer the information is sometimes not complete. The complete data that should be received should be of the size 28 + FrameSize where FrameSize = ThermalSizer + JpgSize + StatusSize. However, when gathering the information from the data that comes in the buffer, it seems that some information was lost and they do not complete this ideal size. Or on other occasions it seems that the information that was lost was from the next header and the size of the information between two headers is much larger than it should be.

I'm using the code from https://github.com/fnoop/flirone-v4l2 , with modifications from @luporl for a flir one gen 3 , compiling it on a raspberry pi 3 model b

What could I do to solve this problem?

[luporl]

Hi @anthonymg,

I haven't seem the issues you mention, about nan or incorrect temperature values.
I saw something similar with the original code, that is for cameras with higher resolutions, then with flir one gen 3 less data would be read and the remaining bytes in buf85[] would be garbage.
But I've only tested it on an x86 laptop, haven't tried it on any raspberry pi boards.

The ThermalSize should always be the same. JpgSize varies, because of compression.
And buf85pointer should always start counting, and be reset, after the 4 magic bytes are found.

I guess you're running using RPi 3 in little-endian mode, right? If not, then the lines that get the sizes from buf85[] would have to be changed.

Other than that, it's hard to know what could be the problem. Maybe you're not reading fast enough from usb or some usb frames are being lost?

[YacineBrahim]

Any one can help please to provide a clean software to run FLIR ONE PRO camera on Linux Machine. That will be very much appreciated. Thanks