Yet another cheap thermal imager incoming.. Seek Thermal

[mikeselectricstuff]

Case is aluminum

Magnesium

[marshallh]

4 very nice test points under the sensor.. separated ground fill... money's on SPI-like

[mikeselectricstuff]

4 very nice test points under the sensor.. separated ground fill... money's on SPI-like

Yes, probably. Also the MCU is flashless -all the code lives in the external SPI flash 

[marshallh]

Code: [Select]

Device Descriptor:
bcdUSB:             0x0200
bDeviceClass:         0x00
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x40 (64)
idVendor:           0x289D
idProduct:          0x0010
bcdDevice:          0x0100
iManufacturer:        0x01
0x0409: "Seek Thermal"
iProduct:             0x02
0x0409: "PIR206 Thermal Camera"
iSerialNumber:        0x05
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed:     High
Device Address:       0x02
Open Pipes:              2

Endpoint Descriptor:
bEndpointAddress:     0x01  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Configuration Descriptor:
wTotalLength:       0x0040
bNumInterfaces:       0x02
bConfigurationValue:  0x01
iConfiguration:       0x00
bmAttributes:         0x80 (Bus Powered )
MaxPower:             0x32 (100 Ma)

Interface Descriptor:
bInterfaceNumber:     0x00
bAlternateSetting:    0x00
bNumEndpoints:        0x02
bInterfaceClass:      0xFF
bInterfaceSubClass:   0xF0
bInterfaceProtocol:   0x00
iInterface:           0x03
0x0409: "iAP Interface"

Endpoint Descriptor:
bEndpointAddress:     0x01  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x81  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Interface Descriptor:
bInterfaceNumber:     0x01
bAlternateSetting:    0x00
bNumEndpoints:        0x00
bInterfaceClass:      0xFF
bInterfaceSubClass:   0xF0
bInterfaceProtocol:   0x01
iInterface:           0x04
0x0409: "com.thermal.pir206.1"
0x0409: "com.thermal.pir206.1"

Interface Descriptor:
bInterfaceNumber:     0x01
bAlternateSetting:    0x01
bNumEndpoints:        0x02
bInterfaceClass:      0xFF
bInterfaceSubClass:   0xF0
bInterfaceProtocol:   0x01
iInterface:           0x04
0x0409: "com.thermal.pir206.1"
0x0409: "com.thermal.pir206.1"

Endpoint Descriptor:
bEndpointAddress:     0x02  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00

Endpoint Descriptor:
bEndpointAddress:     0x82  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0200 (512)
bInterval:            0x00


[waldo]

There have been reports of flakiness on other platforms, in particular Samsung S3, and a message on their facebook page indicates that they have found some issues and will be issuing an update soon.

I can confirm that it works fine on my Moto X but when the same unit is plugged into a S4 Mini, it acts as if the Seek camera is not plugged in.

[marshallh]

Ok, I have captures!

Unfortunately I didn't log the firmware update process that happens on the first boot, but the APK contains that image anyway...

You need Total Phase Data Center to read these captures. You can download it from the offiical site, or i have it already here:
http://retroactive.be/data-center-dinwos-i686-v6.61.zip

http://retroactive.be/1.tdc
http://retroactive.be/2.tdc
http://retroactive.be/3.tdc (contains the enumeration process)
http://retroactive.be/4.tdc

Raw binary dump of 4.tdc, you may be able to find image boundaries and convert the image directly:
http://retroactive.be/pir206_cap.bin

Using these caps and some libusb code it should be possible to have it working on any PC.


It seems extremely simple:
1. Write control transfer on EP0: 0xC0 7E 00 00 (probably does shutter calibration)
2. Read entire frame from EP1. Repeat for a few seconds then recal

[lain]

Just took a quick poke at marshallh's 4.tdc capture (no particular reason I chose to poke that one).
Hi marshallh *waves back* seems the brief video in 4.tdc came through nicely 
 
Frame size is 64896 bytes, there is no header. Frames are sent at roughly 8fps in the 4.tdc capture, didn't look closely at others. The control transfer is a frame request, it's sent before every frame so I don't think it's a shutter calibration request.

Frame consists of 208x156 pixels, each pixel is 16bits, with only 14bit effective. Little endian.
The last 2 columns are not image data:

• The second-to-last column might be a CRC16 or simple checksum, I'm not sure. It seems strongly correlated to the row pixel data so maybe it's some sort of histogram data or something?
• The last column is all 0x0000's in valid frames, it seems. It looks like occasionally the app requested frames faster than ~8fps, and the Seek responded with incomplete / misaligned frames.  One of those is attached (seek-3.png).

What's weird is these extremely low value (often 0000h) pixels, which are pretty uniformly spread throughout the frame... See attached seek-0.png frame for an example which has been auto-level'd to make them more obvious. Maybe calibration pixels of some sort? I'm really not sure at all. They seem to be in fixed positions throughout the image though, across the entire image stream in 4.tdc. No time to investigate closer.

The B&W images were created by dumping the frame endpoint data to a .bin file, then using this command (ImageMagick convert):

Code: [Select]

convert -depth 16 -endian lsb -size 208x156 gray:epdump.bin -auto-level seek.pngIf epdump.bin contains many images (dump an entire stream) this will dump all of them to separate files named seek-0.png, seek-1.png, etc.

The color image was trickier. The images this thing spits out are probably straight off the sensor with zero processing -- they're noisy as hell, unlike the FLIR ONE's image stream which is pre-digested by the Lepton core. This means the flat field correction and such is likely done in software, not even in the Seek itself. So to get the color image, I applied some manual level adjustments as I think the dark pixels were throwing off convert's auto leveling... then I took a frame from the start of 4.tdc which looked very uniform and subtracted the two frames. From there I colorized it with the typical "ironbow" palette again using convert:

Code: [Select]

convert marshallh-wave.png ..\palette.png -clut marshallh-wave-colorized.png
Anyway, no time to poke this further tonight but thought I'd share my findings. Hope it helps!

[marshallh]

Well that makes me feel a lot better, I was getting basically the exact reasult and wondering what the hell was wrong. I guess the missing pixels are just interpolated in software. SW games seem to be the huge thing here.

Even my nice NEC camera has a very noise imagery with no filtering. In minimal filtering mode it runs 5 times 9fps (45fps) and downsamples to 9fps. Explains why motion is blurry as hell on the Seek.
Now to see if the 9fps limit is done in the ARM or sensor itself...
In the FW there are references to various DACs, probalby the MCU does various tweaking at runtime to babysit the sensor. If it's low level enough we can whack the sensor harder and get more detail at the same fps. The annoying auto-cal every 5 seconds is also extremely annoying

It seems like the sw just bangs away at the endpoint... absolutely gobs of NRDYs in the logs. Maybe they should've spent 5 minutes writing a status on the other completely unused endpoint?

Filtered

[mikeselectricstuff]

Low values probably dead pixels - if they want to keep costs low, they wouldn't want to scrap sensors with bad pixels.
 

[eneuro]

Plugging it into a linux desktop lsusb produced: Bus 002 Device 006: ID 289d:0010

Did you checked what dmesg shows on its output?
There is some info about Linux USB OTG: http://www.kernel.org/doc/htmldocs/gadget/otg.html .

Didn't you tried to run some video capture software under Linux? 

[cynfab]

I was able to get the seek app running on my Nexus 7 to the same extent as on my Radxa Rock. It turns out that my micro USB extension cables don't seem work quite right. In any case, I was able to run adb via wifi to my Nexus 7 and here is a logcat capture from about the time I allowed the app to use the USB.

Code: [Select]

D/ConnectivityService(  489): Done.
D/ConnectivityService(  489): Setting timer for 720seconds
I/ServiceDumpSys(  887): dumping service [account]
D/dalvikvm(  887): GC_FOR_ALLOC freed 246K, 7% free 9225K/9904K, paused 31ms, total 31ms
D/libgps  (  489): proxy_gps_inject_location()
I/GCoreUlr(  983): Successfully inserted location
I/GCoreUlr(  983): Not calling LocationReportingService, hasMoved: false, elapsed millis: 3015626, request: Tablet
W/UsbSettingsManager(  489): no meta-data for ResolveInfo{426a8bf8 com.estrongs.android.pop/.view.FileExplorerActivity m=0x108000}
W/ContextImpl(  489): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1131 com.android.server.usb.UsbSettingsManager.deviceAttached:621 com.android.server.usb.UsbHostManager.usbDeviceAdded:156 com.android.server.usb.UsbHostManager.monitorUsbHostBus:-2 com.android.server.usb.UsbHostManager.access$000:38
I/ActivityManager(  489): START u0 {flg=0x10000000 cmp=com.android.systemui/.usb.UsbPermissionActivity (has extras)} from pid 489
I/ActivityManager(  489): START u0 {flg=0x10000000 cmp=com.android.systemui/.usb.UsbConfirmActivity (has extras)} from pid 489
I/ActivityManager(  489): Displayed com.android.systemui/.usb.UsbConfirmActivity: +121ms
I/ActivityManager(  489): Displayed com.android.systemui/.usb.UsbPermissionActivity: +122ms
V/GmsNetworkLocationProvi(  983): onSetRequest: ProviderRequestUnbundled, reportLocation is true and interval is 120000
V/GmsNetworkLocationProvi(  983): SET-REQUEST
V/GmsNetworkLocationProvi(  983): in Handler: ProviderRequestUnbundled, reportLocation is true and interval is 120000
W/InputMethodManagerService(  489): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@42650200 attribute=null, token = android.os.BinderProxy@426e4510
W/GA-SERVICE(  887): Thread[Thread-546,5,main]:  Using destination https://ssl.google-analytics.com
D/Grafika (11376): EGLContext created, client version 2
D/dalvikvm(11376): GC_CONCURRENT freed 12062K, 35% free 32240K/49316K, paused 2ms+5ms, total 54ms
D/dalvikvm(11376): WAIT_FOR_CONCURRENT_GC blocked 22ms
W/GA-SERVICE(  887): Thread[Thread-546,5,main]:  Using destination https://ssl.google-analytics.com
D/dalvikvm(11376): GC_CONCURRENT freed 4139K, 27% free 36233K/49316K, paused 2ms+4ms, total 39ms
D/dalvikvm(11376): WAIT_FOR_CONCURRENT_GC blocked 33ms
V/GmsNetworkLocationProvi(  983): onSetRequest: ProviderRequestUnbundled, reportLocation is true and interval is 120000
V/GmsNetworkLocationProvi(  983): SET-REQUEST
V/GmsNetworkLocationProvi(  983): in Handler: ProviderRequestUnbundled, reportLocation is true and interval is 120000
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/dalvikvm(  983): GC_CONCURRENT freed 597K, 12% free 9484K/10724K, paused 3ms+4ms, total 29ms
D/dalvikvm(  983): WAIT_FOR_CONCURRENT_GC blocked 20ms
D/libgps  (  489): proxy_gps_inject_location()
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): close
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/UsbRequestJNI(11376): init
D/Seekware(11376): Begin ThermographyCalc
D/Seekware(11376): Finished ThermographyCalc
D/Seekware(11376): Begin ImageProcess
D/Seekware(11376): Finished ImageProcess
D/Seekware(11376): Begin Colorize
D/Seekware(11376): Finish Colorize

This goes on and on forever...

Hope this is useful to someone

   ...ken...

[kwallen]

Empty space where Lightning<>USB bridge interface sits.

Where are you suggesting the Lighting bridge would go in that? I don't see any obvious empty spots.

[marshallh]

Directly over the flex pcb

[callipso]

Tell me the lens holder isn't styrofoam, please...

[marshallh]

Tell me the lens holder isn't styrofoam, please...

Silicone dust shield, white plastic lens holder. It's quite solid

[lain]

Where are you suggesting the Lighting bridge would go in that? I don't see any obvious empty spots.

If you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.

Low values probably dead pixels - if they want to keep costs low, they wouldn't want to scrap sensors with bad pixels.

There are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence 

Can we get someone else with a Seek to dump some images and compare the pattern?

[mikeselectricstuff]

If you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.

There is an unpopulated 8 pin chip on the opposite side to the flex

There are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence 

Embedded reference dark pixels?

[lain]

If you mean the Lightning IC for iOS devices, it could be like the FLIR ONE which has the Lightning IC in the Lightning connector assembly itself. From what I could tell on the FLIR ONE it's just USB pass-through with some basic comms to tell the iDevice that a peripheral is attached.

There is an unpopulated 8 pin chip on the opposite side to the flex

D'oh! I missed that.

There are definitely some dead pixels, but there are also low value pixels which occur regularly, every 28 pixels, forming broken diagonal lines across the image. I guess it's still possible those are dead pixels but that pattern would be quite a coincidence 

Embedded reference dark pixels?

Since not all are exactly 0, that would be my guess as well.

[bktemp]

I tried to generate the images from the usb dump myself. Not easy to remove all the noise.
I did notice that the noise seems to change after each reference frame. Since these data are presumably unprocessed raw data, why does the image change significantly? There are quite a few pixels with high values in each frame and after the reference frame they change to almost the lowest values.
The last word of each line seems to be constant on all frames. The other word could be the avarage line value. Checksum is unlikely, there is a visible trend over all frames.

There is really litte stuff on the board. The sensor has its own ground plane. It seems that even all traces are decoupled with resistors. Probably to create a thermal island with no thermal gradients.

[tom66]

I wonder who makes the sensor.

[callipso]

I wonder who makes the sensor.

Freescale

[miguelvp]

Downloading 4.tcd but it's huge (151MB) is that base64 encoded or something even so it's way too big to be raw data, maybe I should have gone for the bin file instead

[marshallh]

Several seconds of all bus data, of course it's going to be huge. You don't want to know how big USB3 logs get to be...

[eneuro]

Since these data are presumably unprocessed raw data, why does the image change significantly?

It may be wrong assumption while there is quite powerfull IC MCU ARM ROMLESS 100TFBGA digikey: NXP LPC4320FET100 

Latest datasheet linked from Digikey: LPC18X0,LPC43X0 IRC Update 22/Aug/2014
Update: Above some production notice of IRC details changed.
Its NXP page there:
http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/LPC4320FET100.html
Its datasheet: http://www.nxp.com/documents/data_sheet/LPC4350_30_20_10.pdf

It would be very interesting to.... disassemble its ARM program code, but where it is -on external flash IC? 

BTW: It costs on Digikey <$10 and arount $4 for bigger volume. Quite nice MCU-maybe it is time to do some ARM development   

[sgstair]

I've built some PC side library code to do really basic frame acquisition and calibration based on the data from marshallh's captures, feel free to try it:
https://github.com/sgstair/winusbdotnet

It's winusb based, you should use Zadig to install the winusb driver on the "iAP interface" device that enumerates.

It's not perfect or polished but it does work, I'll probably continue to improve it as I have time.