-
-
@Mike... do you sacrifice your seek just for getting this layer images?
Well... thanks.
It would be interesting if this sensor could be used with another µC...like a stm32f4xx.
It's one that rjardina broke and donated.
Due to the die-bond construction and lack of easily accessible connection points, I think the only practical re-purposing would be to keep the existing ARM processor and write new code for it.
-
#1626 Reply
Posted by
Uho
on 26 Jan, 2015 08:08
-
joe-c
Your countrymen have done a good editor. Open source. I translated into Russian. Features of the program look here.
http://youtu.be/-34KSjlfiw0 Processing data stored in a text file. Like you. Only need to change the number of points. Will be ready to prepare the report editor. If interested I will give all the information.
-
#1627 Reply
Posted by
joe-c
on 27 Jan, 2015 05:25
-
Your countrymen have done a good editor.
thank you... it was my website
I have also made a program for analyze thermal images. Also open source:
http://joe-c.de/pages/posts/programm_thermalviewer_120.php#ver007now the Flir Ex is implented. You could connect the camera over RNDIS and grab a full image...
it takes just a few seconds:
1. take a short radiometric sequence (full ir frames... like a video)
2. download it
3. readout the min and max (from Scale or better... from full screen measurement box)
4. readout the frame from the download file and calculate the image with the min and max from camera
if I get the seek completely working... I will implanting this camera too
-
#1628 Reply
Posted by
eneuro
on 27 Jan, 2015 16:43
-
I assume they didn't supply a disc or USB flash drive because of the cost and fragmentation it would cause.
In this video
EEVBlog #704 – Rigol DS1054Z Oscilloscope Features Review they include DVD/CD disk to his product and it costs less than two such Seek Thermal tiny dongles
Buy such scope and decode live I2C from Melexis IR sensor and... you have device to detect heat leakage in house and... no fancy "sick" software needed
-
#1629 Reply
Posted by
efahrenholz
on 28 Jan, 2015 01:13
-
Eneuro, the Seek was designed with mobile phones and tablets in mind. That's why both versions use male lightening and micro usb. They weren't intended to be used with a computer. How did you expect them to sell a device with their "thermal imaging for dummies" business model if they required the customers to figure out how to put software on the phone or tablet to even use it. What you are saying is complete nonsense. An oscilloscope could just as easily be designed to be used with a tablet or smartphone. Hell, there *ARE* tablet based oscilloscopes. It was more logical to place an app on each major app store. The reason the oscilloscope has software is, surprise surprise--it was designed to work with a computer! So they were kinda obligated to providing you with software. Oscilloscopes don't come with access to the Internet or an app store.
-
#1630 Reply
Posted by
steveg
on 28 Jan, 2015 04:34
-
Hello - I have a Seek Thermal I am interested in using it on a Rapberry Pi. I have tried Cynfab's Seek_2.0.py but I get error messages about a broken pipe from usb.core. I do not understand the protocol enough to know what to do. Has anyone used Cynfab's program on the Ras Pi or have any other software for the Seek that runs on the PI?
Thanks!
Steve
-
#1631 Reply
Posted by
eneuro
on 28 Jan, 2015 07:49
-
the Seek was designed with mobile phones and tablets in mind.
So, they loose other customers.
Common this Z shaped Seek ... looks very crappy, I don't like it at all.
Its sensor and possibility to hack its MPU firmware is the only thing it is quite interesting device for the moment
-
-
Teardown part 2 :
I did try reading the flash but it appeared to be blank - could have been a programmer issue, but I've lost the chip now...
-
#1633 Reply
Posted by
efahrenholz
on 28 Jan, 2015 14:59
-
There aren't any customers lost. The people who bought the device were aware of what they were buying into. They made a few exaggerations about the capabilities; the resolution claims are rubbish, and example photos were completely either fake or through a different camera. These things are typical with any company trying to pursuade buyers to an unproven product, and I scold them for it, but people will still buy.
-
#1634 Reply
Posted by
Fraser
on 28 Jan, 2015 16:11
-
@Mike
Thanks for another great video.
Nice X-Ray images
Aurora
-
#1635 Reply
Posted by
WS-PI
on 28 Jan, 2015 16:32
-
@ Mike
That is great to see the sensor details so clear. Good work with simple tools. But I am a little bit astonished not to see any indication for a hexagonal arrangement of sensor elements what was discussed earlier.
-
#1636 Reply
Posted by
efahrenholz
on 28 Jan, 2015 19:08
-
Well folks, that video sums it up. Mike is officially disappointed with the performace.
I found it interesting that there were no pixels physically blanked. That means it's done by the controller. Also the reference block has so many pixels. Perhaps row 207 is where these values come from. Each pixel in the reference row might be averaged and applied to the main array. Really interesting stuff.
-
#1637 Reply
Posted by
cynfab
on 28 Jan, 2015 19:09
-
steveg,
Trying to get my python code running on a RPi is an ambitious project.
In a previous post I stated that the code
"Runs at about 5 fps on my i7 desktop and about 1fps on a MinnowBoard Max under
Linux Mint 17"
Both those are multi core x86 64bit processors with sse4.
My python code is very floating point intensive. I'd bet if you can get it to
run on a RPi, it might do 3-5 seconds per frame.
Re. the broken pipe error message, it would help if you post the complete error
message and the command you issued to get it.
As well as the versions of all Py libs that were installed (see the source).
I have used pyusb 1.0 on the RPi on other projects and it has worked for me. But I've
never tried to run the seek python app on the RPi. IMHO it is far too underpowered for real time processing.
You should be able to get it to grab images and save them though.
Put some print statements into the python code and see how far it gets before the error pops out.
...ken..
-
-
Well folks, that video sums it up. Mike is officially disappointed with the performace.
I found it interesting that there were no pixels physically blanked. That means it's done by the controller. Also the reference block has so many pixels. Perhaps row 207 is where these values come from. Each pixel in the reference row might be averaged and applied to the main array. Really interesting stuff.
Thinking about it, if you don't have enough reference pixels on a row, you effectively lose the whole image row, so they need enough that even after bad pixels etc. in the reference array, they have enough to compensate the main row.
-
#1639 Reply
Posted by
dexters_lab
on 28 Jan, 2015 22:19
-
could they use the array of reference pixels to make a two dimensional predictive reference map of the entire die?
-
-
could they use the array of reference pixels to make a two dimensional predictive reference map of the entire die?
I can't see how anything across the 22 pixel width of the ref array could relate to anything over the with of the main one. Not even sure about the length either, though without knowing the sorts of things they are compensating it's hard to know.
If there is some progressive issue across the array, you'd think a strip on all 4 sides would be the way to compensate it.
-
#1641 Reply
Posted by
Fraser
on 28 Jan, 2015 23:20
-
I have seen microbolometers with whole rows of pixels that are not used for imaging, but rather offsetting of data coming from the main array. I do not recall, but have we previously seen any defined banding in images ? Could this 'stripe' that is blinded by the microbolometer case be a sort of comparator reference for processing swept 'stripes' of pixels in the imaging array. We are dealing with early days 12um microbolometer technology here. It could be that the only way to tame the active imaging pixels drift and behaviour is to either compare it to a 100% duplicate on the same die that is blind, and so a reference against which to compare, or use a reference stripe that is compared to stripes of the active microbolometer pixels and save on die size.
One thing is for sure, my experience of the SEEK microbolometer is that it is VERY thermally unstable and so requires a lot of taming. Maybe a FFC every second or so is not enough to make a usable image. Remember that we have that strange mottling effect that I had assumed was image processing, maybe its the result of using one pixel against another (reference pixel) to detect the differential ?
I am not a designer of such cameras and have no inside information. This is just a theory of mine.
Aurora
-
#1642 Reply
Posted by
dexters_lab
on 28 Jan, 2015 23:42
-
could they use the array of reference pixels to make a two dimensional predictive reference map of the entire die?
I can't see how anything across the 22 pixel width of the ref array could relate to anything over the with of the main one. Not even sure about the length either, though without knowing the sorts of things they are compensating it's hard to know.
If there is some progressive issue across the array, you'd think a strip on all 4 sides would be the way to compensate it.
yes true, does seem odd the number of reference pixels though
-
#1643 Reply
Posted by
efahrenholz
on 28 Jan, 2015 23:48
-
Well folks, that video sums it up. Mike is officially disappointed with the performace.
I found it interesting that there were no pixels physically blanked. That means it's done by the controller. Also the reference block has so many pixels. Perhaps row 207 is where these values come from. Each pixel in the reference row might be averaged and applied to the main array. Really interesting stuff.
Thinking about it, if you don't have enough reference pixels on a row, you effectively lose the whole image row, so they need enough that even after bad pixels etc. in the reference array, they have enough to compensate the main row.
Mike I think you are spot on. I suspected that because lots of pixels will inevitibly drift, pixels will be dead or have wild gain differences from the main array, they need a large range of reference pixels to compute an average value from. I wonder if flir sensors have a the same large amount of reference pixels. The seek sensor manufacturing process appears to contain serious limitations. I wonder what yield of sensors they get from a wafer that contain fewer than 1% bad pixels.
In reference to a previous post I made, I'm wondering what the integration time is. it would be really interesting if someone was able to reverse engineer the flash chip and write some code to change the integration time. In my opinion, the shortest possible integration might reduce drift. A shorter duty cycle of current being passed through each pixel, less energy being converted to heat and thus a more uniform image for longer periods between NUC events. And more samples for oversampling. I wonder if the lepton core uses a similar technique.
-
#1644 Reply
Posted by
-jeffB
on 29 Jan, 2015 02:24
-
In reference to a previous post I made, I'm wondering what the integration time is. it would be really interesting if someone was able to reverse engineer the flash chip and write some code to change the integration time. In my opinion, the shortest possible integration might reduce drift. A shorter duty cycle of current being passed through each pixel, less energy being converted to heat and thus a more uniform image for longer periods between NUC events.
I'm not sure I follow this. Yes, passing less average current through each pixel should reduce the "thermal background" in the sensor -- but as long as the current * time is
constant per frame read, I wouldn't expect it to contribute to non-uniformity. Since NUC doesn't cut off current to the sensor (you're reading out in the usual way, just with the sensor exposed to a reference instead of the scene), I don't see how uniformity is affected by a lower (but still constant) pixel read current.
Or am I confusing NUC with something else?
-
#1645 Reply
Posted by
efahrenholz
on 29 Jan, 2015 06:24
-
The drift is high in the array, so I'm going on the principle that the thermal capacitence is low in each pixel. Any heat on the pixel, whether generated from radiation or from measurement, will saturate the pixels thermal capacity since it is so much smaller than anything ever achieved. So there comes this new territory where you must deal with barely measurable changes in heat in the pixel, which can cause rapid swings in resistance. The engineers likely decided on a longer integration time to get over the ROIC noise, and this increases the time that current is passing through the pixel from frame to frame. Each pixel at a unique resistance, getting warmer from different amounts of current and a small thermal well, equals out to quick thermal drift and frequent NUC events. My theory is to reduce the integration time to where is it able to generate enough signal over read noise, by sacrificing some low end temperature response, in order to minimize drift. It would also provide more samples to average out any other noise. It *is* just a theory, so don't take any of it too seriously.
-
#1646 Reply
Posted by
eneuro
on 29 Jan, 2015 07:11
-
These things are typical with any company trying to pursuade buyers to an unproven product, and I scold them for it, but people will still buy.
If someone doesn't know that lens holder is.... glued to PCB and have no technical background maybe someone will buy those toys (Flir One also is a toy only).
This Seek sensor is the only reason people who read "Art of Electronics" and are interested in hacking its MPU might want it in this hardware version before official standalone Seek module will be available.
-
#1647 Reply
Posted by
efahrenholz
on 29 Jan, 2015 19:17
-
I don't see them releasing the module separately. I mean, how do you figure they would do it? The lepton worked that way because everything was squished into a tiny housing with a commonly used protocol for the video out.
-
#1648 Reply
Posted by
Uho
on 29 Jan, 2015 20:22
-
joe-c
Thank you. Eliminating the gradient runs. For my convenience I have translated the program. Not enough save photos in JPEG. To compare the two photos. Seek processing algorithm better. It is not clear how they reduce noise. I have two Seek. In the later less noise. Possible spread of the parameters.
-
#1649 Reply
Posted by
efahrenholz
on 30 Jan, 2015 04:21
-
A bit off topic, has anyone had a chance to read "Thermal Imaging Cameras: Characteristics and Performance," by Thomas Williams? I read the sample and there is definitely some very good information in there. I'd buy the book but the pdf commands about $100. I've looked around and it can't be had any other way. That appears to be almost like the Bible for thermal imaging engineers. I'm almost compelled to drop the cash on it. Anybody have any good resources besides that one?