Is the TE-M1 a software downgraded TE-Q1 ?

[Marvin_324]

Hi guys

I recently got a TE-M1 and a TE-Q1 thermal imager on my desk that I need to integrate in Linux.

From the outside these two imagers look exactly the same - Same housing, same lens, same packaging
The thermal sensors also have the same size.  The only visible difference is the TE-M1 imprint on the camera (TE-Q1 has no imprint).
I did not want to open the housing as I need to return the cameras when I am done with my work but it looks like the TE-M1 has the same hardware as the TE-Q1 and is just downgraded by software.

Can anyone here confirm my assumptions?
If it is really the same hardware?
Has anyone tried a "Firmware upgrade" for the TE-M1 to get from 240 x 180 to 388 x 288?
It would be good to know if this is possible as I am thinking of getting a TE-M1 for myself.

There is much to find about the TE-Q1 in this forum, but nothing on the TE-M1 (or I was too stupid to find it). 
I attached some pictures.

[Fraser]

I cannot confirm your hypothesis, but it sounds sensible.

In the world of Microbolometers, cost has been reduced by scaling up manufacturing to provide a lower cost per FPA. Manufacturers of the FPA's normally have set sizes of array, such as 160 x 120 and 320 x 240 etc. The 'mass produced' FPA may then be installed in any number of different cameras and it's resolution set in the firmware. 'Windowing' is offered by many Microbolometers to allow an OEM to set the cameras resolution with ease. As you will know from the E4 thread, the best situation for a manufacturer is often to use a common hardware platform to achieve cost savings due to scale, then hobble some models to meet the needs of less demanding tasks or cheaper market sectors. Building unique cameras for each market segment would make little sense these days.

Be suspicious of any 'unusual' resolutions that depart greatly from 160 x 120, 320 x 240, 384 x 288 or 640 x 480 as such normally suggests windowing in firmware or down-scaling. OEM's who wish to maintain the same FOV and lens across a range do this through pixel combining, down-scaling or other video processing techniques. The E4 uses video processing to degrade the resolution as the FOV and lens are the same in all Ex models.

Whether the firmware in one of these cameras can be easily or economically changed to release the Microbolometers full resolution very much depends upon how keen the OEM is to prevent such activities !

Common microbolometer resolutions are shown on the ULIS page here......

https://www.ulis-ir.com/catalog/thermal-image-sensor.html

Fraser

[Vipitis]

That is interesting.

the TE-M1 is like 449€ from the store directly and having a resolution of 388 x 288 with it would be really great.

So let's check the facts. Only the european store and website lists it. It looks identical: https://www.thermalexpert.eu/english-1/product-overview/ even the data sheet is the same with new values for resolution and fov badly copied in(in other colors, size, font and places)... they offer a 30hz verison of the low resolution model?

both sensors use 17μm sensors... and i3 only sells the core in two resolutions: http://www.i3-thermalexpert.com/products/oem-core/ and http://www.i3system.com/eng/n_product/product101.html

It would be great if you could do some tests but taking pictures from the same place with both cameras and all lenses you have. the FoV change sounds like a window mode to me as well... next step would to compare files, maybe try to get firmware files like updates and see how the differ.

[Fraser]

I just looked at the datasheet, thanks to Vipitis providing links.

The difference in resolution between the M1 and Q1 models is 1\1.6 in the horizontal plane. This matches the almost 1\1.6 difference between the two cameras FOV when fitted with a 6.3mm lens. This screams windowing to me. Only the centre portion of the microbolometer is being presented to the user. Some OEM's effectively just use the 'electronic zoom' feature to lock a maximum FOV and resultant resolution. So it would be like a Q1 model set at x1.6 Zoom.

Fraser

[Vipitis]

hmm... this gives more hints as the Q1 (and V1) offer digital zoom, to like 120x160 and some other factors... not 240 x 180 specifically.

[Ben321]

The hard part about hacking the firmware, is learning HOW to hack the firmware. Unless they are designed to have the end user upgrade the firmware from firmware downloads from the hardware's manufacturer (in which case the manufacturer's website will provide a firmware flashing tool), there would be no easy way to do it. You would need to see if the microcontroller in the device supported a USB command for flashing the firmware, and this would require de-capping the microcontroller itself (carefully grinding off the ceramic case of the mincrocontroller chip, without damaging the silicon underneath), and then put it under a microscope and look at the wiring of the transistors. From that you should be able to figure out the hardwired program in the microcontroller, and then decompile the bit-code into assembly code (assuming you know the microcontroller's instruction set). From that you should be able to find out what USB commands it recognizes. However, this would require something like an FBI computer forensic lab, with MILLIONS of dollars worth of reverse-engineering equipment in order to properly de-cap the microcontroller without damaging the silicon.

[tmbinc]

Rule 1: Don't panic.

What you describe is the worst-case scenario. I haven't seen good board pictures, but it seems the system is build from a few discrete components. Firmware could be stored in a discrete flash part, for example. Has someone analyzed the regular USB connectivity? Maybe it's as simple as setting the right resolution which the host software doesn't do if it doesn't detect the right Camera. Or maybe there's a USB command that is buggy and could be used to read or write more or arbitrary memory from the camera. Has someone analyzed the Android or Windows software to see if there is a hidden firmware update ability inside? Has someone poked at all test points, maybe there's a debug UART or something else interesting to observe?

I can't rule out that they spent a lot of effort into securing this - and this is all assuming that it uses the same sensor, which - while likely - hasn't been confirmed yet. But don't panic because it _could_ be hard. A good strategy is to assume that the simplest method works. Only once you ruled it out, try the second-simplest, etc. Assuming upfront that only the most complicated method works, and then saying "but I don't have the equipment" is not a very viable strategy .

[Ben321]

Rule 1: Don't panic.

What you describe is the worst-case scenario. I haven't seen good board pictures, but it seems the system is build from a few discrete components. Firmware could be stored in a discrete flash part, for example. Has someone analyzed the regular USB connectivity? Maybe it's as simple as setting the right resolution which the host software doesn't do if it doesn't detect the right Camera. Or maybe there's a USB command that is buggy and could be used to read or write more or arbitrary memory from the camera. Has someone analyzed the Android or Windows software to see if there is a hidden firmware update ability inside? Has someone poked at all test points, maybe there's a debug UART or something else interesting to observe?

I can't rule out that they spent a lot of effort into securing this - and this is all assuming that it uses the same sensor, which - while likely - hasn't been confirmed yet. But don't panic because it _could_ be hard. A good strategy is to assume that the simplest method works. Only once you ruled it out, try the second-simplest, etc. Assuming upfront that only the most complicated method works, and then saying "but I don't have the equipment" is not a very viable strategy .

The problem is, while a few people on this site have bought the Q1 or M1, nobody has opened it up yet (I guess they don't want to risk damage their expensive equipment), so we have no way of knowing what's really inside (such as the model number of the microbolometer itself).

[Vipitis]

Hm yeah, no teardown of either camera yet. Maybe different i3 cameras that were software downgraded to compare to?

The windows software can be downloaded here.... http://www.i3-thermalexpert.com/support/analysis-tool/ I think there is a uncompiled version as well, but I haven't been at my computer to look into it. I don't think the USB communication would just set the command to dissolve the digital zoom, as it's most likely locked far deeper in the system.

If we see the insides we can try and assume where the firmware is located on. Try to access the Q1 version and flash it onto the M1 if the flash utility is available from the manufacturer. I haven't read about any firmware updates for the TE at all.

[Marvin_324]

I made a picture with the two cameras from the same spot and integraded the TE-M1 image into the TE-Q1 image.

Like you guys assumed it looks like windowing is used.
The strange thing is that for some reason they did not put the window in the center but in some corner of the sensor.
I do not understand much about thermal imaging but this doesn't seem right.

Maybe I should ask if there is a firmware upgrade to fix this 

[Fraser]

That suggests they are not using an electronic zoom function, but rather use a limit on the number of rows and columns that are used from the microbolometer ROIC. That is to say pixels 1 to 240 of 388 and 1 to 180 of 288 in their respective row or column. YUK! That means you get a corner centric image that is using the worst areas of the lens characteristics. A lens usually performs best at its centre and distortion/ defocussing tends to creep in at the edges. Thermal camera lenses are relatively simple designs, unlike modern Digital SLR lenses. This would not be my choice of resolution crippling options ! There would be the option to move the microbolometer to align the centre of the 240 x 180  microbolometer 'active' area to the centre line of the lens, but I very much doubt they would bother to do this in the M1.
Your pictures also appear to support my doubts.

Fraser

[Fraser]

It would be interesting to view a grid with the two camera to see how much distortion exists in the H and V planes for each. The M1 may look pretty weird unless they have oversized the lens system or have a really excellent lens geometry.

A cake cooling grid heated under hot water would work as a grid, especially if not a shiny type. An alternative is strips of Aluminium foil placed on a radiator. The difference in Emissivity makes the required grid image.

Fraser

[Vipitis]

If this in infect the case... It is really stupid. Not only image distortion will happen but also it is off center aim.

Maybe this is the attack angle on the support. Say that you believe your sensor has an issue because the center where you aim at appears at the very corner of the frame. If they don't write you off and work on this, they might just read out a different part of the sensor instead. At least we get some firmware and maybe utilities to look at.

Looking for the grid image, same setup could tell us if they somehow adjust for edge distortion.

[joe-c]

Hello,

it would be interesting to see if the TE Q1 and M1 are similar.
My TEQ1 is no more in normal case, my hardware mod is not done, but the core is fixed to a Shutter and Lens combination.

@ Marvin
you have both devices, please do the following:
- connect the M1 to your phone
- connect the Q1 to a active USB-Hub (just provide USB power), wait a few minutes
- Remove the lens of the Q1 and take a image as close as possible... with the Thermal camera you can see the FPGA array behind the detector window.
- then change both cameras and do the same.

the result images will have different resolution but it should be possible to see if the Sensor array have the same size.
best wishes
joe-c

[Vipitis]

I have been eyeballing a new thermal camera for some time. The new TE-M1 is nicely priced and can so far only be purshases though the European shop. If I can manage to get it in 30hz with a license.

I'm okay with opening it up and identifying the components, as soon as we get a hint to a possible firmware modification.

[Fraser]

There is also the issue of microbolometer specific calibration tables. If the M1 is calibrated at the lower resolution then any 'upgrade' will need to include creating new calibration tables. Hopefully the camera is calibrated at its full resolution and then the hobbled to the lower spec.

Fraser

[Vipitis]

if the whole idea is to sell the same hardware at different price points. It would be tedious to differentiate on a manufacturing level. It could be that the lower spec units use sensors from a lower bin with worse performance or maybe other issues. The easiest would be to flash the firmware from an image onto the different devices after all manufactureing and testing/calibration. And there should be two different firmware versions with the sensor readout artificially limited on some of them.
Given that they use a specialized process to install all firmware and software on the dives that works in a factory setting - it won't be a simple USB plug in and wait for the end consumer.

I will try to investigate more into how it's done by talking to i3 and asking for some firmware files and checking patents and agency filings with teardowns.

[Klaus]

Does anyone know if a version with 25hz is available?

[Vipitis]

there is supposed to be a 30hz version for the M1 if you got a export license. But I have to ask them how.

I looked through the international website again and found that they even sell a Sensor only with 192x144 resolution. It's 12 um pich so won't be in any of the TE1 models. But it strangely has he same dimensions as the very same Sensor with 384x288 resolution. Check here: http://www.i3-thermalexpert.com/products/qvga-uncooled-infrared-detector/

So they not only sale the TE models as smartphone imagers, also cores for OEM and developers as well as sensors for integrating. On the website they talk about a EQ2 and EV2 version of the core in 12um - which makes me believe that they will soon put out a second series of their imagers. How soon that will happen - can't speculate on this. But maybe the european shop is triying to get rid of stock by simply crippling the device and sale at a lower price.
My current theory to why the M1 only showed up on the european store.

A sign that worries me is that they advertise their sensors with windowing ability, so it is possible to cripple the resolution at a hardware level.

[mahony]

I just bought a TE-V1 30Hz from this seller - no issues there but they ask a somewhat higher Price for the 30Hz Version - not sure how much on the TE-M1 actually.
Buying it is no pain here. The distributer just takes the money and sends you the camera - no paperwork at all. And I can confirm that the V1 does the 30Hz easily on a PC - on my Xiaomi Rednote 4 it does probably ~15fps @640x480 and much faster in the lower resolution modes. I did not measure it exactly so far. With the M1 30fps should be o.k. on any medium range phone I suppose.

I also started looking at the new version of the new SDK (which also seems to support the TE-M1) and there is actually no serious difference between the Q1 and V1 except for some of the calibration data being hidden in different parts of the initial Frames. Even the USB VID and PIDs are the same on all cameras... ;-) And as is the case with the Q1, the performance is seriously crippled using the the phone App compared to going raw mode on a PC or any other platform! I'll post some pictures tonight maybe.

Edit: Looking at post 9 again I have to check if the new SDK i have really supports also the Q1 and M1 cameras - I think it might have been V1 only?! If so I might be able to tell you rel. quickly if the M1 just reads a partial frame or a full frame and discards some of it for display. The other option is downloading the current apk and extracting the java code from there...

[mahony]

@Marvin: I can send you over my Code/Software to read raw data from the TE-Q1 using the Zadig WinUSB Driver. You can try this with the TE-M1 and see what happens.

An additional note on the OEM cores. I initially tried to get one of those directly from i3 but this is not possible w/o being a company of some sort they want a tax number at least.
The 17µm cores should be readily available and the 12µm are now shipped to first customers - not me unfortunately due to lack of a tax number ;-)

[Ben321]

@Marvin: I can send you over my Code/Software to read raw data from the TE-Q1 using the Zadig WinUSB Driver. You can try this with the TE-M1 and see what happens.

An additional note on the OEM cores. I initially tried to get one of those directly from i3 but this is not possible w/o being a company of some sort they want a tax number at least.
The 17µm cores should be readily available and the 12µm are now shipped to first customers - not me unfortunately due to lack of a tax number ;-)

Why use Zadig WinUSB installer? From my understanding, there is a free-to-download SDK for the units from I3 (or Thermal Expert, or whatever the company is called now). It should be right their on their website (or it was to the best of my memory a couple years ago). This should provide the needed drivers and API to control the camera from within C++ or even Visual Basic (as long as the DLL file for the API exports STDCALL functions instead of CDECL functions).

[mahony]

Yes, right. You can use the SDK but you don't have to.
I prefer to not use it as it does some stuff I do not like (i.e. image processing, speed) ... Plus it offers more 'flexibility' when tinkering with 'unkown' devices such as the TE-M1. ;-)

[Ben321]

Yes, right. You can use the SDK but you don't have to.
I prefer to not use it as it does some stuff I do not like (i.e. image processing, speed) ... Plus it offers more 'flexibility' when tinkering with 'unkown' devices such as the TE-M1. ;-)

Doesn't the SDK allow you access to the raw unprocessed image from the camera?

[mahony]

Yes, right. You can use the SDK but you don't have to.
I prefer to not use it as it does some stuff I do not like (i.e. image processing, speed) ... Plus it offers more 'flexibility' when tinkering with 'unkown' devices such as the TE-M1. ;-)

Doesn't the SDK allow you access to the raw unprocessed image from the camera?

Yes, but as soon as you want to get to the temperatures you get either the full Image blurred or you have to do it Pixel by Pixel which is slow and not very comfortable. Besides that I do most of my coding in C# which wasn't a big deal with the old SDK structure as there were just like 10 DLL calls but the new one returns a pointer to camera class which is a real pain when using it apart from C/C++ i.e. through C# marshilling/interop.