Products > Thermal Imaging

Question about FLIR One for Android

<< < (97/98) > >>

Inflex:

--- Quote from: aund on May 17, 2020, 02:17:11 pm ---Here you go - thanks!

--- End quote ---

   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:
[attach=1]
(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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version