DIY ICX453AQ, Sony sensor CCD camera

[luka]

Great thinking Glen (and Rowland), I will have to check that tomorrow.

[luka]

Update:
1. The back of the sensor is not grounded. The multimeter shows infinite resistance to ground and no voltage when the camera is on but this is only half of the story.

2. If the back of the sensor is grounded (via an electrically conductive thermal paste (Arctic Silver 5) to a grounded cold finger) the camera does not start. Considering that the USB does not even register on the computer, some voltage (3.3V?) must be pulled down.
In other words, if the back of the sensor is grounded bad things happen. Luckily the camera survived.

3. If a non-electrically conductive thermal paste is used the cold finger can be grounded and the camera works but the stripes are visible. I did not notice much change in the stripes if the cold finger is left floating.

4. The best case scenario... a floating cold finger electrically connected to the back of the sensor via electrically conductive paste.
The horizontal stripes are visible but only because I know what to look for. Or maybe I am imagining that they are there. However, they are quite visible in a stacked master bias file.

We may have to give up trying to PWM the TEC during the frame reads.

By the way, unlike here the grounding of the cold finger in a modified Canon 450D worked just fine and solved the noise problems.

[rcheshire (Rowland)]

Hi Luka. If it helps. The back of the 450D sensor (1000D and 550D) is not conductive. The camera chassis is ground and the cold finger is bonded to the chassis - and, it follows, to supply ground.

The apparent emphasis on bonding the copper finger to the camera chassis, was a matter of ensuring that the cold finger (antenna) and camera shared a common analog ground - when running the camera with batteries - separate from the cooling system supply, which is likely affected by PWM switching.

Irrespective of camera design, it should be cold finger to supply ground. On a single analog / digital board, I connected AGND and DGND with a 1uH inductor.

[luka]

Thank you Rowland, that clarifies a few things. I have forgotten about the back of the 450D sensor, it has been a while since I did the cold finger mod.

The Nikon D70 sensor that we are using has a metal back but the back is not grounded. The camera stopped working once I grounded it via a grounded cold finger.

So I can see two possible options:
1. Grounding the cold finger but electrically insulating it from the back of the sensor with electrically non-conductive thermal paste.
2. Electrically connecting the cold finger to the back of the sensor (but not grounding anything).

The 2nd option seems to give lower noise when switching TEC. It is also less dangerous than the first option which relies on the thermal paste making a perfect electrical insulation.

Unfortunately, while we minimised the switching noise it is still present. We are back to leaving the TEC on or off during the frame reads.
Or I can increase the switching frequency to bury the noise inside the image and pretend it is not there

[luka]

The new driver is out. Download from the usual spot.

Changes:
- I added a few delays in the low level driver communication to the camera.

I have noticed that some of the settings were not sent to the camera correctly during the initialisation stage. A quick and dirty fix was to add some delays to slow down the communication a bit. This is not a proper solution, the firmware will need some serious work on the communication protocols to fix the issue.

You may notice that now the camera is slightly slower to initialise when first connected. Otherwise there should be no difference.

No changes to the firmware.

[luka]

Another driver version is out, v0.7.10. Get it from here.

I approached the delay problem differently, this approach should work more reliably. Please update.

No changes to the firmware.

[luka]

New driver update is out, version 0.8.0. Get it from the usual place.

Changes:
1. The cooling power % is shown in the info section now (next to the temperature).
2. Image minimum, maximum and mean are displayed now.
3. Sped up the image processing time. Each image will be taken about 0.2-0.3 seconds faster now.
4. Several interface improvements.
5. Minor bug fixes.

Enjoy and please report any bugs and suggestions.

[luka]

A summary about the horizontal stripes:

1. They are not noise caused by the TEC switching. If I set the switching to be very slow (once a second) the stripes stay at the same intensity for the whole 1 second. Any electrical noise caused by the switching would not last that long.

2. They feel more like the gain or offset or some voltage is slightly changing, hence the darker/brighter stripes. Or some capacitive effect???

3. I measured voltages with oscilloscope to try to find any variations that happen at the same frequency as the stripes. I did not find anything but it is very difficult to detect small voltage variations on large base voltages.

4. If we use higher frequency the stripes start losing their sharp transition edges. Unfortunately we don't have proper PWM on the pin controlling the TEC and we cannot manually change the TEC pin fast enough during the frame reads. The stripes are clearly visible even if the TEC is switched on and off at every line change (1000 lines in 2 seconds).

5. The intensity of the stripes can be reduced if the cold finger is electrically connected to the back of the sensor by using an electrically conductive thermal paste, like Arctic Silver 5. However, they are still present.

6. If the cold finger and the back of the sensor is grounded the camera will stop working.

So, unless someone figures out what is causing the stripes I don't think it is possible to use the current TEC pin to have manual PWM during the frame reading.

Note that Rim said:

The peculiarity lies in the fact that it is necessary to properly connect the power wires supplying the "+" and "-" peltiers to the source of the power switching transistor, otherwise there will be some banding of the image. It is necessary to drive these wires separately from the input connector and it is better to use a separate connector for powering the cooling power section.

Not sure how that would help us.

Anyway, Cam90 uses a different pin for the TEC control and that pin has PWM. TEC is switched at about 500Hz and the stripes are not visible. So the only option for us would be to use the humidity sensor pin (which supports PWM), cut traces on the board and wire it to the MOSFET that switches the TEC. Or alternatively wire the humidity sensor pin to a separate MOSFET that is not mounted on the board - this would mean that no traces need to be cut.

[N_DD]

Hi,

I have recently updated to Windows10 creator edition, but due to space limitations I had to uninstall most of the programs on my imaging netbook. Now I have reinstalled everything and upgraded to ASCOM 6.3: I have installed the cam86 ASCOM driver (latest and V0.72) but I can't connect anymore to the camera. Using APT I get an error message, telling me that cam86.dll is missing (even if I click on "Properties" instead of connecting the camera).

Am I doing anything wrong, or did I forget to install something else? Anybody else on Windows10 and ASCOM 6.3?

Thanks,

Nico

[luka]

Hi Nico,

No problems here with Windows 10.

Try completely removing the driver first.
1. Uninstall the Cam86 driver (from Control Panel)
2. Open Windows Explorer and browse to

C:\Program Files\Common Files\ASCOM\Camera

or if you are using 64-bit Windows to

C:\Program Files (x86)\Common Files\ASCOM\Camera

3. You will see the Cam86 folder there. You want to delete that folder.
(By the way, can you check if the cam86.dll is in the folder first before deleting it).
4. Reinstall the driver and try again.

Let me know if you still have problems.

[N_DD]

Hi Luka,

thanks: the dll was there. I have uninstalled the driver using Control Panel, then reinstalled again, but I still cannot connect to the camera. Here is the error message from ASCOM diagnostics:

Create              Creating device
SetupError          Creating an instance of the COM component with CLSID {677DF06A-D784-4A3B-9028-D597E58131A4} from the IClassFactory failed due to the following error: 8007000b An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B).
Dispose             Disposing of device
Dispose             Completed disposal of device

From the ASCOM homepage, it seems that there might be some issue with security in one of the latest Windows updates. Unfortunately I cannot install the suggested update, so I am stuck! I have also noticed that the error code I get is the same one I was getting when trying to connect my camera using wINDI: in that case, the solution was to run wINDI as administrator, so a security issue makes sense. I will try troubleshooting a bit more in this direction.

Any suggestion is welcome!

Nico

[luka]

Can you send the link to the ASCOM page describing the security issue?

[N_DD]

Hi Luka,

look at the alert here and for a possible solution here. Also a nice discussion here
If that is the problem, I cannot uninstall the security update because I have installed the Windows10 creator edition, which supposedly comes with the updates pre-installed. Moreover, since your driver is dll based, it should NOT be affected, and it does not show up under DCOMCNFG (both 64 and 32 bit version).
I am a bit running out of ideas...

[luka]

This is a long shot, can you try copying the attached DLL into the folder
C:\Program Files (x86)\Common Files\ASCOM\Camera
(or C:\Program Files\Common Files\ASCOM\Camera on 32-bit Windows).

Just rename the old file first so you can restore it easily. You will need to close all programs using ASCOM first.

[N_DD]

Thanks: unfortunately it still does not work. Using the ASCOM Diagnostic tool, I get the following error message (only if choosing to connect to the camera in 32-bit mode, seems the driver is not registered as 64-bit):

Create              Creating device
SetupError          Creating an instance of the COM component with CLSID {677DF06A-D784-4A3B-9028-D597E58131A4} from the IClassFactory failed due to the following error: 80131524 Could not find the specified DllImport Dll. (Exception from HRESULT: 0x80131524).
Dispose             Disposing of device
Dispose             Completed disposal of device

Oddly enough, using Sharpcap I see the properties dialog f I choose the camera: I will try and connect the camera and see if Sharpcap manages to acquire images.

Any idea about what might be going on?

Thanks,

Nico

[N_DD]

Ok, that's odd: if I physically connect the camera, everything works fine and I can control the camera from APT, acquire images and so on. If I disconnect the camera, and just try to see its Properties from any program, including the ASCOM diagnostic tool, I get the same error!
Should the camera be connected in order to retrieve its properties?

Nico

[luka]

Nico, that is an excellent find.

The camera normally does not have to be connected. However I just tried my Windows 10 and got the same problem if the camera is not plugged in. I am sure everything worked fine a few days ago before I installed a whole bunch of updates. Thank you Microsoft
(No such issues on Win7)


The driver is 32-bit only, just like most of ASCOM. We cannot easily go to 64-bit as the low level DLL is written in Delphi and my Delphi compiler is about 10 years old and cannot do 64-bit.
There is an option, as mentioned here, to do an universal driver but I never got around to it.

By the way, you can use ASCOM Profile Explorer to change any camera settings. But I think only the Trace (logging) gets hidden when the camera is connected.

[luka]

A new version of the driver (0.8.1) has been released on the github.

I made the driver report strictly as 32-bit and cannot be selected from the 64-bit applications any more. This was the problem, at least on my computer. It looks like some Windows update changed something and 64-bit mode was attempted by default... or something like that

By the way, the ASCOM diagnostics can choose devices in 64-bit or in 32-bit modes and obviously the attempts to use it in 64-bit mode were not working.

Nico, can you try this driver and report.

I will look into make the driver 32 and 64-bit compatible but it will need a lot of work. Most of the ASCOM applications are 32-bit anyway so I don't think there is a rush.

[N_DD]

Hi,

I have tested the new driver and everything works!!! Great job!

Now, if I only had some clear weather... could you also fix that?!?!

Thanks a lot,

Nico

[luka]

Originally Posted by N_DD

Now, if I only had some clear weather... could you also fix that?!?!

I was thinking of adding a "Clouds off" button to the driver but could not get it to work reliably yet. Sometimes it takes days or even weeks for it to start working