Thermal Expert- Raspberry Pi - Page 1
Forum section: electronics / general

author: kiranjayaraj
author_rank: Newbie
timestamp: September 06, 2018, 01:16:51 pm
content: Hello guys,I have been reading this blog for a few months for information related to my university project. We are building a canopy temperature sensor using IR camera and we did an implementation with a Seek camera on Raspberry Pi.I recently got hold of a new Thermal Expert Q1, which I am now trying to integrate to my Raspberry Pi and I'm not having the best times with it. I see that there are a lot of posts about the Q1, but does anybody have a solid way to have the TE interact with the Raspberry Pi. I installed their SDK and tried their instructions on running it on the Pi, but it doesn't seem to work at the moment. I can get to those details in trailing posts, but I was wondering if someone had a simpler test code to use the TE (in Python perhaps)? I am also new to Raspberry Pi and linux environments, so appologies in advance if the question seems wrong. (Noob Alert)Thanks in advance for your responses.Kiran

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: September 19, 2018, 08:48:53 pm
content: kiranjayaraj,I'm trying to reply to your PMs but the system says your inbox is full so I'll put a reply here & hope you see it.You asked if it is normal to not see a /dev/video device for the thermal camera on a Pi and that you have seen a FLIRone being viewed on a webcam app.Yes, that is normal for a thermal camera because there are no standard V4L (or VFW in Windows) drivers for thermal cameras. The reason you can plug in most webcams and view the output in various different camera programs is that there is a standard (Video for Windows & Video 4 Linux) that specifies a set of standard function calls that all compliant programs will use to get information from the cameras and each camera vendor provides a driver that accepts and responds to that standard set of function calls. Thermal cameras are not cheap and common enough for that to have happened yet. They might get there in a few years, though, especially with the Chinese cameras coming out. That shared library file provided by I3 is the sort of thing that is needed and then someone would need to either make thermal camera viewer programs or add the capability to existing webcam software. Around 12 years ago or more you could buy webcams that you had to use their special viewers for because the Windows standard was not fully adopted. It has been fewer years for Linux, and there might still be some webcams that don't work under Linux because the vendor does not want to give out proprietary information.I suspect that what you saw for the FLIRone is what the guys developed on the " Question about FLIR One for Android" topic(?) What they did is essentially make a V4L driver for the FLRIone--exactly what Ben321 wanted except for Linux instead of Windows.But they used a package called "vloopback", which as far as I know is not officially supported anymore.Seek does not provide any sort of driver, dll, or shared library like I3 does so there is nothing but hacked information to use with Seek.

author: mahony
author_rank: Regular Contributor
timestamp: December 01, 2018, 06:38:04 pm
content: Hi, late reply but I played a bit with the Raspi Zero and the TE-Q1.Attached is some very basic code to get images from the Thermal Expert Q1 - for the moment this is really only getting 50 frames as they are from the camera and dumping them to disk. It's just a main.cpp plus simple makefile. The code was tested on a desktop machine (and written) and a Pi Zero W - compiles and runs on both without issues BUT on the Pi I had to run it as sudo for whatever reason. Only requirements are make, gcc/g++ compiler and libusb-1.0 (I used sudo apt-get install libusb-1.0-0-dev).For any further image processing (dead-pixel removal, factory shutterless correction, manual NUC and so on) you either have to write your own stuff or wait until I get on with this and post an update.This is NOT using the supplied TE-SDK but I probably also build a version using it at some point just to compare.

author: Vipitis
author_rank: Frequent Contributor
timestamp: December 01, 2018, 07:32:03 pm
content: what kind of framerate are expectable from a very very basic Pi or Pi Zero?

author: mahony
author_rank: Regular Contributor
timestamp: December 02, 2018, 12:08:17 pm
content: Hi vipitis,I did not actually measure the time but it just took a few seconds to grab the 50 frames.I assume you can easily achieve the default 8.5 Hz even on a PI Zero (W). I mean the data rate is really low (384x296x2bytesx8.5Hz = ~2MBytes/s) and even the basic image corrections computations should be doable - it is just a simple lookup and multiply-add per pixel (for simple gain-offset) or a 4th order Polynom per pixel (factory shutterless gain-offset correction).I can probably do some timing tests this week. I want to extend the code anyway to at least replace the dead pixels and maybe also do the 4th-order gain-offset correction plus show the final image in a simple OpenGL window (not sure if OpenGL will do a the PI Zero - I never tried so far).EDIT: just tried it on the Pi Zero - and I am pretty unimpressed! So far I did not get significantly above 3fps with dead pixel replacing AND full shutterless correction - no matter if the frames where just read or also dumped to disk and also independent from execution in either pure console or from the desktop. I did not yet get the frames displayed in a GL window on the Pi - seems like I have choosen an improper pixel format or something.I may do some tests on a Pi 3B+ too but that is not the platform(s) I am really interested in Linux-wise so do not expect too much effort here - I have already skrewed the afternoon getting the GL libs installed on the Pi just to find out my code is not running as is ...

author: mahony
author_rank: Regular Contributor
timestamp: December 03, 2018, 06:57:33 pm
content: Finally got some GL code running on the Pi Zero W and Pi3B (so 1.2 GHz NOT 1.4) and adapted my code for the Thermal Expert - it is now running smooth on both.The 3B achieves somewhere around 8.5Hz at roughly 40% CPU load while the Pi Zero W finally did slightly above 4 fps but almost maxed out on CPU. I enabled the full MKS OpenGL driver on both and had to install some GL libraries on the Zero.The code is attached plus some actual screenshot of the app running on the 3B. What is still missing is some code cleanup (i.e. move stuff to appropriate classes) and reading the dead pixel map, gains and offsets from camera instead of reading them from disk.

author: Vipitis
author_rank: Frequent Contributor
timestamp: December 03, 2018, 07:58:13 pm
content: Is your imager limited to 8.5hz or do you have the unlocked 30hz version?I am just trying to figure out if a DIY handheld monocular would be possible with a small but open computer.

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: December 03, 2018, 10:05:20 pm
content: Quote from: mahony on December 01, 2018, 06:38:04 pmIn order to NOT need root (sudo) privileges you need a file in the /etc/udev/rules.d/ directory that contains a line likeCode:SUBSYSTEM=="usb", ATTRS{idVendor}=="I3vendorID", ATTRS{idProduct}=="TEQ1ID", GROUP="plugdev"Where I3vendorID is the vendor ID number for the camera and TEQ!ID is the ID number for the camera. You can get the numbers from the command lsusb -vI don't think the file name matters, but this file was somehow auto-generated with the file name 50-seekthermal-usb.rules for my Seek on my laptop running Debian "Wheezy". It has not been automagiacally done on any of my Pi's.And yes you do need at least libusb-1.0-0-dev (and the library itself), older versions won't work.Does the Zero allow you to enable the REAL MKS driver now, or is it the "fake" MKS? "Raspbian Jessie" did not work with it (at all), I think.If you are better at multi-threading than I am you might be able to get some improvement if you put the USB transfer code in a separate thread and also the display writing in a separate thread. I have to have the display stuff (using dispmanx video core commands) in a separate thread on the Zero in order to get 8fps off a plain non-pro Seek. Since there is only one CPU core I have not tried putting the USB stuff in a separate thread. I see no chance of getting any where near 30fps on a Pi though.

author: tmbinc
author_rank: Frequent Contributor
timestamp: December 03, 2018, 11:12:18 pm
content: I have a custom core (I _will_ follow with details at some point) on a Raspberry PI. My setup is an OpenVizsla board (random FPGA board that I had lying around) receiving LVDS data (FPD-Link II; an interesting topic in itself), feeding that over an FT2232H, and displaying that on a RaspPi (3B, non-plus). The FPGA packetizes the LVDS data and reduces the data slightly (FPD-Link II is 24 bit/pixel payload, but 16-bit are sufficient; 14-bit of thermal data + 2 bits for sync). The RaspPi receives the data (via scanlime's "fastftdi",https://github.com/openvizsla/ov_ftdi/blob/master/software/host/fastftdi.c), and does the pixel processing (all in software).I then either output that in a eglfs SDL2 image, or via eglfs qt. (qt because I wanted to provide a UI, but I struggled there...).The data is around 324x256 with 30fps, and I can display that in realtime.Some notes:- Raspberry Pi's USB (dwc2) is _a piece of crap_. (If you look into how it actually works - it's a horror story. One of the issues is that you need to service the stupid USB controller for every microframe. You literally need a full CPU core just for that - and in fact, that's what's for example Windows 10 IoT on Raspberry Pi is doing. ).- In Linux, just use multiple cores. I have one USB receive thread, one pixel processing thread, one display thread. They get nicely scheduled across the quad cores.- My pixel processing is plain C code. No fancy shader. I receive a uint16_t framebuffer (i.e. double-buffering, so I can fill the framebuffer with USB data while the pixel processing thread is running on it; otherwise I would have to serialize or sync the operations - but hey, memory is plenty!), I do histogram equalization (seehttps://stackoverflow.com/questions/34126272/histogram-equalization-without-opencv), which requires 1 pass over the image to build the histogram, 1 pass over the histogram (16384 entries) to build a 14-bit-to-RGB LUT, and then one more pass over the pixel data. Since for a typical image only few distinct pixel values are used, the 16384 * 4 bytes LUT cache performance isn't that bad.) The RGB values I derive from a pre-calculated palette with, say, 1024 entries. (So it's really 14-bit-to-10-bit-to-RGB but that's fair enough)- The end result is a 32-bit framebuffer that I either poke directly to /dev/fb, or submit via whatever GUI library I'm in the mood for.The most critical path is the USB bandwidth. 324x256x30 is roughly 2.5 MPixel/s, which works with 16 bit per pixel (~5MByte/s), but not with 24bpp. I prototyped the setup with a Zynq-based ZynqBerry, which worked well, but was too expensive in the end.I can see to share my code but it's super crappy, and I don't have time to work on it right now.

author: mahony
author_rank: Regular Contributor
timestamp: December 04, 2018, 06:48:48 am
content: @Vipitis: I am not yet aware of a 30Hz Q1 (unfortunately) - so it is actually limited to pretty close to 9 Hz. I think the 3B should be capable of handling close to 30 fps from an M1 (with 240x180 Pixels). And even the Zero should be able to get to 8/9 fps with the M1 as the amout of data to be processed is less than half of the Q1. I tested my Code with the V1 yesterday on my desktop so I could try it on the Pi too - but I expect to get noticably less than 30 fps with the 640x480 resolution.Just another example for the processing: I have a Teensy 3.6 running at just 180 MHz that happily grabs the data from a 160x120 Lepton3 at 26 fps (thats the data rate you have to handle: 1 good frame + 2 junk frames) displays it to a 160x128 SPI TFT (8.7 fps) and also dumps the raw data to SD card (once per second).As @tmbinc and @IwuzBornanerd pointed out multithreading may significantly improve Performance on the Pi 3 - most likely not on the Zero as it's a single-core.320x240 at 30 Hz is already quite demanding for the Pi but sounds absolutely reasonable. On a medium i5 processor PC the 640x480x30 Hz cause little more than 30% CPU load so I would assume the 1.2 GHz Pi might be able to get at least 10-15 fps here - probably even more with some streamlined / multithreaded Code.I may try this on the Pi when the code gets to this point but my primary target is a Jetson TX1 ... so plenty of power here. ;-)@IwuzBornarnerd: thanks for pointing me to the rights issue - I assumed something like this but did not really dig into the issue as my main PC is not having it.Regarding the GL Driver on the PI zero: I just activated it through raspi-config but did not actually check which Driver is really used on the zero. I used a new Image of Raspbian Stretch - maybe there are some changes but I am not sure.

author: jglomas86
author_rank: Newbie
timestamp: February 24, 2019, 08:46:38 pm
content: Thanks for the code Mahoni, you have gone beyond what thermal expert does.Regarding the .bin outputs and .radWhat fileformat / post-processing do they need to get to an image?Thanks,JL

author: mahony
author_rank: Regular Contributor
timestamp: February 26, 2019, 07:50:46 pm
content: Hi,thanks, the code is far from 'finished' but I am lacking time somehow at the moment for all the fun stuff with thermal imaging, coding and so on.The .bins are basically a raw dump of the 16-bit pixel data, the .rad format is very similar but has a small header of 28 bytes that holds mostly image width, height, bytes per pixel, and pixel type (8, 16, 32, 64 bit / int or floating point) plus some magic number for id purposes.Attached is a a C# app that can display those files (plus a lot of image processing stuff that is somehow useful to me) and save the data as displayed to .bmp/.jpg/.tiff or .png files. NOTE: there are two .zip files due to file size limits. The app should run without the OpenTK dlls but there is a menu point "3D Ansicht" which needs them. (Yes the menus are mostly German - I have to re-write it at some point and that is on the TODOs …)

author: jeng
author_rank: Newbie
timestamp: March 07, 2019, 09:07:48 am
content: @Mahony,About libusbTEQ1GL, exactly what I need,But is it possible to pipe this to gstreamer?I have no X11 server running on my pi zero.I want to pipe this in gstreamer an then transfer it via WiFi broadcast.https://github.com/rodizio1/EZ-WifiBroadcast/wiki

author: Ultrapurple
author_rank: Super Contributor
timestamp: March 07, 2019, 02:30:23 pm
content: Slightly off topic, I know, but In case it's of any interest, Wi-Fi broadcast is built in to the Therm-App native driver and at least one other third-party app (ThermApp Plus). It runs on Android, rather than the various Linux platforms such as the Pi, but many Android stick-type computers will work fine. The main requirement is that the stick must support USB OTG (not just be able to support a USB keyboard/mouse etc).If I recall correctly, ThermApp Plus establishes an independent Wi-Fi hotspot (sorry, I can't remember the exact terminology or details; it may possibly be Wi-Fi Direct). I am not sure but I think the stock app requires an internet connection, but is viewable anywhere in the world.PM me if you want any more info and I'll see what I can dig up.

author: mahony
author_rank: Regular Contributor
timestamp: March 07, 2019, 02:32:32 pm
content: Hi,I assume this should be possible but I never used either gstreamer nor ez-wifibroadcast. You will most likely have to create a compressed videostream from the raw 'bitmaps' that are displayed. I assume that is what gstreamer is for, if not ffmpeg should do. But I got no idea how to put together all the rest. Data rate is states as <12MBit/s so uncompressed might do to but you have to check your tools how to get what you need.On the other hand I also interfaced a Lepton3 from the Pi3 some time ago and build a very basic(!) UDP-based server on the Pi that streamed the raw data to some host PC via local WLAN. This worked ok-ish but would need some work to be more reliable/stable.

author: jeng
author_rank: Newbie
timestamp: March 08, 2019, 08:00:48 am
content: Quote from: mahony on March 07, 2019, 02:32:32 pmOk, that's what I need, but have a problem.Im not a developer.So this would be the difficult part for me.Gesendet von meinem SM-G950F mit Tapatalk

author: jeng
author_rank: Newbie
timestamp: March 08, 2019, 08:16:26 am
content: Quote from: Ultrapurple on March 07, 2019, 02:30:23 pmHi,I can give it a try,I really need this cam working.The thermal app you are talking, is the TE-Q1 compatible?If so,Have a nanopi a64 board here, I can flash android v6.0 on it to test.http://linux-sunxi.org/FriendlyARM_NanoPi_A64Gesendet von meinem SM-G950F mit Tapatalk

author: Ultrapurple
author_rank: Super Contributor
timestamp: March 08, 2019, 10:37:30 am
content: Quote from: jeng on March 08, 2019, 08:16:26 amUnfortunately the Therm-App is a different device from the TE-Q1, made by a different company. As far as I know there is no common driver. mahony and others know a lot more about I do about running dongle-type cameras on Linux systems and are better placed to advise on your specific issues. The only reason I mentioned the Therm-App camera range was in case someone else is reading this thread in the future looking for a similar, off-the-shelf answer.Of course there's nothing to stop you selling one camera and buying another but that generally works out fairly expensive. Engineering a solution to your current setup is likely to be a more satisfactory way to go - but of course I don't know your budget.I should point out that I am very biased towards Therm-App because they are my main area of practical experience and I like the way the cameras workfor me. I am not professionally associated in any way with Therm-App or the parent company Opgal - they do not give me any payment or other benefits).

author: Requiem for a Dreamcast
author_rank: Newbie
timestamp: June 02, 2019, 09:41:33 pm
content: Quote from: mahony on December 03, 2018, 06:57:33 pmMahoney, great job with this code! I have adapted your code to work with the M1, and it runs well enough on the Pi 3B. However, since I don't know how to get the dead pixel map or the gain and offsets from the camera, the values are not scaled properly (the dead pixels throw off the range). I have managed to make my own maps more or less, but they are a hack job. How did you get your proper maps?

author: mahony
author_rank: Regular Contributor
timestamp: June 03, 2019, 07:13:37 pm
content: Hi Requiem,to be honest I read the shutterless data (gains, offsets, dead pixels plus some calibartion constants) via my more functional C# app and just copied the data over.But it is relatively easy to read all of the data from the first 26 frames (probably less frames on the M1?) after the camera is connected. I think I described it somewhere in the Thermal Expert Q1 thread - it is more or less the same for the Q1 and the V1 and I think also for the M1 as far as I could see in the disassembled Java code. Most likely the calibration constants are in a different place - thats the main difference between Q1 and V1 from my experience.I can describe it to you if required or maybe point you to the existing description in the TE thread.At some point I am planning on porting all functionality of my C# code to C++ for use on the Raspi, Jetson Nano and Jetson TX1 - mostly for performance reasons. ;-)

author: Requiem for a Dreamcast
author_rank: Newbie
timestamp: June 03, 2019, 08:58:49 pm
content: Thanks Mahony, I've gone through your posts and found the ones where you explain what the first frames do. Info is a bit all over a few threads so it can be hard to find everything in one place, but following your posts pointed me to the right one. I'll see if I can figure it out when I get some more free time. Cheers.

author: mahony
author_rank: Regular Contributor
timestamp: June 29, 2020, 08:22:21 pm
content: Late update:As I got a PN question about the software I though it might be helpful to some if I finally post some updated code.This will now also read all relevant data from camera flash (only after each reconnect to the PC! TBD: find and include flash read request command) and store them to disk.I also added full radiometric support using all the required calibration data.I did not test it under Linux (just VS2017 for today) but it should still compile and run. If compiled in windows you can click to the image to get DL and temperature for this pixel along with current image min/max and FPA temperature.From here on it should be easy for anybody to build whatever is needed from this camera on almost any platform (even a perfoming Android Phone version should be doable -> TBD for the V1).

author: agh768
author_rank: Contributor
timestamp: June 30, 2020, 06:29:14 am
content: will take a look. maybe i can get it running in my thermal spectrum app

author: mahony
author_rank: Regular Contributor
timestamp: June 30, 2020, 10:01:13 pm
content: @123Dante123: your inbox is full, so I answer here:You don't need nvcc - this is the CUDA C compiler from NVIDIA which is only required if compiling withCode:#define CUDAactivated in the code.I use this on the NVIDIA Jetson Nano to speed up image correction.You should be able to compile the program with this on the command line or in a bash script (build.sh in .zip):Code:g++ -c -o3 -Wall -Wextra -Wpedantic main.cppg++ -c -o3 -Wall -Wextra -Wpedantic ThermalExpert.cppg++ -o main main.o ThermalExpert.o -lusb-1.0 -lX11 -lGL -lGLU -ldlThis will just compile the 2 source files to object and then link everthing to the executable called 'main'.You should not have the TE drivers installed on the system for this - or at least deactivate them. I am using the generic libusb-1.0 for direct raw access to the camera!I do all the image processing that is done in the driver the same way but it seems to be more efficient. ;-)Edit:regarding required libs: on a bare Linux system (i.e. ubuntu) you may need to install the dev libs for GL, GLU and libusb-1.0 using:Code:sudo apt-get install libgl1-mesa-devsudo apt-get install libglu1-mesa-devsudo apt-get install libusb-1.0-0-devOn the RPI you may need to also install the X11 libs - I can rember what was exactly needed on the RPI3 so you may need to google or post the errors you get.It should be something like:Code:sudo apt-get install libx11-dev

author: agh768
author_rank: Contributor
timestamp: July 01, 2020, 01:06:47 pm
content: tried to compile the vs solution. i'm using VS2019 and installed cuda v11.0 and libusb1.0.23but when starting it is recognizing the camera but the TE-Viewer only shows some rubbish and the window locks up. Not sure if its because i changed the references or using VS2019

author: mahony
author_rank: Regular Contributor
timestamp: July 01, 2020, 07:15:56 pm
content: Probably try it first w/o CUDA - should not make much difference on a desktop PC.Did you keep the calibration/flash data files that were in the zip maybe? If so these are from and for my camera and may produce unwanted output on different cameras.Also when compile for the Q1 be sure that #define Q1 is activated - otherwise the software will assume a V1 (640x480) camera.Delete the files named Q1.*, disconnect the camera, reconnect and the start the program again. This should read all the flash data files from the camera as they are sent by the cam by default after each re-connect. After this you should hopefully see a good image and on your disk should be 4 files name Q1.dead, .gain, .offset and .fpa that hold data specific to your camera.Hope this helps.

author: Klaus
author_rank: Contributor
timestamp: August 08, 2020, 02:50:42 pm
content: Quote from: mahony on June 30, 2020, 10:01:13 pmHi, can you help me with installing it on a rasperry pi?When I start the build.sh i got this error messages:root@raspberrypi:/home/pi/20200630# sh build.shmain.cpp: In function âint main()â:main.cpp:318:16: warning: unused variable âtSâ [-Wunused-variable]double tS = secondsNow();^~ThermalExpert.cpp: In member function âbool ThermalExpert::ReadDeadPixelData(unsigned char*)â:ThermalExpert.cpp:531:19: warning: ISO C++ forbids converting a string constant to âchar*â [-Wpedantic]char *fileName = "Q1.dead";^~~~~~~~~ThermalExpert.cpp: In member function âbool ThermalExpert::ReadGainOffsetData(float*, float*)â:ThermalExpert.cpp:556:19: warning: ISO C++ forbids converting a string constant to âchar*â [-Wpedantic]char *fileGain = "Q1.gain";^~~~~~~~~ThermalExpert.cpp:557:21: warning: ISO C++ forbids converting a string constant to âchar*â [-Wpedantic]char *fileOffset = "Q1.offset";^~~~~~~~~~~ThermalExpert.cpp:558:18: warning: ISO C++ forbids converting a string constant to âchar*â [-Wpedantic]char *fileFPA = "Q1.fpa";^~~~~~~~ThermalExpert.cpp: In member function âint ThermalExpert::ReadRawFrame(libusb_device_handle*, int, unsigned char*)â:ThermalExpert.cpp:630:13: warning: variable âretâ set but not used [-Wunused-but-set-variable]int ret = libusb_control_transfer(dev_handle, 0x80, 0x86, packets, 0xbeef, ctrl, 0x10, 5);^~~ThermalExpert.cpp: In member function âunsigned char* ThermalExpert::GetDisplayFrame()â:ThermalExpert.cpp:818:9: warning: unused variable âretâ [-Wunused-variable]int ret = ShutterlessCorrectFrame(_rawFrame, _w*_h, _fpaTemp, _frame);^~~main.o: file not recognized: File format not recognizedcollect2: error: ld returned 1 exit statusBest RegardsKlaus

author: Klaus
author_rank: Contributor
timestamp: August 10, 2020, 07:23:27 am
content: Hi,now it starts, but the picture is black.The process needs 100% of the one CPU thread.What could it be?

author: mahony
author_rank: Regular Contributor
timestamp: August 10, 2020, 04:03:53 pm
content: Hi Klaus,do you have any outputs on the commandline?I am not sure if you got the latest version of my source code. I can upload the most recent later this evening.If you got a RPi3 or a PI zero I can even provide you with the binaries from one of my units.I could imagine that you got an issue with OpenGL drivers maybe - that is a bit of pain in the first place on all the PIs. If you are able to run some simple OpenGL test application that would rule this out.RegardsToniEdit: as you are also based in Germany you may PN me (in German ;-))

author: Klaus
author_rank: Contributor
timestamp: August 10, 2020, 05:58:02 pm
content: Hi Toni,checked the OpenGL drivers withglxgearsThat seemed to be okay.The output of the commandline are:root@raspberrypi:/home/pi/20200630# ./main6 Devices in list.TE-Q1 openedClaimed TE-Q1 interfaceDead pixel correction availableReading gains ... successReading offset ... successReading calibration data ... Shutterless correction availableConnected to Thermal Expert. Image size is 384x288visual 0x1a6 selectedKeypress (code): 37T(210,161)=4.26668deg - min/max=3.40271e+07/4.26668deg FPA=21.8375degKeypress (code): 110T(210,161)=4.26668deg - min/max=3.40271e+07/4.26668deg FPA=21.9476degT(123,138)=4.26668deg - min/max=3.40271e+07/4.26668deg FPA=22.0864degSystem is running on stretchThe latest files would be great!

author: mahony
author_rank: Regular Contributor
timestamp: August 10, 2020, 09:16:49 pm
content: O.k. so GL is not an issue.Attached is an updated version of the code. There were some bugs present from removing the CUDA and TE-V1 parts.This should work better but I am not 100% sure if i3 did maybe change something on the camera side.If you try it:1. compile the code to binary2. if the camera is already attached, remove it from USB3. from the folder where the binary lives remove all files named either Q1.* or *.dead, *.gain, *.offset and *.fpa -> those files contain all the calibration data from the camera and should be read from your cam at least once (this data will be dumped to disk and on successive use just read from disk and not from the camera again)4. re-connect the camera and start the softwareIf all goes well you should see a decent thermal image and on disk should be 4 new files (in the binary's folder) named Q1.gain Q1.offset Q1.dead and Q1.fpa.If not I have to dig a bit deeper ...

author: Klaus
author_rank: Contributor
timestamp: August 10, 2020, 09:38:38 pm
content: Hi Toni,these are the compiler outputs:root@raspberrypi:/home/pi/20200810# ./build.shmain.cpp: In function ‘int main()’:main.cpp:291:16: warning: unused variable ‘tS’ [-Wunused-variable]double tS = secondsNow();^~ThermalExpert.cpp: In member function ‘int ThermalExpert::Connect()’:ThermalExpert.cpp:101:25: warning: ‘void libusb_set_debug(libusb_context*, int)’ is deprecated: Use libusb_set_option instead [-Wdeprecated-declarations]libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the documentation^In file included from ThermalExpert.cpp:7:/usr/include/libusb-1.0/libusb.h:1300:18: note: declared herevoid LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);^~~~~~~~~~~~~~~~ThermalExpert.cpp:101:25: warning: ‘void libusb_set_debug(libusb_context*, int)’ is deprecated: Use libusb_set_option instead [-Wdeprecated-declarations]libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the documentation^In file included from ThermalExpert.cpp:7:/usr/include/libusb-1.0/libusb.h:1300:18: note: declared herevoid LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);^~~~~~~~~~~~~~~~ThermalExpert.cpp: In member function ‘bool ThermalExpert::ReadDeadPixelData(unsigned char*)’:ThermalExpert.cpp:491:19: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]char *fileName = "Q1.dead";^~~~~~~~~ThermalExpert.cpp: In member function ‘bool ThermalExpert::ReadGainOffsetData(float*, float*)’:ThermalExpert.cpp:512:19: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]char *fileGain = "Q1.gain";^~~~~~~~~ThermalExpert.cpp:513:21: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]char *fileOffset = "Q1.offset";^~~~~~~~~~~ThermalExpert.cpp:514:18: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]char *fileFPA = "Q1.fpa";^~~~~~~~ThermalExpert.cpp: In member function ‘int ThermalExpert::ReadRawFrame(libusb_device_handle*, int, unsigned char*)’:ThermalExpert.cpp:581:13: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]int ret = libusb_control_transfer(dev_handle, 0x80, 0x86, packets, 0xbeef, ctrl, 0x10, 5);^~~ThermalExpert.cpp: In member function ‘unsigned char* ThermalExpert::GetDisplayFrame()’:ThermalExpert.cpp:749:9: warning: unused variable ‘ret’ [-Wunused-variable]int ret = ShutterlessCorrectFrame(_rawFrame, _w*_h, _fpaTemp, _frame);And this is this message, when i start it:root@raspberrypi:/home/pi/20200810# ./main6 Devices in list.TE-Q1 openedClaimed TE-Q1 interfaceReading gains ... error openingV1.gainWarning: Could not read flash data from disk.Attempting to read flash data from camera.Error: no flash data available!Disconnect and re-connect camera, then restart program.Could not connect to Thermal Expert

author: mahony
author_rank: Regular Contributor
timestamp: August 12, 2020, 09:05:07 pm
content: Hi Klaus,this is the error I mentioned - this should not happen I think with the latest code version I uploaded.I am currently writing from my Pi3b. I just compiled it again and ran it, see the attached screenshots (the first one without NUC and the second one with some temperature values and NUC via 'n' key NOTE: lens cap should be on!)There is also a .zip file containing the source code, object files (.o) and the binary 'main' as used on this Pi3b. I almost forgot: you have to run it as sudo as other users are not allowed to write to USB devices by default on the PI?!I get a lot of libusb transfer errors on the Pi3. Maybe this is due to missing packets or something - I would have to investigate this some more. It could also be a bad cable I used that randomly seems to disrupt USB connection.Hope this works.Regardsedit: just checked: the error message still says V1.gain - although Q1.gain is actually attempted to be read

author: IwuzBornanerd
author_rank: Frequent Contributor
timestamp: August 12, 2020, 10:48:40 pm
content: To avoid needing "sudo", you should try adding a file to /etc/udev/rules.d containing a line of this form:SUBSYSTEM=="usb", ATTRS{idVendor}=="****", ATTRS{idProduct}=="****", GROUP="plugdev"Replace the *s with the vendor ID & product ID of your camera. I don't think the file name matters. You can have comments starting with the # character. This file was somehow automagically generated on my laptop running Debian "Wheezy" while I was running Seek Python code I got off Github, but I have had to manually add it elsewhere.I also tend to get a lot of USB transfer errors when running my Seek Fast Frame Pro on a Pi, but seldom on the laptop. I have not tried to figure out the cause as I don't use it much on a Pi.

author: mahony
author_rank: Regular Contributor
timestamp: August 13, 2020, 07:10:53 pm
content: @IwuzBornanerd: thanks - I will give this a try at some point.In the end it is the same on my end: I am not really using the camera on the PI. My main focus is the Jetson Nano/TX1 and I just out of curiosity I gave the software a try on the PI.

author: mahony
author_rank: Regular Contributor
timestamp: August 14, 2020, 05:01:50 pm
content: @Klaus:Minor change - this version will constantly dump the raw data received from the camera to disk. Compile as before, then connect the camera to the host and run for ~5s to get at least 30 frames to disk (those should contain all the flash data) - upload a zip-file or similar somewhere so I can have a look at those initial frames to find where the problem is.Also included is a Visual Studio 2015 solution to build and run it on a windows PC (if no i3 driver is installed). Requires libusb-1.0 repo and maybe adapted include and lib path in the settings.

author: Klaus
author_rank: Contributor
timestamp: August 14, 2020, 10:28:57 pm
content: Hi Toni,this are the messages:root@raspberrypi:/home/pi/20200814# sh build.shmain.cpp: In function 'int main()':main.cpp:291:16: warning: unused variable 'tS' [-Wunused-variable]double tS = secondsNow();^~ThermalExpert.cpp: In member function 'int ThermalExpert::ReadRawFrame(libusb_device_handle*, int, unsigned char*)':ThermalExpert.cpp:580:13: warning: variable 'ret' set but not used [-Wunused-but-set-variable]int ret = libusb_control_transfer(dev_handle, 0x80, 0x86, packets, 0xbeef, ctrl, 0x10, 5);^~~ThermalExpert.cpp: In member function 'unsigned char* ThermalExpert::GetDisplayFrame()':ThermalExpert.cpp:757:9: warning: unused variable 'ret' [-Wunused-variable]int ret = ShutterlessCorrectFrame(_rawFrame, _w*_h, _fpaTemp, _frame);^~~root@raspberrypi:/home/pi/20200814# ./main6 Devices in list.TE-Q1 openedClaimed TE-Q1 interfaceReading gains ... error opening V1.gainWarning: Could not read flash data from disk.Attempting to read flash data from camera.Error: no flash data available!Disconnect and re-connect camera, then restart program.Could not connect to Thermal Expertroot@raspberrypi:/home/pi/20200814#

author: ericb
author_rank: Contributor
timestamp: December 05, 2020, 11:53:39 pm
content: Hello all,i don't own such a cam, but I can help if you are interested :The first warning is caused by unused variable. The other are because the functions return int and those values are not evaluated. And the compiler is not happy :-)Not sure ShutterlessCorrectFrame() needs to be an integer though.@mahony : Thanks a lot for providing such code, very interesting approach, really. Thanks for sharing it :-)[ Edit : removed stupid question ]Back to the warnings :1. just comment the line 291 (containing tS declaration). This should shut up the compiler.2. If the warning is right, in ThermalExpert.cpp, line 580 you have the following line of code:Code:int ret = libusb_control_transfer(dev_handle, 0x80, 0x86, packets, 0xbeef, ctrl, 0x10, 5);Simply add this line (just after the one above):Code:// LIBUSB_ERROR codes are all negativeif (ret < 0)std::cerr << "problem with libusb_control_transfer()" << "\n";Result is :Code:int ret = libusb_control_transfer(dev_handle, 0x80, 0x86, packets, 0xbeef, ctrl, 0x10, 5);// LIBUSB_ERROR codes are all negativeif (ret < 0)std::cerr << "problem with libusb_control_transfer()" << "\n";3. after:Code:int ret = ShutterlessCorrectFrame(_rawFrame, _w*_h, _fpaTemp, _frame);Add :Code:if (ret != 0)std::cerr << "problem with ShutterlessCorrectFrame()" << "\n";(around line 757)Should fix all the warnings.HTH