Yet another cheap thermal imager incoming.. Seek Thermal

[mikeselectricstuff]

every 2-3 secs - unlike the E4 it doesn't seem to slow down as things stabilise.

[Fry-kun]

Oh ok, so I guess it's normal..
Does it also do it more frequently on startup?

[miguelvp]

yes, on startup it has a series of rapid succession calibration events.

[efahrenholz]

@mike,

I don't know if I'm going to be able to repair this thing. The bond wires were basically spaghetti. I managed to move a few off each other but the center section of the wires is pretty bad. I could probably do a better job if I had a way to hold my microscope and rake the bond wires with a small wire. Its fairly difficult. If I don't succeed, you'll have a board coming your way.

[Yushir0]

Just as an FYI, I got my camera this afternoon and it works just peachy on a galaxy note II running the latest cyanogenmod nightly.  Your experience may differ depending on your device,  but cyanogenmod definitely works on at least some phones. If you have USB debugging enabled,  try turning it off and maybe it will help.

On a side note, the gradient on mine is crazy bad (10°F variation between the high and low on a surface with a perfectly uniform temperature). I wanted to use it to do an energy audit on my house and for electronics troubleshooting, but sadly it is pretty much useless for both purposes as you can barely see anything through the gradient unless the temperature is wildly different between whatever is in the foreground and background) .  Pretty much the only thing it is good for right now is taking thermal pictures of my pets...

[Andrew Seltzman]

I made a jig to attach the seek camera to a thorlabs optical cage and image a CO2 laser beam. The laser is pulsing at about 5W through a 200X attenuator with a 6% duty cycle 1kHz waveform.

[efahrenholz]

Well, I don't know how I did it, but I managed to untangle bond wires. I resurrected the camera! FYI, for anyone who decides to take their camera apart and remove the lens, heed my warning!!!! Do NOT attempt to reposition to lens. It's not worth the effort, and the damage you might do to the bond wires could ruin the camera. They certainly less than the thickness of a human hair. I have access to a decent usb microscope, and I used a razor blade to pull bond wires apart. They aren't pretty, but the there isn't any noticeable difference to the image quality. Just breathing on them causes them to touch each other.

I was literally about to hit the order button on the thermal.com website. Saved myself $200.

Sorry mike, i'm keeping this one.

Now...on the other hand, I did have a few spots on the lens housing that the paint missed. I used white out to cover the areas up. I also noticed my shutter coil wasn't perfectly sitting against the pcb, which is interesting. If the shutter is at an angle, as it has a slightly reflective finish, could it cause a change in the field? I can report my gradient has now moved, but only occupies one side of the image along the edge, and it doesn't go towards the center of the image. I didn't move the lens position. Interesting findings. Oh and the gradient was about 10-11 degrees before. Now after its gotten hot, its about 5-6. Much improved, but not there yet.

I hope this helps anyone else. Check your shutter coils. Also, sharpie works well to touch up the black paint flecks off of the metal housing.

[miguelvp]

Congrats on resurrecting your camera   
You should have watched Mike's video about the bond wires, it almost happened to him but he dodged the bullet.

[efahrenholz]

Congrats on resurrecting your camera   
You should have watched Mike's video about the bond wires, it almost happened to him but he dodged the bullet.

Well, funny thing is, I got the lens off with no major issues. It was when I was trying to get the lens in a different position is when I managed to snag those wires. I moved the lens to far right and it crashed into them, which caused many to crinkle up into eachother. I much have about a micron of clearance on some of the wires, just enough to not cause a conflict.

I might try removing the lens again, but this time clean the epoxy off and get the lens closer to the sensor. It seems like most cameras are near focused. Things far away are blurrier than they should be, which could be a result of the post processing, but up close things are tack sharp. I wonder if mike can speak on his experience with setting the lens down closer to the sensor.

[miguelvp]

He was luckier than you, check 18:30 on his 2nd video:

[Fraser]

Congratulations on the re-alignment of the bond-wires..... not an easy task and thank goodness that they were not too brittle to reposition.

This camera is just screaming for a better lens holder than that aluminium tube that SEEK have used. In my minds eye I picture a 'cage' instead of a tube and the lens mounted in a threaded holder that permits manual focus. enlargement of the lens aperture on the SEEKs case would then permit the new holder and manual focus ring to protrude. It may not be as pretty as the standard SEEK but it would be a heck of a lot lore useful and less likely to suffer thermal issues around the microbolometer. The 'cage' could be formed from thick copper wire or something slightly stiffer and a threaded 'nut' positioned at the end for the lens holder.

There is so much opportunity for experimentation with this little camera. It is unlikely to happen any time soon but it would be great if the SEEK camera technology became as common as an Arduino and sold in a format for experimentation. How popular that would be with the maker community. Robots and computer applications with thermal vision etc 

Mike has an excellent way to control lighting effects using thermal camera technology that can see the human target coming. Far more complex than a normal PIR and that sort of application is begging for the new cheaper SEEK technology. IRISYS charge around $1000 for a 15x15 thermal camera people counter..... pretty expensive compared to the $200 SEEK but software would have to be written for the specific application.

FLIR are declining single unit supply of the LEPTON core to the maker community so maybe SEEK can fill that market opportunity as and when the rush on their SEEK camera subsides. Hope you are reading this SEEK Thermal Be the first to market a DIY thermal camera worth deploying in as-yet unimagined applications  Being as famous as the Arduino would not be a bad thing for a start up company. The R-Pi community is another market for such a camera. Oh the opportunities that exist out there.

Aurora

[efahrenholz]

Well, I decided to chip away at the epoxy on both the board and the lens...very carefully. I got the lens about flush with the pcb, used a bit of hot glue to hold the lens down. Yes, moving the lens closer changes the focus of the lens. Now instead of a super clear up close image, I get great far focus. The housing actually pulls the lens away a little and lines it up. So it's basically really well focused for what I would want now. Gradient is still a minor issue, but that's something I guess we will have to live with till Seek offers us the ability to take a calibration frame through the lens vs. just the shutter. I strongly believe the radiation is coming from the lens housing, as the gradient has moved a little. This is a huge red flag pointing right at the lens housing. It does sit awfully close to the sensor. Also, the housing actually has a ledge inside right before the lens, which would be part of the retainer the lens sits in. So that could very well be what we are seeing, as the sensor heats up, the radiation is reflecting off the lens housing, possibly in that area.

Good luck to anyone who decides to dice up their units. They are tough on the outside, fragile as can be inside.

[miguelvp]

Well, I did change the C# code to read 16 bits unsigned shorts instead of 8 bit bytes to be recombined later to 16 bits. I'm not ready to post the code yet since I have to clean up a lot of stuff first, but I looked at the first 12 frames from boot and found some interesting things.

In the following table I made it 1 based so what we usually refer to as pixel 10, in here is pixel 11

Code: [Select]

PX   F1   F2   F3    F4 F5    F6   F7   F8   F9 F10 F11 F12
 
01 3251    0 8733 15625 135 4256 8721 8278 8680 8701 8278 8683
02    0 2000 3237 15520 112 4257 3236 3236 3235 3234 3234 3234
03 3361 2000 8566 15626 139 4258 8540 8080 8500 8516 8076 8496
04 3221 2000 7266 15612 136 4129 7251 6772 7202 7227 6758 7200
05 3320 2000 6417 15588 139 4382 6384 5877 6360 6371 5878 6338
06 3304 2001 9039 15639 137 16287 9024 8570 8985 8997 8575 8968
07 3352 2001 7086 15587 141 4001 7067 6565 7026 7029 6560 7008
08 3133 2001 5748 15574 132 4255 5733 5223 5686 5699 5226 5673
09 3281 2001 6932 15589 138 4257 6914 6437 6882 6904 6427 6872
10 3088 2001 7765 15615 130 4257 7741 7293 7693 7707 7283 7688
11    4    9    8     7 10     5    1    3    6    1    3    6
12 3321 2002 6264 15595 140 4129 6255 5714 6201 6213 5710 6181
13 3353 2002 6949 15585 142 4223 6923 6404 6885 6892 6407 6859
14 3351 2002 8650 15623 141 3999 8635 8173 8603 8616 8176 8588
15 3408 2003 8593 15603 144 3998 8570 8088 8543 8540 8086 8520
16 3404 2003 6941 15600 142 4255 6919 6420 6870 6885 6406 6859
17 3397 2003 6417 15576 143 4126 6405 5887 6356 6374 5855 6349
18 3382 2003 8247 15611 143 4638 8229 7742 8177 8195 7732 8168
19 3432 2003 8360 15618 144 3868 8349 7862 8298 8305 7845 8292
20 3492 2004 7514 15604 146 4257 7491 6986 7450 7468 6984 7438
21 3391 2004 6048 15572 145 16289 6024 5486 5979 5991 5466 5969
22 3381 2004 6525 15587 144 3874 6500 5961 6462 6465 5957 6441
23 3263 2004 6276 15571 139 3746 6258 5746 6207 6227 5748 6205
24 3389 2005 6530 15580 143 4127 6511 5979 6458 6476 5981 6439
25 3488 2005 6730 15581 147 4000 6719 6185 6672 6687 6177 6656
26    0 2005    0     0   0 4511    0    0    0    0    0    0
27 3298 2005 5906 15568 140 4385 5883 5352 5847 5850 5351 5827
28 3392 2005 6634 15603 143 4095 6618 6077 6571 6580 6065 6556
29 3524 2006 9092 15630 149 4130 9059 8556 9022 9028 8560 9010
30 3474 2006 5879 15588 146 4256 5867 5271 5801 5814 5264 5788
31 3529 2006 7605 15604 147 4385 7582 7071 7540 7555 7067 7520
32 3602 2006 7792 15623 150 4255 7772 7243 7720 7740 7229 7705
33 3300 2007 6456 15596 140 4257 6436 5901 6376 6391 5893 6369
34 3266 2007 5959 15593 139 4513 5923 5388 5886 5900 5394 5867
35 3467 2007 9011 15668 142 4259 8998 8510 8959 8971 8514 8955
36 3469 2007 6178 15588 146 16288 6156 5583 6103 6118 5581 6087
37 3523 2007 8010 15598 149 4257 7981 7455 7939 7937 7446 7916

We know that 1 is for a calibration frame, also we know that 3 is a usable frame, we also knew (although we never used it) that 6 is a pre calibration frame.

But on startup there are other IDs, namely 4, 9, 8, 7, 10 & 5 they do look like parametric values to an equation, or at least 7 could be max value and 10 min value, or something like that.

I think those in combination with column 207 might hold a key on reducing banding noise and other calibration data.

I will try to put some code to capture the first full 20 raw frames in individual files with the camera facing down

Edit: Those first 6 frames on device startup might hold the key to a cleaner image.

[miguelvp]

So here is some raw data, 20 frames from startup including those first 6 frames then calibration, capture and precalibration.
They are all raw without taking away any pixels or doing any processing in any shape or form, I did put all the 20 frames in a single file and did two separate runs.

They are 16 bits per pixel, little endian.
Each frame is 208 by 156, 2 bytes per pixel unsigned int16
column 207 has the adjustment value we've been mentioning
column 208 is always 0.

First file is with the camera facing down during startup for 20 frames.
2nd file is with the camera facing the router during startup for 20 frames.

They both include the those bootup frames with ID on pixel 10.

Edit: here are the frame IDs for the facedown file
1 means calibrate (3 total in this file)
6 means pre-calibrate (we think it does anyways, 2 total in this file)
3 means valid frame to process (9 total in this file)

The rest we don't know what they mean (one of each in this file)

4, 9, 8, 7, 10, 5, 1, 3, 3, 3, 6, 1, 3, 3, 3, 3, 3, 6, 1, 3

[miguelvp]

So here are the first 8 frames of the camera facing down but not to scale range (value) wise, but so that the data is somewhat visible.

Frame 1 (ID 4) seems like it has the patent pixels and what seems to be dead pixels, and what seems to be the horizontal banding. I wonder if this data is added somehow to the capture data or it just identifies the non responsive pixels (kind of like a slope value)



Frame 2 (ID 9) is a bit bizarre, because it shows a nice gradient, like if during boot the chip shows that the memory is writable and is just to make sure it can be read. It's pretty smooth with no dead pixels (other than pixel 10) and maybe some others that I can't see. the original range goes from [2000 to 16383] (both included) it didn't translate well to 8 bits. Maybe that's the actual sensor range for raw data, not sure. Also it might be the firmware that outputs the gradient, doesn't have to do anything with the sensor for all we know.



Frame 3 (ID 8 ) looks like a factory calibration data, or maybe it's a boot time real calibration image. Since I had the camera facing down it looks (almost) exactly like Frame 7 and 8 (first real cal, and first image since i had the camera facing down)



Frame 4 (ID 7) looks like the patent pixels and some minor adjustments, little threshold and all the data is on they high 15,000 range, but I scaled it to make it visible.



Frame 5 (ID 10) is similar to Frame 1, but at a lower range (in the hundreds), also I don't know what the upper right corner is doing being all darkish.



Frame 6 (ID 5), patent pixels and horizontal banding, but only for the left half of the image like it's supposed to be stretched, funny thing is that the 1st patent pixels is at half of what it should be but the 2nd one is 15 pixels further so, maybe it just represents the pattern to be adjusted by. Also note that no really dead pixels so the sensor's memory (if it does have that) or the firmware is the one producing that.



Frame 7 (ID 1), 1st calibration frame with the shutter blocking the sensor.



Frame 8 (ID 3), first display frame, shutter open but camera facing down.



Edit, forgot to add the pre-cal frame:

Frame 11 (ID 6), first pre-cal frame, since it's facing down it looks the same as the cal ones and the visible ones)

[mikeselectricstuff]

Re. bond wires, it would probably be possible to blob them with glue to make them more secure.
You'd need to be careful with choice of glue - it would want to be something that stays slightly flexible to avoid putting any stress on anything, runny enough to fill the gaps but not so runny it flows away across the PCB.

[callipso]

@Mike,

I rewatched the gradient video and got an idea: could you try and grind away at the round opening in the bottom of the lens holder to make it bigger, possibly all the way?

It also might be possible to make the lens holder into a "cage" by carefully cutting the sides out of the holder...

[Fraser]

@Callipso, I wondered if drilling a series of holes around the lens tube might resolve the gradient issue. The problem is that the lens tube needs to be removed to do the work.
Aurora

[jaybeez]

@ mike, aurora, calipso
I think duplicating the shutter opening on the opposite side of the lens holder would do the trick.

the sensor starts "hot" at that corner, and moves to "cold" (room temperature) and the shutter opening.

[eneuro]

If the shutter is at an angle, as it has a slightly reflective finish, could it cause a change in the field? I can report my gradient has now moved, but only occupies one side of the image along the edge, and it doesn't go towards the center of the image. I didn't move the lens position.

When we compare this Seek shutter with Flir E4 that probably the first suspect could be this Seek shutter, while there is no perfect symetry in its design and shutter holder with relative higher mass or maybe even comparable to its thin part when moves in sensor FOV than simply maybe faster moving end of shutter is cooled in air while part close to rotation point is at lower speed so I can imagine that there can be temperature difference.
Maybe even some kind of friction in rotating point heats up shutter holder slightly?

Just implemented my image processing idea based on  Seek sensor raw data and now performing additionaly FFTs of calibration and image data.
Gradient issue is interesting thing while it can affect also custom mounted MELEXIS thermophile arrays, so worth futher investigation 

Could some one provide more detailed vblog with this Seek shutter mechanical view from looking into it around him to see  details how it is mounted and how much friction is between those moving parts?
It could be interesting to see it in action in slow motion using fast framerate camera 

10*F gradient difference is about 5*C so huge 
I could bet not for $1000 but for $100 easy that this gradient issue was the reason that Seek app doesn't show temperature scale, while it is much more difficult realize that easy visible different colors when pointed to flat surface perpendicular to its surface have such huge difference in temperature on flat surface 
Since there is no LUT temperature scale presented, one have to switch on those spots tracking and what he'll see only those white temperature numbers on GRAYED background, so this is some kind of distraction while those spots are moving your attention is to track those moving spots, so much more effort needed to realize that wow these temperatures should be close to the same...

Without enabled spot tracking mode it is difficult notice this, while people used to knew that when they look at LCD from diffrent angles then those colors change a little bit, so by disabling pernament default temperature scale it coube a tricky, but simply way to hide this gradient issue 


it is only a speculation, but if it were only 1-2 degree difference than ok, but when Seek doesn't provide any data on expected accuracy of those temperature measurements, probably it is made intentionally, while when someone discovered such difference, than could have a easy way to proof that this device doesn't meet its requirements and might wanted send back and request refund.

So, DOES Seek impleented temperature scale in his latest software app update? I guess, they don't  until resolve gradient issue somehow

[jaybeez]

near focus vs far focus

The near focus is pretty good. my pvs14 and some thermal imagers use add on lenses for magnification.

these lenses are reported to work with the therm-app
http://eom.umicore.com/en/infrared-optics/product-range/35-mm-f-1.1/

but when it comes to focal length and determining which size lens doubles or triples magnification I get lost. but it shouldn't be difficult to 3D print a threaded lens holder that snaps over the seek's bezel/housing. if 2-3x magnification was in focus i'd be much happier.

Seek,
if you are still listening, i'd like to suggest an app modification. Your side by side viewer with the thermal/native camera is nice, but in portrait orientation its not as usefull as over and under would be. over and under while in portrait orientation would allow the 2 images to remain closer to the 4:3 aspect ratio, one above the other without the slider, and would be a little more intuitive considering the native and Seek cameras are physically positioned that way on most phones. seperate zoom for each view would be nice too.

id love to be able to hook my pvs14 to my phone adapter and have night vision/native camera view on top and seek view on the bottom of the screen.

[eneuro]

So here are the first 8 frames of the camera facing down but not to scale range (value) wise, but so that the data is somewhat visible.

Good work, but it is issue that those images are ONLY 8bit so they are useless for anything but display them only....

$ file Frame1.png
Frame1.png: PNG image, 208 x 156, 8-bit/color RGBA, non-interlaced

If you provided those 16bit grayscale PNGs I suggested and using as input to my image processing soft while raw sensor data is 14bit, not 8 bit, then people could verify what you stated 

$ file  sts_cal.png
sts_cal.png: PNG image, 208 x 156, 16-bit grayscale, non-interlaced

This is only two lines of code in OpenCV to output such 16bit grayscale PNG image after or durring processing from any internal matrix format:

Code: [Select]

// Conversions
outf.convertTo(out, CV_16U, 16384 );
imwrite("sts_cal.png", out );
I used 16384 scaling factor since operated on real numbers 0.0..1.0 in software...it can be changed or keep oryginal raw sensor data intact...

Update:

So here is some raw data, 20 frames from startup including those first 6 frames then calibration, capture and precalibration.

It looks much better   

[Spyke]

Just got mine a few days ago. I must say the gradient issue makes the thing pretty poor in high contrast situations. Sad as that rules out most uses. Upon power up the gradient does not exist, but slowly comes into frame after about 20 seconds.

Did anyone think it might be the lens that is getting warmer on one side? I'd imagine the lens tube being made of metal does a good job at transferring heat from the PCB into the lens itself. If somebody could 3D print an ABS one this could probably be better examined... you'd have to remove the lens itself without breaking it however.
As was posted in most TIC's the lens assembly isn't attached to any heat sources and is separate from the PCB.

[efahrenholz]

The lens isn't really heating up from the PCB, the factory puts glue down and the lens housing sits on the glue like a pillow. There's about a millimeter gap between the PCB touching the housing. The heat conduction isn't great. As I stated, the problem seems to be related to the sensor heating up, and the white paint on the housing is slightly reflective, so it seems to be a reflection off some surface inside the housing. Had they used a black matted surface, it probably wouldn't have been an issue.

Here's a picture of my cat warming up in sunlight.

[eneuro]

First file is with the camera facing down during startup for 20 frames.
2nd file is with the camera facing the router during startup for 20 frames.

They were send at <10Hz ?
Do you have any timing hint what frame rate in this raw data could be?
It could be helpfull to estimate when those events took place, so for example delays between calibration frames and normal-do they happen at the same constant frame rate and delay between each those frames?
Such time stamp information when each frame took place could help investigate this raw data...so suggested to output each frame with time stamp info.
OpenCV has builtin functions for calculating such timing, but one have to be carefull and check if task scheduling in OS doesn't affect those time stamp at higher frequencies