Jenoptik IR-TCM-384 thermal camera - ‘Box camera’ Teardown

[Fraser]

Having just used the VarioAnalyze program to look at the IR-Data images and compared them with zooming in on the JPEG version previously saved by the program, I can confirm that the image gets degraded. The unmodified IR-Data image is actually very nice indeed.

When using VarioAnalyze I can clearly see every single microbolometer pixel and even select the measured value of such. The program also provides a spread sheet style of presenting all of the captured pixels. The camera captures the full 384 x 288 pixels.

Once I save the image in JPEG it is upscaled to 644 x 432 pixels which is not a great situation  I shall have to look into stopping the auto upscaling as it does not do a very good job.

Fraser

[Fraser]

Ok, the up-scaling issue was my fault.

I had not realised that when you zoom in on an image in VarioAnalyze it not only upscales the displayed image, it also saves the up-scaled version when you select 'save-as'. Examples attached at 100%, 200% and 300%. All have JPEG compression but the available TIFF format would be better.

Fraser

[Fraser]

I am uncertain how much more I can post about this model of camera, and the PC software, that will be of interest to the readership. I may park this thread for now and move onto another thermal camera repair. I have a Guide M3 / SPi RazIR and a Keysight U5855A to look at. Then there is the Stirling Cooled Amber Radiance 1 to explore ! Not forgetting  looking at the Ideal HeatSeeker camera and upgrading my FLIR E40 to E60 spec. So much on the to-do list !

These Jenoptik cameras have been an enjoyable little project for me and I hope my long meandering commentary has not been too boring a read. I tend to write as I speak, so a lot gets written

Fraser

[WastelandTek]

Well, at the risk of being "that one fan", I am not even a thermal camera enthusiast and I found your detailed, learned write up interesting indeed.

I look forward to your next endeavor.

[Fraser]

Well I am pleased that this little story has been of interest. These cameras are just a bit out of the ordinary so I thought the readership might be interested in the technology within them and the potential issues that can exist in industrial cameras that have been deliberately 'abused'.

I am certainly very please with what I got for $250. The cameras are perfect for PCB thermal profiling and thermal fault investigations on equipment.

I am very aware that the story could have been very different had i not been able to find the controller software though. Some similar industrial thermal cameras do have the required software easily available but at a horrendous price. Always worth considering when looking to buy such 'special use' cameras. If this thread prevents just one person from wasting significant sums of money on an industrial thermal camera that cannot be used, it will have been worth my effort to write.

Fraser

[lukier]

I am very aware that the story could have been very different had i not been able to find the controller software though. Some similar industrial thermal cameras do have the required software easily available but at a horrendous price. Always worth considering when looking to buy such 'special use' cameras. If this thread prevents just one person from wasting significant sums of money on an industrial thermal camera that cannot be used, it will have been worth my effort to write.

Which is strange IMHO. The drivers for machine vision cameras are freely available from manufacturers websites - PointGrey / Basler / AVT / IDS / VRMagic and so on. At most registration is required.

Doing otherwise by the manufacturers means shooting themselves in the foot. At work we spend thousands of pounds on these cameras and lenses and if, let's say PointGrey, decided to charge for the Linux driver and C++ API we would promptly switch to the other brand, assuming they went mad. In the end there is no rocket science there, often sensors from the same manufacturers + FPGA + transceiver (FireWire/USB 3.0/GbE).

[Fraser]

Lukier,

The reason for proprietary thermal imaging and analysis software and its often high price goes back into the annals of time.

In the early days of thermal imaging everything was geared up for military and industrial buyers as they were the only ones who could afford such equipment. At that time a thermal camera cost several times that of a 2 bedroom house ! The cameras were treated more like specialist scientific equipment at that time. With such scientific equipment it was not at all uncommon for each manufacturer to have a proprietary control software costing a great deal of money. Everything cost extra, a bit like buying a German car ! In the early 1990's the Agema Thermovision 880 scanning cooled camera cost around £125K with its hardware controller, the lens was another £25K and conversion to a Stirling Cooler from LN2 was another £25K. The kit gave you real time viewing of a scene with only basic control over span and centre temperature. For analysis of images you needed the AGEMA BRUT computer. If you had to ask the price of BRUT, you could not afford it !

Later cameras became more integrated and offered conventional communications ports for connecting to a PC. These could be RS232, SCSI or IEEE 1394 and USB on later models. The old tradition of using proprietary software and charging for it continued. No two manufacturers used the same control codes or data sets in their software.

Why ? Well I believe it was just an attempt to prevent third parties producing software and to 'lock-in' customers to their products. Once you have invested in very expensive hardware plus software the OEM wanted you to trade-up with them when the time came and they would offer trade-in offers for cameras and software versions if required. Remember, there were very few suppliers of this technology, and that is still the case compared to conventional digital cameras.

In my experience the thermal camera market has a tradition of selling the customer a camera that can do basic thermography but true image analysis is seen as a cash cow by them. The OEM has the opportunity for a second bite of the Cherry whilst also committing the customer to their unique analysis software, and thus potentially their brand at time of equipment refresh. The software often came in different versions for different purposes. Some were image file analysis only whilst others offered remote control and more advanced analysis features. Yet more software offered report writing capabilities separate to the analysis side of things. Just like with Microsoft, the OEM's wanted to offer a suite of software packages on which they could effectively earn another income stream with sales and support contracts. The OEM's also had the advantage of a captive audience in their customers due to proprietary code, and their customers usually had deep pockets ! remember... from the customer procurement department perspective, this was NOT Information Technology software, it was Scientific Instrument software so they expected prices to be high. That was just the world of military and scientific equipment.

Were OEM's wrong to do this ? In my opinion no. They were a small number of companies producing a very specialist product full of 'black magic' that impressed the customers. Why not treat the cameras and analysis software as two income streams ?  PC software OEM's like Adobe base a business on writing clever image manipulation software, why not the same for thermal images ?
The cost of the software had the potential to vary vastly between versions, capabilities and OEM's. They charged what the market would pay. I still use some of the older software's that were very expensive in their day and I can report that some are embarrassingly poor in terms of the user interface and their capabilities. Some are nothing less than appalling cr*p ! But the customers had no choice remember, it was that or nothing, take it or leave it.

Over the years the software has come of age and has improved vastly when compared to the early stuff. It still comes in many different versions, still uses proprietary image types and control codes and can still cost a small fortune to buy.

I was pleasantly surprised when I saw that the FLIR Ex series came with a free non-demo version of FLIR Tools. That was the first time I had met a FLIR product that gifted analysis software to the customer and I believe it was because FLIR realised the importance of providing some basic PC software, and the shallower pockets of the intended customer base. Customers want to at least view and edit their images on a PC for reports etc. They were used to Digital cameras offering such after all. Offering FLIR Tools free was also an excellent vote winner for the customers who knew of the tradition for charging extra for such in the industry. Then there was the clever marketing tactic of offering a FLIR Tools+ upgrade that would attract interest from more advanced thermographers wanting more capabilities, who likely had deeper pockets to pay for it. Now as many will agree, FLIR Tools and FLIR Tools+ have their issues and are nothing amazing, but they are affordable for many customers and do 'get the job done'.

For the professional thermographer there is still the option to purchase the traditional more advanced software packages that still cost thousands of Dollars for a single licence. Unlike in the past though, customers are not left with this as the only option open to them. There are also third party thermal image analysis and reporting software's available, though many are still very expensive.

So in summary, Thermal camera PC software has traditionally been an extra cost, and a not insignificant one at that. It has not always offered good value for money either. Visible light industrial cameras are a different market that has possibly had different traditions when it comes to proprietary control codes and image formats. The technology certainly has a much larger OEM base than that of thermal imaging cameras, and the adoption of standards like Firewire may have helped with standardisation of image and control data. Firewire on thermal cameras was just another type of communications interface, with no effort to make any two OEM's products compatible with the others software.

We live in more enlightened times now however and I am pleased to see that many thermal cameras now come with at least basic image display and editing software. More advanced software is normally offered for those who need it and can afford the associated cost.

With regard to Jenoptik, they are an OEM who still wishes to maintain tight control over their software market and still like the idea of support contracts and additional fees for functionality unlocking. That is just their business model. Interestingly Jenoptik have been in some difficulty in recent years. Maybe their business model has become outdated when compared to others in their markets ?

Well those are my thoughts on this matter, others may have a different view on the industry.

Fraser

[lukier]

But my point was not on "thermal imaging and analysis software", let them charge whatever for that, I don't care, I write such software for a living. I believe it is the same for visible spectrum cameras, where people that don't want to code buy either Matlab or something like HALCON: http://www.mvtec.com/products/halcon/ or more industry-specific solutions.

My point was just the OS driver and something like C++ API to control the camera and access thermal or ratiometric video streams, that's all. It doesn't even have to be open source or standardized across manufacturers - it isn't in the visible spectrum cameras as well (with the exception of the FireWire standard that most cameras adhere to as I've mentioned in my previous post).

[CatalinaWOW]

I endorse Fraser's comments, and would extend that back a couple of decades.  The first thermal cameras were complex electro-mechanical beasts that usually had to scan a small array over the scene.  Small might even mean a single element, and was seldom more than 4x64 or some similar format.  Costs were stunning - even to military and industrial users.

In addition to Fraser's comments on software, think of it this way.  Each of the companies had software that interfaced to their own peculiar interface.  They had significant investment in this software.  Making it compatible with another vendors hardware would require additional investment and be vulnerable to defensive moves from the other vendor such as a change in hardware interface.  Making it compatible with a standard interface (PAL and NTSC were most of what was available) would put real limits on the data and open the income stream to others with little obvious payoff.

[lukier]

In addition to Fraser's comments on software, think of it this way.  Each of the companies had software that interfaced to their own peculiar interface.  They had significant investment in this software.  Making it compatible with another vendors hardware would require additional investment and be vulnerable to defensive moves from the other vendor such as a change in hardware interface.  Making it compatible with a standard interface (PAL and NTSC were most of what was available) would put real limits on the data and open the income stream to others with little obvious payoff.

Still missing the point. In the visible spectrum each manufacturer (PointGrey/IDS/Basler) has their own closed-sourced driver and API, with different image formats, API calls, driver architecture and so on, but it is publicly available so I can access the camera.

I even wrote a simple semi-unifying library for that: https://github.com/lukier/camera_drivers that implements back-ends for PointGrey FlyCapture SDK, FireWire DC1394, OpenNI2 (RGB-D Kinect 360), libRealSense (new Intel RGBD cameras), VRMagic SDK (OEM industrial cameras), libfreenect2 (Kinect One), IDS uEye SDK and classical Video4Linux2 API (USB webcams etc). Each of these is a completely different API, often closed source, with multitude of image formats, camera controls etc - don't care as long as the driver is available and somehow documented. Usually the functionality is very simple, i.e. set the camera mode to this and that, parameters to this and that, resolution and fps to this and enable stream, then one has to fetch the frame buffers (either via blocking or a callback, depends on a driver architecture). I don't need anything more.

[Fraser]

Lukier,

I see your point but, from the OEM's point of view, Software and Drivers are one and the same. They want(ed) to control the drivers and use proprietary code to protect their software market. There was absolutely no incentive for them to help others write software for their equipment. It might appear unfriendly of them but they wanted the income from the software sales to continue. Even now OEM's protect their proprietary code and offer only 'packaged' SDK's. Such are often chargeable.

Remember, the customer did not have much say in the matter. The technology was and still is very specialist with only a few OEM's available. You can threaten to not buy a particular OEM's product, but then the alternatives are little different so you gain little or nothing. It is a tough and well locked down market that offers the customer few options.

Remember SEEK Thermal .... Champions of the common man (woman) when it came to cheap thermal imaging ? Well they are just as tight lipped about their interface drivers. They are all the same on this matter. Only a good quality truly open source thermal camera would likely change the situation.

Fraser

[lukier]

I see your point but, from the OEM's point of view, Software and Drivers are one and the same. They want(ed) to control the drivers and use proprietary code to protect their software market. There was absolutely no incentive for them to help others write software for their equipment. It might appear unfriendly of them but they wanted the income from the software sales to continue. Even now OEM's protect their proprietary code and offer only 'packaged' SDK's. Such are often chargeable.

Remember, the customer did not have much say in the matter. The technology was and still is very specialist with only a few OEM's available. You can threaten to not buy a particular OEM's product, but then the alternatives are little different so you gain little or nothing. It is a tough and well locked down market tat offers the customer few options.

You might be right, while the machine vision camera market is rather niche (compared to, for example, smartphone camera sensors - some manufacturers make 1 million a month of these) the thermal vision market is even smaller with a handful of manufacturers, therefore much easier for them to form a cartel and play such games with vendor lock-in even on the low-level drivers.

Edit: but maybe the new manufacturers will break this monopoly - I was very happy when ThermalExpert provided me the Linux driver for my Q1 Pro. Closed source and crappy driver, but still something.

[Fraser]

The thermal camera OEM behaviour is very protectionist and some would say 'old fashioned' but they have the power to be like that and still survive I suppose.

Fraser

[Fraser]

Oh, does this situation annoy or disappoint me ?

Yes it does. Especially when OEM's refuse to offer any help with software or drivers for long obsolete products. But then they are are unlikely to earn money via new sales from me, so can I blame them ? No, but some companies are more friendly, like FLIR and E2V. I have no hesitation in recommending a company that is helpful to the 'little people'

Fraser

[Bicurico]

I just want to say that I love reading your stories about your cameras and their repairs, so please go on and be as extensive in writing as you want.

I always learn something and it is very interesting,

Regards,
Vitor

[Fraser]

Thank you Vitor 

[amyk]

Oh, does this situation annoy or disappoint me ?

Yes it does. Especially when OEM's refuse to offer any help with software or drivers for long obsolete products. But then they are are unlikely to earn money via new sales from me, so can I blame them ? No, but some companies are more friendly, like FLIR and E2V. I have no hesitation in recommending a company that is helpful to the 'little people'

Fraser

You said this yourself, which probably has a lot to do with why they're so secretive:

Just so people are aware, I will not be reverse engineering these cameras beyond what is needed to get them operational and any areas that interest me. These are a controlled Dual Use technology camera and I respect that status.

[Fraser]

Amyk,

Good point.

Fraser

[Fraser]

I was recently asked whether I had purchased a certain ‘exotic’ box format industrial thermal camera that recently sold on eBay. I replied that I had not, and advised that I tended to avoid such cameras due to the challenges often encountered in obtaining the required control software for these totally remote controlled units. Unlike the FLIR A40 box camera, these do not have a keyboard for local control.

I am resuscitating this ancient post by me from 2017 as I thought it might interest those who have not seen it previously. It details the excellent engineering of these industrial cameras, but also shows that without control software or a command set, they are not the best of buys unless extraordinarily cheap and you have the time and skills to reverse engineer the command set from the firmware.

I hope this old thread is of interest to some.

Fraser

[Fraser]

As an update to this thread, I have now identified the use and component connected to the Lens contacts 

For those unaware, the camera requires a lens to be connected that is identified to the system via its two gold lens contacts. If a suitable lens is not seen by the system, the aperture wheel moves to protect the microbolometer so the camera cannot be used.

I was recently contacted fir help with an IR TCM 384 camera that does not have a lens. I had already considered the possibilities when it came to the use of the lens contacts…they were…

1. Temperature measurement of the lens using Thermistor, Thermocouple or simple silicon diode.
2. Lens identification using some unidentified 2 connection IC

After some simple tests I discovered that the resistance across the lens barrel contacts was in the Mega-Ohms in both directions but it did display a 0.6V reading in diode test mode and and an O/C in the opposite polarity. This suggested to me. That I was dealing with an IC of some sort. The obvious possibilities were a temperature measurement IC or an ID chip.

There are only 2 contacts in use here as the lens barrel is not used as an electrical pathway. I immediately thought of the common Dallas iButton units that use only 2 wires for data I/O operations. The 1-Wire system is used for this. The possibilities remained if either a temperature sensor or ID chip but the owner of the lensless IR-TCM 384 read the user manual that I had provided and highlighted that the camera was able to identify the exact lens that is fitted, whether it was the serial number against which it had been calibrated and whether it was even the same lens type. Suddenly, lens ID became the more likely use of the contacts.

As luck would have it, I purchased a couple of Maxim 1-Wire serial communications adapters on eBay a few years ago. I was looking at 1-Wire systems used on laptop batteries and the Maxim adapters were very cheap so added to the “may be useful some day” stock in my lab I dug out the two serial 1-Wire adapters and an iButton that I had and tested the Maxim 1-Wire viewer software on a laptop that is equipped with a real serial port (not a USB to Serial adapter) The setup worked perfectly and read the iButton with ease. My iButton was an eeprom and I suspected the lens ID chip would also be an eeprom of some sort, likely with very small memory capacity.

I tested the iButton with my multimeter in diode mode and saw the exact same 0.6V / Open Circuit readings as found on the lens barrel. This gave me the correct pin out of the lens barrel connections as well. Using a couple of jumper wires I connected the 1-Wire interface to the lens contacts and was immediately rewarded with the unique ID number and the device type identification of the 1-Wire IC within the lens  The device was not the eeprom that I had expected to see, but rather a DS2406P 1-Wire 2 output switch ! That surprised me so I quickly downloaded the data sheet. Whilst I cannot explain the use of a 2 port switch in the lens, I did find that that DS2406P also contains a user programmable OTP EPROM of 1Kbit in size  This was what I was looking for as it would likely contain data unique to my lens.

https://datasheets.maximintegrated.com/en/ds/DS2406.pdf

Using the Maxim 1-Wire viewer software I was able to display the contents of all of the DS2406P data areas so could clone the IC if required. The switch function could potentially be used in some lens versions to select an electric lens cap or even change the FOV setting on a multi FOV lens. My lens does not appear to use this function though.

More from me on the data that I found inside the lens in the next instalment.

My thanks to the owner of the lensless IR-TCM 384 for focussing my attention on the cameras lens contacts again as they had long dropped off my ‘Radar’ as I have the original Jenoptik lenses to use with my cameras.

Fraser

[Fraser]

Next installment.... the data collected from the 1-Wire DS2406P IC.......

And what does the EPROM data say ? See my next Post 

[Fraser]

The translation of the EPROM data into plain English using a Hex converter. Yes it is that simple in this case !

My thanks to "Golden Wedge" (the other IR-TCM 384 owner) for doing the Hex to ASCII translation for me as it was late when I downloaded the data.

The lens details written on its barrel are as follows:

COASTAL IR 2.0/50mm LW CLOSEUP LENS 707033 SN/COA7513

For anyone not wanting to download the attached PDF file, the DS2406P EPROM Data pages translate as follows:

Variocam II closeup lens
IR 2.0/50 LW
COA7513
707033_1
Y ? ? ? ? (In decimal this reads as 89290011)

The last line does not translate to English so may be a build date code or other 'in house' code for the lens

The contents of the EPROM data fields provide everything the IR-TCM-384 camera needs to identify the lens that is connected to it.
My 25 pin version of the Maxim 1-Wire interface has the added capability og being able to provide a 12V programming pulse for EPROM's. The normal 5V based serial adpaters cannot program 1-Wire EPROM's but they do program 1-Wire eeproms.

With my Maxim DS9097U 25 pin serial 1-Wire interface I can create a clone of the DS2406P that is used in my lens so that 3rd party lenses may be used on the Jenoptik IR-TCM camera

Fraser

[Fraser]

For completeness, here are the Data screens from my other Jenoptik camera lens. All details are the same except lens serial number an the final data field.

The lens barrel detail is as follows:

COASTAL IR 2.0/50mm LW CLOSEUP LENS 707033 SN/COA7760

The final data field is 50 1E 00 00 0B Hex which is 80300011 Decimal. The other lens reads as 89290011 Decimal. This does not look like a build date. Only the first 4 digits appear to vary. This does not matter much to me but interestingly the numbers do have a pattern..... 80 30 and 89 29. It could be coincidence but the second digit of each pair are the same in each case.

Fraser

[Fraser]

The DS2406P IC’s have arrived 

Thankfully the 6 pin IC has 1.27mm pitch pins so I can easily attach a couple of wires to it for programming and testing on the camera chassis to see how it behaves with the clone. More when I have had a chance to program and test the IC.

Fraser

[Fraser]

Update..... 'Disaster' strikes:(

I just tested one of the 'new' DS2406P IC's ready to program it and ........ it already had data in its EPROM memory area 
These IC's are OTP and data cannot be erased from the EPROM (not eeprom) so the IC's are useless to me. I will recover my money from the seller but I now need to source some truly new, unprogrammed parts so there will be a delay 

When is something 'New' not 'New' .... when it is delivered pre-programmed with someone else’s data !

I attach the data revealed by Maxim's 1-Wire viewer software

Fraser