Products > Thermal Imaging
Yet another cheap thermal imager incoming.. Seek Thermal
eneuro:
--- Quote from: cynfab on November 26, 2014, 04:16:04 am ---I've been looking at the "sources" as well and have added a bit of documentation to my Python program detailing what the startup sequence is.
--- Code: ---...
self.send_msg(dev,0x41, 0x3E, 0, 0, '\x08\x00')
# 0x3E = 62 Set Image Processing Mode 0x0008
self.send_msg(dev,0x41, 0x3C, 0, 0, '\x01\x00')
# 0x3c = 60 Set Operation Mode 0x0001 (Run)
ret8 = self.receive_msg(dev,0xC1, 0x3D, 0, 0, 2)
# 0x3D = 61 Get Operation Mode
...
--- End code ---
--- End quote ---
I looks like parameters are passed in Little Endian ;)
--- Code: ---public ShutterArg(short word0, short word1)
{
this$0 = RequestSequence.this;
super();
response = new byte[4];
ByteBuffer bytebuffer = ByteBuffer.wrap(response).order(ByteOrder.LITTLE_ENDIAN);
bytebuffer.putShort(word0);
bytebuffer.putShort(word1);
}
public SingleCommandArg(byte byte0, byte byte1)
{
this$0 = RequestSequence.this;
super();
command = ByteBuffer.allocate(2).order(ByteOrder.LITTLE_ENDIAN);
command.put(byte0);
command.put(byte1);
}
--- End code ---
So, in the python code where frames are captured we have frame pixels count:
--- Quote ---0x7ec0 32448=208*156
0x41 65
private final int USB_TYPE_VENDOR_TYRIAN = 65;
0x53 83
private final int URB_SUBI_START_GET_IMAGE_TRANSFER = 83;
msg = '\xC0\x7E\x00\x00'
assert dev.ctrl_transfer(0x41, 0x53, 0, 0, msg) == len(msg)
--- End quote ---
However in java code they have something like this:
--- Code: ---int j=usbdeviceconnection.controlTransfer(65, 83, 0, 0, abyte0, abyte0.length, 1000);
--- End code ---
In your code you have something like this:
--- Code: ---# For some reason, we need to read the result in 4 blocks, setting the
# read length to 4*0x3F60 returns only 0x3F60 bytes. Why?? maybe it is a
# PyUSB thing, since it seems to work elsewhere.
data = dev.read(0x81, 0x3F60, 1000)
data += dev.read(0x81, 0x3F60, 1000)
data += dev.read(0x81, 0x3F60, 1000)
data += dev.read(0x81, 0x3F60, 1000)
return data
--- End code ---
Since 0x3F60 = 16224 = 1/2 32448=280*156, while we have 16bit raw data requested 32448 two byte words is 64896 bytes per frame which is exactly 4*0x3F60 :D
Not sure what 1000 means in this java code, but it looks like this what is done in python code makes now sense :-+
The most interesting thing is now if we could tweak frame rate at which we are able to capture thermal images from Seek camera, while quick review fo java code and no direct calls to set this frame rate, but maybe someone will find this >:(
Maybe there is some image processing mode different than 0x8 used in Android Seek dongle, so probably it should be safe to try different image processing starting from 0x0 to... maybe even 0xff >:D
--- Code: ---private final int URB_SUBI_GET_IMAGE_PROCESSING_MODE = 63;
private final int URB_SUBI_SET_IMAGE_PROCESSING_MODE = 62;
private final int URB_SUBI_SET_OPERATION_MODE = 60;
--- End code ---
Than try to catch frames in different mode and see if we are able to get something at higher frame rate :P
For the moment optimizing my gradient correction routines for end of month demo, so if someone have time to add small loop to python code to try different image processing modes it could be fun what we get :-/O
Maybe operation mode should be altered too, so two loops might be better-operating image processing modes from 0x0..0x8 first and operaions modes from 0x0...0x8 too :-DD
I can't see for the moment another way to change this frame rate-maybe they locked it in hardware in those image processing and operation modes...
eneuro:
@marshallh @miguelvp @cynfab @rickastro
After running automated tools for gradients detection on Seek sensor shutter calibration frames its output looks very interesting and maybe those efects depend on how long time this dongle was running, so this sensor response in shutter calibration frames 0x1 was so different accross those your devices? ???
NOTE: This is not gradients visible on output thermal image, just approximation of sensor shutter frames with 6 parameters polynominals, so I'm able to compute exactly place where those gradients are zero which means maximum (or minimum) marked with black cross on normalized shutter calibration frames surfaces.
It will be very interesting to see how this shutter surface changes in time and animate this from Seek device in ambient room temperature within a few working hours where it looks like inside around sensor was easy 36*C at 23*C room temp :-/O
miguelvp:
I took my Seek to the optometrist (my ZnSe 4" Focal length lens showed up today).
And my seek can read the label in my router. Edit: (The red Z doesn't show neither does a big red V over the whole verizon logo) the letters showing are white/silver and they probably dissipate heat quicker.
I don't have a good adapter for the lens yet, the 3d printed one a friend made me was too small because his printer wasn't calibrated.
Yushir0:
Fyi, seek appears to have pushed 1.6.0 to the android market which says it addresses the thermal gradient problem. DO NOT UPGRADE! Not only does the gradient appear to be unchanged, now all of the measurements are off by a huge amount! The device is completely unusable for measuring temperature on this new version. Example, a surface with a uniform temperature that I know for sure is around 30 degrees Celsius is coming up as around 84 degrees now.
Galaxyrise:
--- Quote from: Yushir0 on November 27, 2014, 06:41:59 am ---around 30 degrees Celsius is coming up as around 84 degrees now.
--- End quote ---
84F is around 30C... coincidence?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version