Yesterday I tested both of my Radiance 1 cameras with UserMenu 3 and RTOOLS. I can confirm that RTOOLS works with the Radiance 1 but it is worthy of note that the installation offers separate Galileo/Radiance HS and Radiance 1 camera driver options. The user manual states that the two drivers are for the different bit patterns used by the cameras. I tried a 3rd party Radiance HS control program and, whilst it found the camera, it’s commands were ignored by the Radiance 1. I have yet to get UserMenu even seeing the camera ! Of note is the fact that UserMenu uses Com 2 serial port by default and whilst it is supposed to use Com 1 if started with “UserMenu 1”, this does not work and it still tries to open Com 2. I tried all sorts of command variations to get it to use Com 1 but failed. I had a laptop that could assign Com 2 to its hardware serial port via the BIOS but that did not work either. It is such a pity as UserMenu appears to offer a lot of useful utilities. I spent a whole day using various software and computers with the Radiance 1 and made some discoveries along the way. RTOOLS is the only software that would work with my two Radiance 1 cameras. I now have my original Series 1 PCMCIA card installed in the second Radiance 1 that has the V1.0 PAL configuration. I installed a nice Pretec 2MB Series 2+ card in my original camera and it is working fine with that thanks to its V1.1 PAL configuration.
Once I had RTOOLS working with the two cameras, I carried out NUC procedures for the 4 NUC memory locations. All went as expected and this corrected a “soft error” indication (normally configuration or calibration related) that had been present on the original Radiance 1 (flashing yellow temperature LED even when at operating temperature). The NUC used the internal temperature reference flag so was not as accurate as using an external large area Blackbody source, but it was good enough for my tests. The internal flag is heated and cooled using a Peltier module and has limited temperature range WRT ambient temperature. This can cause issues if a NUC temperature set point is too far away from Ambient for the Peltier to achieve within the preset timeout period. After an NUC process is completed I was able to check the Dead Pixel map details that were created from the NUC tests. I thought I had a bug in the NUC process as the original camera had over 1000 dead pixels ! After completing the same process on the second camera I saw only 49 dead pixels. Oh dear
I experimented with NUC settings on the original camera but, sure enough, it has around 1000 pixels that are either non functional, twinkling or out of acceptable tolerance range. For my needs this is no great drama, but still a pity. The second camera sensor array is in great condition and working well. The 49 dead pixels were the worst case scenario with other NUC ranges show far fewer.
When checking the cameras cooler hours I found that the original camera has less than 2000 hours on it but there is an anomaly with the hours counter on the second camera. It is indicating Millions of hours and many thousands of power cycles. This is likely the result of random data in the battery backed memory IC. Sadly the hours counter may have been lost when the Lithium battery died. I do not know how to reset that counter yet but it is not greatly important as the original data is lost.
Fraser