Products > Thermal Imaging

Indigo Systems/FLIR Phoenix MWIR Camera and interfacing with it

(1/2) > >>

I've been experimenting with this camera off and on for some months and while the project isn't quite complete, I've got all the basic data connections established and have a whole slew of difficult to find specifics on how to work with these cameras, so it's time to share!

The Indigo Systems Phoenix, later bought by FLIR and resold under their brand, is a series of scientific thermal cameras that comprise of a camera head and some kind of capture/image processing electronics.  They come in a lot of flavors and configurations, but the majority of them seem to be cooled MWIR cameras based on InSb FPAs - mine is the ISC9803 640x512 InSb MWIR head.

The camera head can be:
InGaAs for SWIR
InSb for MWIR
And can be cooled by either a linear sterling cycle cooler or by an LN2 dewar

The sole connector on the camera head is a D38999/26FD35SN, which mates with a  D38999/26FD35PN (as the RTIE manual states), but a few different part numbers will work as long as it's 37 pin at the right pitch and keying - there are a few connector material choices with different part numbers.  The head runs off of 24V and will power up and chill down the sensor with just power applied (my initial testing).  Data connections are done through RS485, so presumably the framegrabber for a DAS system is RS485 based, but I haven't seen the low level software nor hardware to confirm that, though it could be a vehicle for hacking into the head alone.  Worth noting that these D38999 series connectors while being quite expensive ($30+ on the used market, $100+ new), are the best connectors I've ever used or worked with, bar none.  They have an annoyingly loud ratcheting action, but everything about them assures you that they will work reliably in every configuration for a long time - tight tolerances, smooth actuation, a self-pressing set of pins that are fully enclosed and aligned even with compliant mounts, and a method of inserting pins when assembling them that actually can't seem to go wrong (they include a tool for it and the instructions tell you to push until the pin bottoms out, which is very obvious when it happens even when not using the tool).

The head connects via an umbilical cable to to some kind of imaging electronics, either an RTIE (what I've got), a DTS (later, FLIR branded, integrated GigE), or a DAS (computer framegrabber card based, seems to be primarily for earlier Indigo branded software but offers the fastest read speed and framerate).  In the case of the RTIE, that then connects to an RS422 framegrabber and serial control, or when paired with somewhat more modern FLIR branded software, it basically requires a Pleora iPort PT1000 module to control over Gigabit Ethernet.  In the case of the DAS, I believe there's a module that injects power into the camera head and changes connectors to what goes into the PC framegrabber.

The power supply is 24V, with a maximum draw in the 3A ballpark with electronics, I'm using a 3.75A Meanwell switching supply and it's had no problems.  The video output on the RTIE is a DB37 connector with RS422 interface connections (14 differential data connections and some sync connections), but the camera control connections are all on a separate DB9 talking through RS232 at a default 19200 baud rate.  The power connector is a WW Fischer S103 A052-60, and the SVideo out is quite convenient for testing basic functionality.

My RTIE is connected to a Pleora iPort PT1000-RS422-V2-E through a custom cable.  The RTIE manual mentions that the firmware needs to be 3.8 or more recent (which seems quite old) and mentions it being the PT1000-IDG which was made for Indigo.  The PT1000-RS422 seems to be effectively the same hardware (and same pinout as the PT1000-LV LVDS version), but I believe the default settings are different, which could contribute to some software issues I've had.  The PT1000 has an EEPROM but when I dumped it, it doesn't appear to be for power on defaults or configuration, so that appears to be all loaded into program Flash through the SDK for it, which of course is licensed.

While I'll discuss software in the next post, I needed one extra bit of hardware for my configuration to work: a hardware baud rate converter.  Either the defaults for the PT1000 or some other reset command in the control software I eventually got working (FSWin) tells the UART in the PT1000 to run at 9600 baud even if configured through Coyote to run at 19200, so I needed to make a go-between to translate 9600 to the 19200 needed by the RTIE, which in the demo was an arduino and RS232 level converter.  It looks like a mess, so I'll build it onto a proto board at least, but I'm hoping I can get software that can make the connection without resetting the port speed (or just setting it again after) so that it's no longer necessary.

That's the basics of the hardware involved, and this is the kind of video I managed to get out of this setup:

Still some work to do with getting more comprehensive camera control and image processing, but the communication links are established and preliminary quality looks good!

On the software side:

Basically nothing current or previous generation likes to interface with the Phoenix, so a patchwork solution is the best that I've got so far.  I am currently using FSWin from the Themovision SDK 2.6 to communicate with the camera and Pleora's Coyote application for digital video capture.

I was told by FLIR that ThermaCAM Researcher 2.10 will interface with it.... but Phoenix isn't even in the camera selection menu.  In Researcher 2.9, it's in the menu, but it always says "device not present" even when connecting through an already verified channel - and there's no output from the PT1000's serial port, so I think Researcher 2.9 is probably looking specifically for the DTS module and just doesn't work with the PT1000.  The LabView SDK 3.3 claims to be able to interface with it in documentation, but in the sample VIs there is no listing for the camera, and I haven't been able to get them to fully run even by manually adding the Phoenix to entry 10 in the VIs - I am fairly new to LabView so it may be possible, but I haven't manged yet.

Most other FLIR software doesn't seem to be able to talk to it - ResearchIR may be able to, but this project has been going on long enough that my 30 day trial expired before I actually made the connection properly, so I'll have to find another machine to try it on at some point.

The camera was originally designed for Talon, IRView, and a GUI made by Indigo (probably for Windows 98/2000), then when FLIR bought Indigo, RTools seemed to be the control software of choice, but I haven't been able to find any of those to try.

The SC6000 GUI actually sheds some light on the problem - an SC6000 seems to basically be a Phoenix and a DTS in the same chassis - but if you enter the maintenance mode (described in another thread, but Ctrl-Shift-M then enter password "indigo"), you get access to a menu that will format Phoenix commands.  It can't send them - sending them crashes the program even under Windows XP - and you don't know what the command is, just the hex value, but you can format a hex command with proper CRC in the SC6000 GUI and then send it via a terminal to the RTIE and get what appears to be an appropriate response - the 0x0001 command returns "phoenix camera" in ascii, the 0x0020 command appears to reset the video feed (a bit of garbage/interlacing issue then a second later it's fine again), and somewhere in the 60 or so commands I tried sending (with no data, just the command itself), I managed to fix the gain on the analog output and I think tinker with an NUC setting.  It would be a bear to try and reverse engineer the commands from the hex, but it's at least possible.

How did I eventually do it?  Well almost all the software in question is licensed... but if you download the Thermovision SDK and open the ISO, you can just open the .cab file there and copy the contents into a folder - giving you access to fswin, fsviewer, and the documentation (you have to append the .pdf to it) and the source code to each.  It's missing some file structure, but it does work.  Then you'll need FLIR's Pleora SDK redistributable components to get the iPort drivers and Coyote, which is quite useful for connecting with the camera and doing basic IO functionality.  I haven't been able to get fswin or fsviewer to show digital video - the program crashes without explanation if you set the video source to gigabit ethernet as well - but if you set the video source to File, the camera can still be controlled to a degree through the UART on the PT1000, and you can get the digital video through Coyote.

My first full connection to the camera over the PT1000, this is with Interlacing enabled but without enabling line sync yet, if I remember right.

In the thermovision SDK there should be all the camera controls needed to do exposure and gain adjustments as well as shutter calibration and whatnot, but these functions aren't fully listed in the sample applications they provide, so it would be a build-your-own GUI from the source code sort of effort (which it very well may come to).

I hope there is more to come on the software front, I'd really love a GUI application to control exposure, framerate, windowing, and shutter calibration that can also show video and adjust the palate/gain settings on the video - 14 bit image data only counts if you can view it in something other than grayscale on a monitor with 8 bits a channel!

Finally, a thank you specifically to Fraser for locating some documentation and starting off the troubleshooting, Peter who went back and fourth a bit with email in trying to get these things running, and ebay user rokkorcat for some extra info on the PT1000 and interfacing with other Indigo cameras.  There's so little information available and so little of it FLIR seems to know about, it would have taken many times the effort without the assistance.

Good work  :-+


Hey where did you happen to get the Pleora PT1000-RS422-V2-E ?

Ebay, nothing fancy.  I think the other PT1000 versions are pretty similar, but have a different output board/connector, and I'm not familiar enough with the protocols to know if one could easily be converted to another.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod