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

[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?

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.

Doesn't the SDK provide both raw sensor values, and a table of radiometric calibration data? That way you can perform the temperature calculations yourself to convert pixel values into temperature values, using your own temperature calculation functions in software you have created yourself, and don't need their API function for calculating temperature.

[Vipitis]

So.... I asked the support about the "alignment" issue of the not centered sensor crop/window. They got back to me and confirmed that a software and driver update is planned for end of September but they can't tell me if the issue will be resolved with it.

es ist für Ende September ein Update der Smartphone App und der Treiber geplant.
Ob das angesprochene Verhalten auch geändert wird, kann ich leider zum jetzigen Zeitpunkt nicht sagen.

so we will get an update for the drivers... I really hope it is actually not the end device software only, so people are able to look into that. I will keep pushing them on the issue and see if they can confirm anything to me that we speculated so far.

[bap2703]

If a software update can change the field of view that would be VERY interesting 

[Bill W]

If the sensor is underscanned (eg 320x240 on a 384x288 sensor) then outputting the whole 384x288 will change the field of view if you do not resort to pixel combination.

It all depends on how the windowing:output scaling is done.

Bill

[mikeselectricstuff]

It's possible, though probably unlikely,  that the low-res version uses a device-specific window to avoid bad areas on lower-yield sensors.

[tonykids]

Find that xinfrared also released T2S(240*180) and T6S(640*512)
For T2S,can it be a software downgrade of T3S?

[Fraser]

With regard to changing the configuration of cameras to release greater resolution, much depends upon how the resolution has been degraded. There are several methods that may be used to lower the resolution presented by a thermal camera, some, like the FLIR Ex, Exx etc series are simply a configuration file that needs to be modified to release the full resolution. Other camera designs use the code in the FPGA to both set the displayed resolution and to protect it from change. It can be challenging to reverse engineer an FPGA configuration file especially if the FPGA has integrated FLASH configuration memory and Flashlock or similar protecting it.

I feel we, as a community, have been very fortunate with the way that FLIR designed and configured their cameras in recent years. I have seen no similarly easy to reconfigure cameras from other manufacturers. Just the use of an FPGA in the image processing path can reall spoil your day when trying to reconfigure a camera.

I hope that the TE-M1 is not using an FPGA to set windowing but sadly such is a definite possibility as it is what I have seen in other cameras.

Fraser

[Vipitis]

my greatest hope right now is that they somehow move the window to be centered. and we can look at the firmware update and compare it side by side... even the assembly or machine codes will show the place where the instruction for window is and maybe we can go from there. We will wait for the software update end of September - it is supposed to be for the smartphone app. if they are smart about it... they could ask you to sent it back to adjust the window and do the firmware flashing themselves.

[Fraser]

Hi Vipitis,

I agree, the M1 configuration should be amended to bring the window to the centre of the microbolometer.
As we know, FPGA's are great as they offer field upgradeability unlike one time programmable arrays.

Let us hope the update sorts out the centring issue. Whether the update can help in better understanding how the camera is configured.... I have no idea as I am a Dunce when it comes to modern coding 

Fraser

[mikeselectricstuff]

Do we have a photo of the other side of the PCB? Looks like a fairly big SPI flash chip on the top side - could be config if it's just an FPGA or code for an MCU

[Bill W]

Find that xinfrared also released T2S(240*180) and T6S(640*512)
For T2S,can it be a software downgrade of T3S?

If you believe the datasheet, no as the 640 x 512 is 14µm pitch, the others are 17µm pitch.

Bill

[tonykids]

Find that xinfrared also released T2S(240*180) and T6S(640*512)
For T2S,can it be a software downgrade of T3S?

If you believe the datasheet, no as the 640 x 512 is 14µm pitch, the others are 17µm pitch.

Bill

I mean the T3S(384*288) downgraded to T2S(240*180),because in some chinese fourm said that T3S uses the sensor from I3

[Bill W]

OK, my misunderstanding.

As the T2S has a 6.8mm FL lens and the T3S has 13mm FL lens, it is not the same as the Flir E4/E8 scenario which uses the same lens across the range.
Unfortunately the datasheet does not include field of view but on that evidence, and iraytek do not do a 240x180, I would suspect it is windowed down not subsampling as FLIR do. 

If 'upgraded' you may get a 384x288 image but the corners would be pretty grim, and that assumes they have full frame calibration data at all.

[eb4fbz]

Do we have a photo of the other side of the PCB? Looks like a fairly big SPI flash chip on the top side - could be config if it's just an FPGA or code for an MCU

That's a Micron N25Q128A indeed, very easy to dump for further analysis.

[mikeselectricstuff]

Do we have a photo of the other side of the PCB? Looks like a fairly big SPI flash chip on the top side - could be config if it's just an FPGA or code for an MCU

That's a Micron N25Q128A indeed, very easy to dump for further analysis.

Though if it's FPGA bitstream, tricky to do anything with, unless it also contains code for an embedded cpu, obvious config area, or multiple bitstreams for different variants

[Marvin_324]

Sorry to keep you all waiting - I had a very busy week...

I got a first update from i3 - Android app only.
The image of the M1 is now centered compared to Q1 (attachment) - the small shift to the right is probably my mistake as I just did a quick test.
To me it seems they definitly use the same sensor and same hardware on Q1 and M1 imager.

Another interesting observation is that the 240 x180 viewing window on the M1 seems dynamically assigned and not hardcoded.
old Android app .... image in corner
new Android app .... image in center

So it might be possible to figure out the function call that sets the origin.
If we have that its just taking one picture from every corner and putting the image together to get the Q1 resolution.
Or maybe its even possible to increase the viewing window.

[frenky]

Try running app from their android sdk to  see if you get whole image:
https://drive.google.com/folderview?id=0B36fN1Q-Tg1AQ1l0aWFGVnVSUTg&usp=sharing

[Vipitis]

okay, that is really really interesting behavior. Do you have the old .apk saved somewhere? It would be interesting to know if it is able to go back again. That would tell us if they included a firmware flash with the new version to change the windowing - or if the app calls for a limited readout only.

Someone knowledgeable could potentially tap into the USB communication and figure it out. What about the desktop software - how does it behave?
If the imagers tells the app that it is the M1 version and the app than requests a limited sensor readout, it should be possible to just tell the app that you are a Q1 and supply a full readout.

Their update showed that it can be accessed with a software directly, so no hardware manipulation needed.

Great news, we are on to something. I sadly don't know a lot about decompiling .apks but it feels like it is possible.

The price point of 499€ is very competitive if we manage to get the full sensor resolution.

[Fraser]

It also proves that the full resolution is included at the NUC and calibration stages in the factory 

Fraser

[mahony]

Looking at the current SDK files / apk(s) I assume there are some command sets that are transfered to the camera.
Is there another Android App dedicated to the M1 or can you use the same app for both the M1 and Q1?
If you can provide both Android apps (old and new) they can be decompiled and changes isolated. Probably there is a possibility in software to just readout the full frame. Maybe they just use a software ROI at the moment - that would be even easierer!

What I find really interesting is the fact that the new M1 is also available as 30Hz Option - so even more interesting for only 499€!

[Fraser]

It would be worth checking the USB ID on both cameras 

Fraser

[mahony]

I would assume they are the same for both cameras. At least the TE-Q1 I own and the TE-V1 use the exact same USB VID and PIDs - I would be surprised if it was different for the M1. There are 3 id numbers embedded in the first flash frame header - those seem to be used to distinguish between different camera models. For the V1 it seems to be 1.1.1 but I have not yet checked the Q1's respective numbers.

@Marvin_324: did you receive an SDK (preferably the Android one) for the M1? Or maybe both versions for M1 and Q1? If not try to get hands on it please. I have current(?) SDKs for Q1 and V1 but missing the M1 so far. At least I cannot see any support so far in either for the M1 camera.

@Vipitis: decompiling a .jar or .apk is relatively easy and can be done from your browser, for example here: http://www.javadecompilers.com/

[Fraser]

Mahony,

I mention the USB ID only because it is a known way of influencing software behaviour with otherwise  identical hardware. There can be a lot of different USB PID's if a manufacturer desires such. Just look at HP in the attached link. The advantage for the OEM is that it is easy to impliment, challenging to change without hacking and prevents a software with greater capabilities working with an otherwise identical product that was supposed to operate with lower capability software only.

http://www.linux-usb.org/usb.ids

It is only a thought and easily checked. As you say though, the handshaking between host and camera can easily achieve the same result. In this case it just directs the software to configure the image processing in a particular way to limit resolution.

Fraser

[mahony]

Hi Fraser,
yes I know about USB PIDs but as I already mentioned - the Q1 and V1 use the exact same VendorID=0x0547 and PID=0x0080 - so I would be surprised if the M1 would be different. I agree it is worth checking but the answer might be 0x0547 and 0x0080.

[IwuzBornanerd]

But could there be something different in the device descriptor information, or is it required to be the same for a given product ID & vendor ID?  Anything that could be different and read by the software could be used by the software to differentiate units.