DIY ICX453AQ, Sony sensor CCD camera

[luka]

The loops are there as the Delphi/Windows timer does not work for durations over about 1000s. The loops are there to restart the timer every 900s so we never go over 1000s.

edit: Just saw your edit :-)

[gehelem]

Yep thx
I must check if this affects firmware's behaviour ("expoz" value to spi_comm)

[luka]

I don't think that got affected. Previously at 1000s the low level driver would read the frame and the camera would stop exposing. Right now the driver will actually wait the real exposure time before sending the read command.

But the loops are messy way to work around the issue. You should not have those problems.

[pat30]

Luka, a few times there is still the condensation warning message while I do not have the DHT 22 on the cam.

Here are my last tests!

[luka]

Pat:
1. Without DHT22 sensor the ATMega pins are floating and every now and then the camera will get weird reading instead of a "zero" reading. The software verifies that the values are reasonable (humidity between 0 and 100% for example) but with random inputs every now and then there will be a reading that seems valid and will cause the warning.

Perhaps the only way around this is a check box where people can select if they have DHT22 or not?

2. Regarding your comment about setting the min TEC power, I was looking at the debugging files only (my cooling is not working yet) and could not see a problem.
Gilles, have you noticed the issue?

One thing that confused me initially is that APT starts cooling as soon as the program is started. This means that it will start cooling with whatever option was left from the previous time. If you change the setting then it won't have any effect until the cooling is restarted. Could this be what you noticed?
In other words, changing starting power won't affect the currently running cooling as it is used only to calculate the starting power and not the current power.


Gilles, I could not reproduce the white line? Do you still have it? If yes:
1. What is your configuration, both ds18b20 and DHT22?
2. Can you disconnect from the camera and in ASCOM properties enable the trace (logging) and then take an image that shows a white line. Can you post the log file that can be found in Documents\ASCOM\Logs....date...



edit: Pat, where are your last tests?

[luka]

New Cam86 ASCOM driver, 0.7L is out. The firmware stays the same.

Changes:
- Added a checkbox to enable/disable the DHT22 humidity sensor. This should stop the condensation warnings when the sensor is not present.
- Small bug fixes

[gehelem]

@Luka : holiday trip to Barcelona at the moment
Stomac on tapas
Feet on Sagrada Familia
Hands on children
Head on Cam86, as often....
But i can't answer your questions at the moment...
Gilles
Edit : thank you for new driver

[pat30]

Luka, for the last tests I meant last bug found.

I going try the latest version as soon as possible, thank you again for this great work.

[luka]

Brendan, on our PCB did we leave a way for connecting +3.3V to DHT22 and also possibly for the temperature sensor DS18B20? I am trying to use DS18B20 in the parasitic mode (without voltage In) but it is not very reliable.
I cannot see any obvious 3.3V connections, apart for going straight for the legs of the regulator or the big capacitor.

Patrice and Gilles, do you use the DS18B20 in parasitic mode?

[gehelem]

I use mine in a "classic" way vin vout data and pull up on on pcb
What is parasitic mode ?

[luka]

In parasitic mode you can power the sensor using the data line (the Vin pin on the sensor is grounded). This way you can run the sensor with only one wire (+ GND). The sensor basically "sucks up and buffers" enough power from the data line to measure temperature and return a reading. It does not work too well on long wires and/or if the power is not that great.

By the way, I just rewired the sensor the "classic" way and it works fine.
The DHT22 and the TEC work fine as well :).

[pat30]

Hello friends,

Last night I tested the version 0.7L, everything is OK no bug found, thank you again for the work LUKA.

212918

[luka]

That is a very nice image Patrice. Thank you for testing the driver.

I have sent the driver to Vakulenko several weeks ago as he wanted to add it to his github instead of having two separate codes. As far as I can see he uploaded the firmware, the low level driver and the viewer source code but not my ASCOM driver. Not sure what is going on there.

[luka]

Is everybody's DHT22 working OK? Did you compare the readings with any other humidity sensors?

I started to test my camera again and it is incorrectly showing 20% humidity while it should be about 50%. The sensor is almost new so I am not sure if it broken or there is something wrong with the software.

Also while speaking of DHT22, the stated accuracy of +-2% is only for humidity over above 20%. It gets as bad as +-5% below 20% humidity. Very inaccurate for our purpose.
Also these sensors are notorious for breaking. Apparently most last less than 1-2 years.


I am looking into BME280 sensors now... +-3% accuracy across the whole range.

[gehelem]

hi
mine is working, but you're right, we don't have to expect more than it can do...
Comparison with another humidity sensor : nope
Comparison with another temp senor : yep
in fact, it's still interesting and gives an indication. When you open your camera for some reason, you can see if you close it well or not.
you can also be warned if your humidity sudenly raises.
I think if you consider there are only 4 values ("Good" "Bad" "Better" "Worse"), it does the job.:)
Gilles.

[luka]

Swapped the sensor, the new one shows 55% humidity. The temperature readings are the same.
So the new sensor is broken :-(

[gehelem]

BTW :

no news ?

[luka]

I have not heard anything from Vakulenko. He pushed all the code to his github apart from my ASCOM driver 2 months ago and there was nothing since then.

[perdrix]

Hi Bren,

Long time since this thread was last active.

What's the current state of play? Particularly interested in the cooling setup.

Cheers, Dave

[gehelem]

Hi Dave,

I can't say, but i'm sure Brendan and Luka are working hard on their setup :)
On my side (in France) this project is more than ever living, the boxing part is really the hard one.
You can follow our french forum if you want :
http://www.webastro.net/forum/showthread.php?t=141764
Or find information we've tried to gather here (you can easily use the "google translate" button on top) :
https://www.diycam.fr/index.php/fr/
It contains some informations regarding TEC cooling
Gilles.

[gehelem]

@Brendan,Luka

I've added an article to show how to use Excel to make automated cooling tests :
https://www.diycam.fr/index.php/fr/10-all/software/24-cam86-tests-de-temperature-avec-excel

Gilles

[flolic]

Too many things to do, too little time...

[pat30]

I like your work, excellent :thumbsup:

[pat30]

Flolic, how did you dry the air between the sensor and the window when you removed the matrix ?

[flolic]

I did not :P
That day air humidity was quite low, and I hope for the best.

My debayered Canon 450D sensor is resealed the same way without any bad effects when cooled.

[wasyoungonce]

Long time no post...so forgive me.

I Have a cam86 PCB ready dark test etc all good. Took some time fixed some vertical noise with was DD11 capacitors again.

Anyway I've identified the issue and tacked on a 200uf 25V cap on DD11 output. No more dark noise.

Anyway I wanted to optically test this PCB. Bearing in mind I have no ability to mount it or fix a lens to it atm. So I was thinking a pin hole camera test...anyone done this? Any tricks?:shrug:

Edit:
Oh meant to say...I had vertical stripes across my darks, removing 2 of DD11 caps doubled the number of these stripes. Placing a 220uf 25V on DD11 out...fixed. I've seen it written vertical stripes on the left are DD11 capacitor issue. Well yes...even vertical stripe noise across the sensor is also an issue with these caps. FWIW.

[Gary47]

Bren,
Do you want me to send your case so you can do tests?
Gary

[wasyoungonce]

Gary many thanks but not yet. I'll try a pinhole camera and Lukas trick with a lens and loop image taking first!

I'm sure its ok atm and I have done images with objects placed on the sensor...yes they work I can see them. But I just wanted to ensure with some methodology before pronouncing it good.

[flolic]

No tricks, pinhole works great for camera testing ;)
Place pinhole 4-5cm from the sensor. You need light-tight enclosure around the sensor, I have used from plastic tube to toilet paper tube :D

[wasyoungonce]

Thanks Flip...I was going to try ~ 10cm...H,, might be too long an FL. I'll try and get back.:thumbsup:

[wasyoungonce]

Ok PCB2 cheap canon 50mm lens, dirty sensor poor light bad focus, light leaks...hey it has all the hallmarks!

Sensor & PCB is a good'un.

[wasyoungonce]

Ok Garys PCB1 is done. Again I had left hand noise bars in the dark frames although this time they were hard to the left not across the image. Again removing C38/C46 and inserting a 220uf electro cap fixed the issue.

I'm going to leave this capacitor in as a fix as this has been successful for me. I think the noise is a combination of issues: the ceramic caps are poor at noise ripple removal; the caps are laid in the wrong place; the filter capacitance is possible low. Its normal to use a combination of ceramic caps and electros for power line filtering and I suspect this is why adding the electro works.

Of note is that many many others with different PCB layouts have had similar issues.

I'm making a "camera obsucera" (pin hole camera) to do a daytime light frame. Busy like a kindergarten kid with toilet roll tubes paper glue/mache etc!:lol: Anyway I've already done light frames so its really just a play time task!

Oh this PCB draw a little more current than PCB2 but not enough to worry no ICs are getting hotter than normal.:shrug: Just monitoring it.

[wasyoungonce]

Ok pin hole camera was a bit of a fail. The image is too out of focused! Probably an issue with the actual pin hole size and sensor distance. The sensor is ~ 11cm from the sensor and the pin hole...just a pin hole!

Yet it was fun building it....for awhile!

Also found it difficult to get correct effective shutter speed with Cam86view. Yes I could have used another imaging program...;)

The Pin hole camera did show a good RGB response and over all it tells me the PCB/Sensor is working like advertised.

Anyway I won't pursue the pinhole much more :sadeyes: as I've already run the PCB optically.

[flolic]

Brendan, you need MUCH smaller pinhole ;)

[wasyoungonce]

Thanks Filip...I was thinking the focus is out because of the hole dia.

I tried a smaller hole....better focus now but image is either too dark or bright. I probably have stray reflections as I used some silver Alloy tape inside to seal it.

I won't pursue this it kinda self defeating. It ran fine with a lens jigged in front of it.

Oh from memory I think I failed Kindergarten ...looks like I haven't improved since!:lol: That's our humble abode in the image.:D

[luka]

Cam86 quantum efficiency... what is it? How to measure it?

On one hand we have D70, D40 or D50 with the same sensor and they have QE of 21% according to sensorgen. But then QHY8 has the same sensor and has QE of 50-60%.

[pat30]

Brendan, good progress :thumbsup:.

Luka,

The Mono sensor has a lot of remanence, and it's very difficult to make flat like that, the option " sensor clr" works well but starts at 1 sec.
Can make sure to put it in forced mode for example with 0 in the box it always empty or when mono and active the "sensor clr" is all time ???

For the QE, it is very difficult to measure, you need a source of light whose exact spectrum and power is known. 21% seems small and 60% big, it seems to me that I had read somewhere 42%

[luka]

Hi Pat,
I will look into the sensor CLR and try it with my mono sensor. I did not use it yet, although I had it debayered for several months... actually today I finally decided to glue the glass window on it.

It may take me a few days, things are quite busy at the moment.

[pat30]

Thank you Luka.

What did you put on the glass?
It takes an antireflective otherwise the stars will be enormous.
I did a test with an antireflective but the quality must be bad because the stars were awful! I will do a test but without glass this time, when it is beautiful weather....

[luka]

Hi Patrice,

remind me in few days if you don't hear from me about the ASCOM driver :-)

I just used the original glass but from a D40 sensor (the D70 sensor glass cracked). I filled a container with argon gas and under argon atmosphere glued the glass with neutral cure silicone. That should keep the space between the sensor and glass dry. I did not test the mono sensor yet, it will be cloudy for the next few days.

Filip, from memory you debayered a 450D before. What glass did you use in front of the sensor?

[pat30]

Hi Luka and everyone,

No problem; it is a good choice argon.

I put 2 comparative images of my test, if you want to see:
1 color version and 1 B / W version with the glass, I would put another without the glass when the clouds are gone.

https://drive.google.com/drive/folders/0B33NUzWf6odbWDJqQ0ZtMDBZZ00?usp=sh aring

[luka]

Got some more info from another person who previously debayered their sensor. He made two excellent points:

1. We could use Astronomik MC-Klarglas (http://www.astronomik.com/en/mc-glass-for-dslr-astromodification.html) as a high quality (and high cost) replacement glass. Multicoated, comes in various square sizes for different Canon DSLRs. I could not find the dimensions on the Astronomik website, it may need cutting to the right size.

2. The effect of glass on the optical path. If a glass is inserted in the optical path the distance to the sensor has to be lengthened.

"Typically this is referred to the Rule of 3rds, where for each 1mm of glass added to a optical path you will need to allow 1/3mm of extra path spacing. This can be critical with CCD and mono cmos cameras. So typically colour or narrowband filters will be say 2mm thick, and sensor windows that cover the sensor chamber are usually 1mm thick, so that is a combined 3mm of glass, therefore using the rule an extra 1mm of spacing is needed to ensure precise backfocus distance is maintained."

This is not a problem for everybody but, for example, if a field flattener is used, usually they require exact spacing to the sensor and extra glass can affect this. My flattener needs spacing to be within 0.5mm. The above example shows that the flattener will not work correctly unless 1mm is added to the optical path.


Also, when I was removing the glass with heat to do the debayering, at some stage it looked like something was "burning" on the glass. Perhaps this was the reflection coating?


I will check my mono camera in 2-3 days, once the clouds go away.

[gehelem]

Hi

Luka, i've noticed a little thing on the driver :
when your cooling is already on, and you've already reached some low temperature, if you set another (lower) temperature, cooling is restarting at "Startpower", not taking care of what your actual power is.
This is not a big deal, just a little annoying when playing with cooler...
I'll try to workaround on my linux driver, but i think i'd be better to do that at firmware level.

Gilles.

[glend]

Luka the burning you notice during removal of the cover glass is likely the epoxy glue used to seal the coverglass to the sensor body. Typically it starts to turn white in the area where heat is applied which indicates it has broken its bond. The application of heat to that glass, to break the glass loose, is a risky step but there is no other way to do it that i am aware of. A hot air workstation is sometimes sighted as the 'safe' way to do this, but many of us use small butane torches that can supply a pencil type flame. As some of the online videos show, its how you apply the heat that is critical; movement of the torch in 'passes' to get the initial white edge under the glass is important to avoid hot spotting that can damage the sensor fine wires which are soldered in place. Also the glass can break through uneven heat application to cold glass, so don't try to get under the glass with a tool or blade to lever it off. A cracked cover glass is much more problematic to remove without damaging the sensor surface or the wires. It only takes a small chip falling into the sensor surface area to cause damage.

[luka]

Glen, I don't think it was epoxy. It looked like a small amount of black-ish smoke came off from the glass itself. I remember repeating the heating on a different side and again the smoke came off in a similar fashion. After those initial "smokes", there was nothing further. I could be wrong and I may have not seen it correctly but I remember it being unusual.
Also I noticed this only on one of the sensors I did an not on the other one. Don't know. I could be very wrong about this.


Gilles, I will see what I can do. I have been working on a new driver version, with some minor bug fixes, but I stuffed up something and it does not work any more. Can't figure out what. Will need to go a version back and do all the changes one by one. Not much time at the moment unfortunately.

[luka]

Patrice, a question regarding the mono sensor and sensor clearing before exposure... I can set the sensorCLR to zero here. Then if the duration of the flats is greater than zero (0.01s for example) it will clear the sensor before exposure. Are you using APT?

Can you describe which options you were using?

[luka]

Gilles, do you stop the cooler to change the target temperature or do you just set the new target temperature while the cooler is running? The starting power percentage is set only when the cooler is switched on.

[luka]

New driver in the usual place, v0.7.1L.
Only minor bug fixes.

[luka]

Tested the mono camera with the original glass. Patrice, just as you said the star bloating is visible.

My cameras are not finished yet but I will use the Astronomik MC-clear glass at the front of the mono camera to seal it. MC-clear has excellent anti-reflection coatings. So, I will leave the sensor without a cover glass and try this first. It may be few more weeks before everything is ready though.

One issue I can foresee is that my colour camera will have 1mm thick glass in front of the sensor while my mono camera won't have it. So, the colour camera will have about 1/3 mm longer optical path to the sensor. This is very close to the tolerance of my flattener which is +/- 0.5mm.
Possible solutions are to remove the cover glass from the colour camera or to use anti-reflective MC-clear glass at the front of the sensor. Hmmm... will probably need to test it before making any decisions.

[rsevs3]

I just wanted to share the first image from my camera.

Still a few issues to sort out as well as a case, but some progress is better than none.

[luka]

LOVE the image Ryan.

You should do a 0ms exposure dark photo. That will give you a good indications about the noise and if everything is working fine. The StdDev line should be around 14 +-2... ish. Some minor vertical lines are fine as well.

[gehelem]

Rhahaha !!!
Congratulations from France
How many are you to build this cam here downunders ??
Gilles

[pat30]

I am ashamed of myself, I have not tried with 0sec :confused2:

Yes I use APT, what option? Cooling?

Cooling min 80% max 100%
AID cooling pause of 5 sec per 7 ° C

Exposure flat of 0.034 sec (19800 ADU) with DIY flat box.
MONO checked in Ascom

other:
PHD2 for guidance with APT dithering; CDC (french software) for skymap.

If you want to know something else, tell me what.

Rsevs3, like Gilles, congratulations from France :thumbsup:

It's good, you're not against the French at least here because we include everywhere :D

[wasyoungonce]

Excellent Ryan...how are the darks?

Brendan

[luka]

Gilles and Patrice, I have uploaded a new firmware to the usual place, v0.7L.

I still don't have a working camera but the ASCOM similator showed that APT sends coolingOn command to the camera whenever the temperature is changed, even if the cooling was already on.

So, I have modified the firmware to check if the cooling is already on after it receives coolingOn command. If it is already on, it will just leave it on. If it was off then the starting power will be used in the formula calculating the cooling power.

Can you please test and let me know.

[luka]

New driver is out, in the usual place. Version 0.7.2L. Screenshots attached.


Changes:
- Fix bug where maxGain was reported as 64 instead of 63
- Modify the layout of the settings form
- Add a button to minimise the settings form
- Add a button to toggle between image info only or settings as well when camera is connected

The biggest visual change is that I have modified the window layout to look more like EQASCOM. You can minimise the window now as well.

The firmware stays the same, v.0.6L.
(there is a testing firmware version v0.7L in the same folder, ignore for now unless you have cooling issues).


Enjoy :D

[gehelem]

Thank you Luka, i've seen that on french forum (wich is down at the moment).
I've troubles with my cam at the moment : it's really hot here in France, and i think my cam didn't like staying all day under the sun.
I'm really disapointed with that, i think i'm gonna take a little break : i'm starting too many projects at same time, can't finish any...
I'll "try to try" your driver this weekend, but it might not be very usefull as my cam gives very strange results

Gilles.

[luka]

Gilles, hope you left the camera covered while in the sun. The metal housing can get quite hot and the internal parts even hotter.

If you get time on the weekend, can you test the new firmware, 0.7. In particular I would like to know if we have fixed the issue that you and Patrice had with cooling.
The changes in the driver were mainly cosmetic, and really do not require any serious testing. I did not touch any of the main functions.

Some bad news here as well.
I killed my mono sensor :sad:
I was trying to take off the glass that I glued over it as it was giving reflections and the blade slipped and cut one of the gold wires. Only one so I will try repairing it tomorrow but you know how tiny those things are. I don't think I stand a chance but desperate times call for desperate measures :sadeyes:

[gehelem]

I think it's KO
screenshot here
http://www.webastro.net/forum/showthread.php?p=2424492&posted=1#post2424492
my firmware version claims to be FW=7 instead of your screenshot (FW=6...)

[luka]

New firmware update, version 8 in the usual place. Fixed the bug with the cooling restarting at 60% when the temperature is changed while the cooler is running.

Please note that I have changed the revision numbering for the firmware from "0.8" to "8" as this is what is actually recorded in the firmware (one byte) and reported in the ASCOM driver.

Enjoy.

[pat30]

Luka, the firmware it's perfect that way.

I have done some research for AD811 and I have retained some references:

THS4031
LMH6629
ADA4895
LT1115
AD797

If someone has more knowledge than me to verify :help:

[Lognic04]

Hi all, :hi:
Just letting you know i will be starting this project! i have already been in contact with luka, so at this stage i still dont have any of the parts i need (yet!)
:D

[luka]

:welcome: to the group. Make sure you do lots of reading before starting and feel free to ask questions.

[pat30]

Hi Lognic04, welcome in the adventure :thumbsup:

[Lognic04]

Hi all!
I have found that the following parts are discontinued at RS:
721-5666
811-8796
696-3092
888-8704
Any idea where i could find these?
Thanks!

[luka]

You can get the manufacturer part numbers from my BOM and then look at element14. For example
721-5666 (RS) -> ERJ6BQF3R0V -> 1892948RL (E14)

Even more interestingly, you can search the RS part numbers directly on the E14 website, i.e. you can skip the middle step.

Note that E14 charges for delivery if under $45 or so. RS has free delivery, even for a 1c part. Also for some parts there is a significant difference in pricing between the two shops. My spreadsheet may not be up-to-date.

Make sure you order the slow parts from overseas first (sensor sockets and TEC if you decide to use the same one as we did), otherwise you will be stuck waiting for them for weeks while the camera is almost ready.

[pat30]

Hi everybody,
I do not know if you followed my last post on Webastro, I measured the noise of the board, a diagonal parasite is out, I would like to see if it is in everyone so if one of you Can do the test it would be nice.

To do this you must not have any accessories running (tec, fan, nothing, just the board) remove the sensor, set the pin 19 to ground with setting offset 0 and gain 0 make a picture as fast as possible.

Here is what it looks like:

https://drive.google.com/file/d/0B33NUzWf6odbVF9XSzc1Yld4SlU/view?usp=sharing

[luka]

Grim may have a better idea than us. Any chance your grounding wire could be picking up the 50Hz mains frequency?

(Cannot test my camera now, no power and no USB cables).

[wasyoungonce]

Hi Logan...just sent you a pm. On parts...we can give you access to our cam86 google drive to see files or I can send you my latest in xls format.

Oh sorry for my late pm reply...I was waylaid by a beautiful girl...my wife!;)

Brendan

[wasyoungonce]

Just about to ship 1st PCB to Gary. Its in case and runs fine. He's sending me a sensor, I'll mount it and fit the temp sensor DS18B20 and its nearly done.

R&R sensors is a real pain. Very easy to bend the sensor pins, so I left my sensors in his PCBs till they were done.

Luka is proposing a small breakout rear case for pwr/USB. This will simplify some connections. Oh I'll conformal coat the PCB to protect it from moisture. Just the cheap Jaycar stuff.


Brendan

[gehelem]

Just to share this interesting setup on cam84 with external silica bottles
I like this
https://www.cloudynights.com/topic/497530-diy-astro-ccd-16-bit-color-6mpx-camera/page-46

[wasyoungonce]

Ok had some issues with horizontal random noise in images. Turns out it was data transfer errors (read noise). Luka explained this (many thanks) and indeed had a "read time" delay in their ASCOM drivers that delayed the row readout each row. Increasing this fixed the issue.

Having issue getting what looks to be correct debayer from APT fit files in DSS. Kinda red looks green...I may be doing it wrong. Wanted to ask...is the matrix RGGB or GRGB? What camera should I use to debayer in DSS....Nikon D70?

Damn...how does bulletin board code work...grrr...

Anyway I figured it out (http://www.iceinspace.com.au/forum/showpost.php?p=1297177&postcount=611)...wrong debayer used Crisis over..use DSS mono camera selected generic camera GRBG...

edit:
You'll need the appropriate cam86 ASCOM driver (mine is 0.7.2L) to do this delay as well as newer firmware (mine at v8L). Many thanks Luka.

[luka]

Interesting note from Faddy on the Ukrainian forums:



If true that would be good news.

[gehelem]

hi

we are a few in France to start new boards (and i want a second one, cleaner...)
I'm about to order new pcb, and i'm thinking to use yours.
Can you tell me which specific parts you've improved ?
Where can i find the last "production" one ? (and now i'm here : have you a BOM ?)

thank you
Gilles.

[luka]

Hi Gilles,

The latest version is in folder "Cam86 ver 2, 18 Dec final corrections". There is also a version by Filip called Cam86_final_filip.
Take a pick...

You will need to wait for Brendan to confirm all the changes. From memory:
- the FET controlling the TEC has been upgraded as it was way too weak in the original version.
- added 3 capacitors to stabilise the input of DD6, however, this was a mistake and they are too far from DD6. They will need to be moved close to DD6, actually they should be directly next to DD6.
- improved the power connector. The original was rated only 2A while more current can be used by the camera, depending on the TEC. We doubled-up the wires to double the maximum current as we could not find a connector with larger rating but with a small size.

Since building the boards, there were few more things I wish we had changed:
- the holes for the TEC wiring are too small
- need to look into and possibly add +ve and GND holes for connecting the sensors. If there is enough place then probably even add the connectors for the sensors.
- possibly a larger hole for the cold finger

I don't think we changed the 3.3V regulator, we decided to go with 9V for the camera power instead. I don't think that the original design of going 12V to 3.3V is a good idea as there will always be lots of heat generation but using DC-DC converters would probably cause noise.

[gehelem]

Thank you Luka
I will check all that
I would really like to have :
- connectors for tec & sensors
- bigger hole for cold finger
Don't know how to do that with Eagle, but i'll give a try.
Gilles

[luka]

Unfortunately I can't be of much assistance, never used Eagle myself. Brendan did all the design files.

I forgot the most important change, we wanted to put Brendan's avatar as logo on the board :lol:

[flolic]

Gilles, I have 8 or 9 spare PCB-s (my design). If you want them, I can send it to you for free (just pay for shipping cost).

[wasyoungonce]

Hi Gents...back from C6/7 spinal fusion surgery, a few days ago.

I cannot do a lot atm "mucho sore"...but I can do some. I hope to much better in a few weeks.

If you want some PCB changes...then list them and I'll do them. Luka I will try incorporate changes/deficiencies we noted in my original board. I do have a list but we need to consolidate them.

Or if you want I can send you the Eagle PCB files and you can make the changes. As long as you allow us to copy these for our use.

Brendan

[gehelem]

Thank you Filip
As long as we are a few in France, i think it's better to order from here...
Keep yours for friends next to you
Thanks again
Gilles.

[gehelem]

Ouch, take care !
Be carefull : if you see more stars at night, it might come from surgery...

About pcb mod : this is very kind also, i don't know if this is difficult or not...
For me the number one is a bigger hole, adjusted to copper sensor back.
Connectors for everything : DS18B20 / DHT22 / TEC / USB / Power
Luka's suggestion are also very good points...
How can i help ?
(this is a september play, i have time, take care of you)

Gilles.

[N_DD]

Hi,

I was trying to use Kstars and EKOS with Cam86 under windows, but when configuring the latest ASCOM drive (0.7.2L) under wINDI I got an error message (see below). Also the original v0.1 driver gives the same error message. I have tried both the 32-bit and the 64-bit wINDI versions, but still no joy.
Has anybody played around with Kstrs and EKOS under windows? It is really cool, although lacking an offline plate solver for now...

Nico

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.BadImageFormatException: 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).
at System.RuntimeTypeHandle.CreateInst ance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSl ow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Typ e type, Boolean nonPublic)
at System.Activator.CreateInstance(Typ e type)
at ASCOM.DriverAccess.MemberFactory..c tor(String progId, TraceLogger ascomDriverTraceLogger) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Mem berFactory.cs:line 55
at ASCOM.DriverAccess.AscomDriver..cto r(String deviceProgId) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Asc omDriver.cs:line 49
at ASCOM.DriverAccess.Camera..ctor(Str ing cameraId) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Cam era.cs:line 33
at INDI.TcpServer.InstantiateDriver(St ring driverID)
at INDI.ControlPanel.setupClick(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClic k(EventArgs e)
at System.Windows.Forms.Button.OnClick (EventArgs e)
at System.Windows.Forms.Button.OnMouse Up(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMous eUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndPro c(Message& m)
at System.Windows.Forms.ButtonBase.Wnd Proc(Message& m)
at System.Windows.Forms.Button.WndProc (Message& m)
at System.Windows.Forms.NativeWindow.C allback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
INDI Server
Assembly Version: 2.2.6.0
Win32 Version: 2.2.6.0
CodeBase: file:///C:/Program%20Files/INDI/INDI%20Server.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
INDI
Assembly Version: 2.2.6.0
Win32 Version: 2.2.6.0
CodeBase: file:///C:/Program%20Files/INDI/INDI.DLL
----------------------------------------
ASCOM.Utilities
Assembly Version: 6.0.0.0
Win32 Version: 6.3.0.2831
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/ASCOM.Utilities/6.0.0.0__565de7938946fba7/ASCOM.Utilities.dll
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
Win32 Version: 14.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1099.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
ASCOM.DriverAccess
Assembly Version: 6.0.0.0
Win32 Version: 6.3.0.2831
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/ASCOM.DriverAccess/6.0.0.0__565de7938946fba7/ASCOM.DriverAccess.dll
----------------------------------------
ASCOM.DeviceInterfaces
Assembly Version: 6.0.0.0
Win32 Version: 6.3.0.2831
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/ASCOM.DeviceInterfaces/6.0.0.0__565de7938946fba7/ASCOM.DeviceInterfaces.dll
----------------------------------------
ASCOM.Exceptions
Assembly Version: 6.0.0.0
Win32 Version: 6.3.0.2831
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/ASCOM.Exceptions/6.0.0.0__565de7938946fba7/ASCOM.Exceptions.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[luka]

Sorry Nico, never tried wINDI. I know that Gilles is using INDI on linux with a special Cam86 INDI driver. Would that work?

Also the new update is out in the usual spot or here (https://drive.google.com/open?id=0B17xefQsw2ktNVV3TkpMX3FPOX M). Driver version 0.7.3L and firmware 9L.

Changes:
- Bug fix - white line in the first row when the cooling is used

Firmware change:
- Extra error checking. It probably does not make any difference but I thought some sanity checking of the values would not hurt.

As always test with care. And enjoy :D

[wasyoungonce]

Hi Luka/Gary

I'm ok enough now to get back into this (pardon the pun)!

Brendan

[N_DD]

Brendan, nice to hear that! :)

I had some success connecting my cam86 to Ekos through wINDI by running kstars as administrator: the program look nice, but it's still lacking offline plate solving under windows. Once this is fixed, I might give it a try "for real"! I'll keep you updated.

Nico

[wasyoungonce]

Thanks Niko

You have done some excellent work with ekos indi cross platform Kinda what ASCOM needed but never happened. Its funny you know its things like what you are doing that forces changes in mfgrs.

They all appear fixated but unwilling to commit because rate of change is enormous. But they forget backing things like indi forces change itself and eventuates in other mfgrs jumping on board. Maybe they are just lazy in support?

Anyway I'm swinging a soldering iron in anger (a little at a time) at last, new Kester solder just waiting for new Kester flux. I did manage to fix the pool controller ...again and printer as well as do some Gemini PLD firmware. A little bit at a time.

regards

Brendan

[N_DD]

Hi!

after some fiddling with ansvr.exe, I finally managed to fix the plate solving issue. Now I just miss my guide camera, then I should be ready for some real test under the stars (...weather allowing, of course...)

[luka]

Guys, Grim posted lots of updates about design improvements to all Cams. You should read it yourself here (https://translate.googleusercontent.com/translate_c?depth=2&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=http://www.astroclub.kiev.ua/forum/index.php%3FPHPSESSID%3Dovbvtf7g0t0 s4e9l5krn05brg0%26topic%3D28929.298 0&usg=ALkJrhjuMUNBYEkgsN81D8brkn0gCRG HTQ) (start with post 2995) but the main points are here:

[luka]

And this is also interesting:

[pat30]

hello friend of the South,

I have seen everything, I do not understand correctly item 3.

For motivate a little the troops :):

http://www.webastro.net/upload/images/8654-1511550323.jpg

[luka]

Hi Patrice,

I am not 100% sure but the way I understand the point 3, Rim is saying that the one side of diode VD4 should be GND instead of +5V. This should be done relatively easily by cutting the +5V track on the PCB and then grounding the diode VD4.

Also +15V supply to the sensor is needed only for the frame reading and can be GND during exposures. This will reduce heat and noise. However, for short exposures +15V must be left on.

Rim mentioned that a firmware change can do this. Someone will need to confirm but I think pin F7 on ATMega controls the voltage. So, changing the voltage on F7 in firmware could do the job :shrug:

Beware that this is my interpretation of the google translation. It does not mean it is what Rim said. I just don't want anyone blowing up their camera because of what I said is not correct :lol:


Very nice image :thumbsup:

[luka]

More about each point:

This improvement would require a separate PCB with 3.3V power supply. But I never saw those diagonal stripes in my 2 cameras so probably it is not worth doing unless you are having problems.


Requires new PCB design.


Can probably be done relatively easily. As I said before cut +5V trace and GND the diode. For +15V a firmware will need to be modified.


This would require a new small PCB with optoisolator and FET. But if FET is kept off or on during the frame read (as it is now) then there is no problem.


Don't have one, can't really comment


Requires a new PCB.


Something to think about. But our plan was to include the desiccant tablets inside the housing which would suck up the moisture anyway.


Makes any repairs very difficult.

[luka]

Confused about the point 3, our firmware/driver already switches off the +15V for >1s exposures. Perhaps Rim only suggested changing +5V to GND on the diode :shrug:

The mysteries of the google translation :lol:

[pat30]

The Russian translation is complicated, it is better to wait for the schema!:)

[luka]

Not sure if the updated files are coming soon/ever. I posted a question on the Ukrainian forums.

[pat30]

There is change, now point 3 invalid, don't touch.

[luka]

Interesting, the change works only for Cam90 but not for Cam86. They do have different sensors which probably explains why.

[luka]

I keep forgetting, the source code is out on the github for all to see/modify/use. No new updates.
Links:
ASCOM driver (https://github.com/axsdenied/cam86_ASCOM)
DLL (https://github.com/axsdenied/cam86_dll)
Firmware (https://github.com/axsdenied/cam86_fw)

[pat30]

Thank you Luka :thumbsup:, even if for me it's Chinese.
I'll have to learn coding one day ...

[luka]

About a year overdue but better late then never :rofl:

[luka]

Hi everybody,

I would like to introduce Oscar, a new member of our software development team :bashcomp:

Oscar's contribution to our ASCOM driver started with a real bang, he developed a full PID solution for the camera temperature control, of course, all in the spirit of open source.

So, in the name of all of Cam86 users I would like to say :welcome: and :thanx: to Oscar.

The new drivers/firmware are on our github page (https://github.com/axsdenied/cam86_ASCOM), see the links in the top of the README section. As always, use at your own risk and report back with any bugs and suggestions. You will need to tweak the PID parameters for your system but the default values seem to represent a good starting point.


Finally as a little New Year's sweetener I did few little interface tweaks and bug fixes. The temperature info now shows the set temperature as well. Also it is possible to to double-click on it to set the temperature independently of the imaging software. Note that this manual temperature settings may be overridden by the imaging software.

Luka

[luka]

New version 0.7.8 of the ASCOM driver is on our github (https://github.com/axsdenied/cam86_ASCOM).

Please update as soon as possible.

Changes:
- Fixed a bug where manually set temperature was resetting itself.
- Manually setting temperature requires double-click now (as originally intended).
- Minor interface tweaks

Thanks to Oscar for noticing the temperature bug.

As always, use with care and please report any bugs and suggestions.
Luka

[Astrococo]

Hi guys! Thank you for your wellcome. I hope to keep contributing to this great project.
Rough-tuning the PID controller is quite easy. First, increase the value of Kp (in steps of 5 units) until setpoint is overshooted. Then, come back to the previous value. Now we must have a stable control, but setpoint is not reached. Then increase the Ki value in steps of 0,05 until setpoint is reached. By now, I don't see as neccesary to use the derivative term.

I think that you can safely use a value of 40 to start tuning the Kp. When Kp is tuned, a starting 0,2 value for Ki can be used. Of course, these values can be too much for your camera, use with caution and at your own risk ;-)

Oscar

[gehelem]

Thank you Oscar

May i suggest to have a look at my little Excel game :
https://www.diycam.fr/index.php/fr/10-all/software/24-cam86-tests-de-temperature-avec-excel
(use the english flag top right to translate)
It should be adapted with new driver, but it's a very simple way to batch a few tests

I'll get back to that once i'll have finished my second cam :)

Gilles.

[pat30]

There was a reboot site ??? my message from yesterday is no longer there :shrug:

It said thank you and welcome to Oscar in the adventure :welcome:.

[luka]

There was a hard drive failure in the server. Most likely some posts just before the failure were lost.

[Astrococo]

Hi Gilles and Patrice, and thank you for your welcome. I have modified the MSExcel sheet to include the new function calls, but in spite of copying it into the same directory, I receive an error telling that cam86ll.dll can't be found. If you can have a look to the xls file, you can download from here: TempTestVBA-11.xlsm (https://www.dropbox.com/s/n52ea49kh5bn5ci/TempTestVBA-11.xlsm?dl=1) :thanx: (https://www.dropbox.com/s/n52ea49kh5bn5ci/TempTestVBA-11.xlsm?dl=0)

[pat30]

Happy New Year my friends, that 2018 gives you a clear enough weather to make beautiful pictures with the Cam86 :)

[luka]

Hi everybody,

Things have been quiet for a while but the development has been ticking in the background. I have been trying to make the camera switch the TEC on/off during the frame reading instead of just having it on or off.

I have tried a few different approaches. It is doable but... and there is a but, it will cause noise in the images, at least with my camera. The attached image was taken with a testing firmware which switches the cooler on/off 4 times during the frame read (in between the row changes). Unfortunately 4 horizontal stripes are visible, roughly every 1/4 of the image.

The attached image has been stretched to show the stripes better. The camera was not cooled for this test, I would expect the cooled sensor to show the stripes better as the background noise will be less.

I have attached the testing firmware that I used. Can someone else flash it and do the test. I would like to see if the stripes are there visible with different designs of the power circuitry for the TEC. I am thinking of adding an inductor to smooth out the large current spikes by the TEC??? Not sure.
(you will need to flash the original firmware to restore the camera back to normal function)

Any other ideas?

Luka

[glend]

Luka, the work that Rowland and i did on cold finger cooled Canon TEC power regulation dealt with similiar noise, which was traced to poor common earthing of the cold finger to the chassis and the regulation circuit. Nothing should be allowed to 'float'.

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

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 :lol:

[luka]

The new driver is out. Download from the usual spot (https://github.com/axsdenied/cam86_ASCOM).

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 (https://github.com/axsdenied/cam86_ASCOM).

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 (https://github.com/axsdenied/cam86_ASCOM).

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:

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.
:question:

[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 (https://ascom-standards.org) and for a possible solution here (http://forums.dc3.com/showthread.php?11182-ALERT-Windows-10-Update-KB4056892-Reported-Problems&p=67734#post67734). Also a nice discussion here (https://www.cloudynights.com/topic/604521-explaining-why-win-10-security-update-kb4056892-breaks-ascom-drivers/)
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... :confuse3::bashcomp:

[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 :mad2:
(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 (https://ascom-standards.org/Developer/DevFor32And64Bits.htm), 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 :shrug:

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!!! :thumbsup: Great job!

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

Thanks a lot,

Nico

[luka]

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 :lol:

[redriver]

If the horizontal stripes are caused by PWM of contolling TEC, then is it possible to use a separate 12V power supply? Or use isolated DC-DC to power the TEC and then a opticalcoupler to control the TEC? My CAM86 is under construction, TEC part is still not finished, I use a 40mm*40mm TEC1-12706 and it can only reach -12.8 with a huge powerful GPU cooler. I am considering with two stage TEC...

[luka]

It is definitely caused by the power supply and some sort of capacitive coupling. I have not posted the results yet but I am on the verge of solving the issue, at least with my camera.

1. I swapped the humidity and TEC control pins by some soldering on the board.
The humidity pin can use hardware PWM but the original TEC pin cannot. This will allow us to do faster TEC switching.
2. At 8KHz switching frequency I could not notice any "noise". The frequency is higher than the line reading frequency.
3. Another improvement has been achieved by using electrically conductive thermal paste between the cold finger and the back of the sensor. This puts the cold finger at the same potential as the back of the sensor and it helps a lot.
DO NOT GROUND THE COLD FINGER.

I am still doing tests but it looks like this has solved the problem for me. Few other people will be doing tests soon and I will post the results then.

If needed further options would be to connect ground directly from the power connector to the VT1 MOSFET. Possibly even move the VT1 from the main PCB. Optoisolator would probably help as well.

Do not use a single stage TEC, you won't get very high temperature differential. Quite a few of us used TEC2-19003 from ebay and it is possible to get 40 degrees C temperature difference.

[redriver]

Hi Luka,

I will practice to use a optoisolator and a separate power for peltier. And I have a issue of peltier placement, does the peltier reside inside the case or outside the case? If the peltier is outside the case, then the cooling if much better, as it has larger heat dissipation area, but the cold finger copper is more long, which brings bad for colding.

Thanks!

[luka]

Optoisolator should help as it will keep the board power and the TEC power completely separate. It will complicate the electronics though, if you are using the original G106 housing things may not fit inside any more. By the way, there is a deeper version of G106 by Hammond, part number 1550Z111.

Keep in mind that we will most likely have to use the humidity pin for the TEC as the current TEC pin does not support PWM. Still doing tests here so don't do any changes yet.

While you are at the design stage here is another thought. The 3.3V regulator gets quite hot as it powered by the input voltage (12V). The camera actually only needs about 6.5V (say 7V to be safe) to run. If you are using separate power supplies for the TEC and the camera electronics you can power the camera with a lower voltage to reduce the heat production.
In my current design I use one 12V power supply but the camera electronics is powered by an external 8V regulator while the TEC gets the full 12V. This way some of the heat is "moved" from the PCB to the breakout box outside the main case.

Regarding the TEC designs, both are possible but I am not sure about the 2nd drawing where only a part of the hot side of the TEC is being cooled. If possible you should shape the cold finger to look something like a letter T in side view. The top of T should be square and fully cover the TEC while the bottom "leg" of T should be round and go to the cold finger through a hole in the PCB. Hope this description makes sense, if not I can do a drawing.

My current design is like your first drawing and I can get down to -40 degrees C below the ambient temperature with the TEC I mentioned before. The final temperature, of course, also depends on the size of the heatsink and the fan.

[redriver]

Thanks for your support:)

For the hot regulator problem, right I now I am using a 9V DC supply to power the board. VT1 is not soldered yet as I have not using that to power the TEC. I am in early stage, TEC is testing with a stand alone DC power.

I have understand your description of the "T" colder finger. I have also see some similar designs from CN forum, see below pictures. I will use design 1 to make the TEC outside of the case and also a "T cold finger:)

[luka]

Killed my camera.
The ground leg of the temperature sensor broke off when I was assembling the camera and shorted something inside when I connected it to power.
:sad:

[redriver]

...
Is the 5V, 3.3V, 15, -8V and 6V are shortened to GND? I think you should check these power supply to GND resistance without power. One of my friends killed his CAM86 as the VT1(AO3400 or AO3401 I can't remember) is shortened with TEC current >3.5A, FT2232 is damaged (no any device when connected to PC), maybe also Mega328P, no idea whether CCD is killed or not.

[luka]

3.3V is grounded. The other voltages seem OK.

I already tested the regulator and DD2 EEPROM (by cutting tracks on the PCB) and they are fine. I also left the camera plugged in hoping that something will get hot... no luck, only the 3.3V regulator got hot. I have to stop now as I need to get a new regulator tomorrow, I totally butchered this one.

Knowing my luck it will be the FTDI chip, swapping an LQFP64 part will be "interesting".

By the way, I took apart the camera LOTS AND LOTS of times (>50) as I was experimenting with different methods of cooling. Every time the temperature sensor legs were bent and then bent back, no wonder one of them snapped.

[luka]

Removed the FTDI chip with the help of my good old friend, ChipQuik.
No short any more. The replacement chip is coming on Monday.

[redriver]

It seems FTD2232 is weak... Hope all other chips are OK.
Remove LQFP is easy if you have a heat gun:)
By the way, how do you remove the CCD from D70 board? with heat gun or electric iron&desoldering pump？ From ICX413 datasheet the soldering temperature should not exceeds 80 degree, we use electric iron&desoldering to remove it from D70 board, and then someone uses heat gun to isolate the CCD from the aluminum board （heat the back of aluminum with about 350 degree and then the glue melts）

[luka]

Nothing else seems shorting to ground. But we will see tomorrow after I swap the FTDI chip.
(I used ChipQuik to remove the FTDI chip instead of a heatgun. Quick and easy.)

Removal of the CCD... two steps (I can't remember in which order).

1. The sensor is glued (epoxied) to the metal carrier so you need to "melt" the epoxy. The usual procedure is to use an DMSO bath for a few days. It will completely melt the epoxy and the sensor will simply come off. It won't damage the sensor. Make sure you bathe the sensor long enough so that no epoxy is left on its back or it can affect the cooling performance later on.
Make sure you read the safety precautions for DMSO.
The usual supplier is ebay or chemists.

2. For desoldering of the sensor Brendan used the desoldering pump (watch for static electricity) on 4 sensors and I used ChipQuik on 3 sensors. They all survived. The recommendation is to keep the sensor as cool as possible so try to be as quick as possible.

Unlike D70, the D40 has a flexible PCB and that one can be removed quite easily, pin-by-pin.

[luka]

Good news, I swapped the FTDI chip and the camera is alive again.

[N_DD]

Luka, happy for you!!! :thumbsup:
FTDI chips are my nightmare: I don't remember how many of them I have burned befire learning how to handle them properly... :D

[luka]

It is a great feeling to have it working again... of course we have clouds and rain now.

Just a quick update about the hardware PWM I have been working on. On one of my cameras it is working perfectly but the other camera it still has some artifacts in the bias images, see the attached image. I have added the black line to show the direction of the artifacts.

My next step will be to take the MOSFET off the PCB and ground it directly from the power plug.

But the cooling works brilliantly with the hardware PWM!!!

[redriver]

Hi Luka,
Happy to know your camera is alive:)
Here I have a note that someone in our DIY group said that disassembling the CCD out of its aluminum back with heat gun causes CCD performance degradation, the noise increase. Currently it is better to use chemical method. Also some guy are trying to remove the bayer filter.

[luka]

The chemical method (DMSO) works very well, it just requires patience (a day or two).

Regarding removal of the Bayer filter, few of us have done it. See here (http://www.iceinspace.com.au/forum/showthread.php?t=152057) or here (https://www.diycam.fr/index.php/fr/9-all/construction/25-supprimer-la-matrice-de-bayer) for descriptions.

[pat30]

Hello my friends,
a quick word to tell you that even if I'm not very talkative for some time, I read your messages.
I have a lot of work now so very busy:(.

Redriver, the few tests that were made with a black and white sensor are not great, the only advantage is to use filters like to make the false color ex SHO, if not as much keep it original unless you do 2 camera.

[wasyoungonce]

Oh jeez it’s been ages since I’ve posted or. Done anything I’m so sorry. Been in for 3rd spinal fusion ( 2nd lumber) and at rehab atm . I also fell over the wife’s new blanket box at the end of the bed fractured C5 and prolapsed C5 disc ( all in between surgeries). Had no ide I did damage which of course got worst neck pain hand tingling numb loss of strength

So it’s been a hell ride and more to come. Last lumber fixed my lower issues really well the I dun buggered my neck! Sheee’s talk about bad luck.

Anyway atm things are looking up lower back is great I’ll be home soon then we’ll decide what to do with the neck if anything. Me thinks they have to way too much pain etc.

Anyway some day I hope to return to my bench and resume work on all this ... but it’ll take me ages just to catch up! Oh forgive typos using iPhone at midnight!

Brendan

[luka]

Brendan, welcome back. It is great to hear from you again, we have been worried. At least your lower back has been fixed, your luck finally may be changing. Best wishes for the neck.


I have been testing a new idea for the PWM cooling that should solve the "stripes" issue. A thermally conductive (but not electrically conductive) thin film between the cold finger and the back of the sensor with Arctic Silver 5 on both sides for improved thermal contact. The electrical separation allowed me to ground the cold finger without grounding the back of the sensor and this removed the stripes completely.

I have been testing this solution by imaging over multiple nights and it seems to work well. The sensor temperature is rock-stable.

I still have to quantify the loss in the thermal transfer due to the film before making final conclusions but I don't think it will be very large... hopefully.

[wasyoungonce]

Stupid question Luka.. did someone try straight DC source (non PWM) to act as cooling supply...ads did the “stripes go away”?

Just guessing if PWM is inducing noise then constant cooling current voltage may fix it.

Really shooting st hip I’ll have to read all posts and get s handle first. Hopefully I’ll be home mid week and be able to devote time and effort.
Brendan...urge sleep time it’s 1am I’m still in hospital!

[luka]

No, we did not try the DC current to TEC. That would most likely work but we would have to control the DC current from the ATMega somehow. PWM was relatively easy and required no extra parts (I had to modify the board and swap pins as our current TEC pin does not support PWM).

Another option would be to smooth the PWM-ed MOSFET output and convert it to DC. Again extra parts and extra heat losses.

You should have some rest. Again, great to hear from you!!!

[wasyoungonce]

My first impression is induced noise from PWM. Yes I’ve see lots of efforts from other uses I think Garymack with smoothing.

Linear current control of a TECH is best done by bipolar transistor but I can run manual control via CC and CV modes using a PSU.

Might be a quick easy way to isolate. What you want is to half you problem doing this does that. The noise lines disappear or not.

I kinda get the impression you already know it’s the PWM ... can you alter TEC frequency ( via at mega code firmware change). is there a change?

Jeez this is interesting getting my juices flowing but still stuck in hospital atm. Due out soon but that might not pan ou let’s see I’m going to go read all the threads and try to get a handle. Can you point me to images of the issues with a link? Just makes it easy for me. Also I’m on mind bending drugs I spend a lot of time quite “foggy” which make it hard for me to comprehend. Forgive the typos again I’m using phone. I have my kappa and wifi modem so I have some luxuries :D

[gehelem]

Nice to see you back Brendan, take care
Gilles.

[wasyoungonce]

Gilles many thanks its been a tough ride! All I wanted was to get back to being half normal and play at the things I like ..like this projects!

[luka]

Brendan, here is a short summary of what is going on:
- The stripes are caused by PWM. The frequency of the stripes changes as the PWM changes. We went as high as 16KHz for the TEC switching frequency but short horizontal lines still formed a visible pattern in the images.
- The stripes are also caused by the cold finger left floating. Previous work with Canon 450D showed that the stripes go away once the cold finger is grounded.
- The back of our sensor is metal. However, unlike 450D and it cannot be grounded or the camera stops working.

So, there are two possible solutions:
1. Electrically connect the cold finger to the sensor.
2. Electrically insulate the cold finger from the sensor and then ground it.

For the option 1 we could not find any thermal paste that is electrically conductive. Most of them are designed for cooling CPUs and have good thermal conductivity but zero electrical conductivity.
Eventually Cedric (from the French forums) thought of using solder paste and it worked. Moreover, the camera read noise went down by about 15% as well.
However, I am not sure about the long term suitability of the solder paste.

Option 2 - I found a very thin (0.1mm thick) thermally conductive film that is also electrical insulator. I used it between the cold finger and the sensor, while also applying some Arctic Silver 5 (AS5) thermal paste on both sides. The thermal films and pads are usually used when the parts are pressed together by a large pressure and we don't have that - hence the use of AS5.
Then I could ground the cold finger without worrying that it may short the back of the sensor.
The preliminary results showed that this worked really well. I could not see the stripes at any switching frequency.
However, there will be a thermal loss because an extra interface between the sensor and the cold finger. I will need to measure this.
(Also I noticed an increase in the camera read noise but I swapped several capacitors at the same time which may be cause of this).

[N_DD]

Hi,

while waiting for some clear skies, I was thinking about the USB and power connections on my cam86: I think they share a common ground signal. Can this create a nasty ground loop, resulting in noise and other unwanted effects?

Nico

[luka]

Hi Nico,

Most of the switchmode power supplies are not grounded, i.e. the postive and negative DC outputs are floating. Just look at the mains connector of the power supply, most of them only have two pins for the AC and no pin for the earth.
So grounding one side of the power connector via the USB ground should not create a ground loop.


By the way, I have been too busy with work to do any more testing of the PWM TEC :(
Hopefully soon

[N_DD]

Hi Luka,

that should be the case, but I have noticed several times that if I touch the camera enclosure with the USB connector, then I can even see sparks :eyepop: meaning that the USB ground and the power supply ground are not at the same potential... I am powering the camera from a 12 V battery, and the USB is attached to a laptop running on its own battery. Did you notice anything similar?

And don't worry about the PWM TEC control: anyway I think the best option would be to redesign the board... but that is a whole other story!

Nico

[luka]

You have batteries and not power supplies... Is anything else connected to the batteries which is joining the grounds?

If not then what is happening is that the two batteries are not at the same ground potential as their grounds are not connected. Both are making 12V potential difference between their terminals but one battery relative to the other battery is not at the same potential. Likely also at a different potential to you, to the tree nearby etc. So when you touch the camera enclosure with the USB connector you basically connect the grounds together and a small current can flow over the air to equalise the two ground potentials. During this the electrons hit the air molecules and this produces light (a spark). The spark won't happen every time as the potential difference depends on the humidity, battery handling etc. Too small potential difference = no spark. As a rule of thumb, spark over 3mm gap corresponds to 1000V potential difference.

You will probably also see a spark if you just take a wire and join the two negative terminals of the batteries. Again a small current will flow to equalise the two ground potentials...
(just be careful connecting battery terminals, accidentally shorting the +ve and -ve terminals WILL HAVE BAD CONSEQUENCES as the (lead acid?) batteries can produce LOTS of current).

Anyway, there is still no ground loop as there is only one ground path from one battery to the other one:
battery 1 ground -> camera power ground (camera PCB ground) -> USB connector ground -> laptop ground -> battery 2 ground.

My setup is (still) in my backyard, powered from power supplies. I have never seen sparks but the connectors I used are "hiding" the wiring so it won't be easy to see sparks.
But I would not be surprised to see them when connecting the switchmode power supply (floating potential) to the laptop USB (another floating potential, the laptop mains plug has no ground).

Hope this helps (sorry about the long explanation, just looking for distractions from work :lol:)

[N_DD]

Hi Luka,

thanks for the explanation: still it is scary to see those sparks, especially when it's dark!
Hopefully I will have some more time to test the camera (here where I live it does not get fully dark until the beginning of August...)

Nico

[luka]

Beginning of August?
I may even find time to finish the PWM TEC control by then :lol:

[Zoroastro]

Good day all from Cologne to down-unter!

My name is Luca Mussati, I have read this forum for some time and now wanted to say thank you all - Luka great job with the software! - and ask if the cam86 is a stable/viable project. I bought cheap some D70 sensors and was trying hard to find reasons NOT to do this great project :), besides having very little tools and no electronics knowledge of course :lol:

Since my son will help me on the latter issue I was looking for the latest IIS PCB Gerber files and BOM ... can you guys point me to the right place for that?

Thanks a lot!
Luca

[luka]

Hi Luca,

Sorry about the slow reply, I was dealing with some health issues but am on the way to recovery.

To answer your questions, cam86 is a viable project. You probably already know but the two other forums of interest are the original Ukrainian forum (http://www.astroclub.kiev.ua/forum/index.php?topic=28929.3140) and the French (https://www.webastro.net/forums/topic/148427-camera-ccd-fabriqu%C3%A9-maison-quotcam86quot/?page=70) forum.

The original project/PCB has not changed for quite some time so it is quite stable. Quite a few people are using it already.

Having said that, I have started working on improved cooling with PWM but run into some noise issues. I may have found a solution but could not test how well it works yet. If it works this would require a minor modification of the PCB (trivial compared to the PCB assembly). It would be easier to do on our IIS PCBs than on the original Ukrainian PCBs.

I'll send you link to our Google Drive folder with the BOM and Gerbers.

Please ask if you need any more info, I should be able to reply a bit faster now ;)

[N_DD]

Hi,

I updated the ASCOM driver and camera firmware to the latest version, but I am now having troubles with the cooling: even if the software (APT) send a turn cooler on command, the cooler never actually gets turned on (see attached ASCOM log file). If I use the original hex and ASCOM driver provided by the Ukrainian, everything works.
Any idea why? I used to run the camera with the firmware 0.4 and ASCOM v0.73, but now, even if reinstall the same firmware and ASCOM driver, it does not want to turn the cooler on :confuse3:

Thanks,

Nico

[luka]

Nico, can you:
1. uninstall the driver

2. make sure that the folder
"C:\Program Files\Common Files\ASCOM\Camera\Cam86"
has been deleted.
(On 64-bit Windows it will be the folder
"C:\Program Files (x86)\Common Files\ASCOM\Camera\Cam86")
If the folder is still there can you let me know which files are in it before deleting it.

3. Reinstall the driver, update firmware etc.

On rare occasions the installer fails to clear files between the reinstallations so manually deleting the folder will give you a clean start (assuming ASCOM cleared options during the uninstall).
Let me know if it still does not work.

Which version started the problems? The latest (0.8.1) from the github with firmware 10?

[luka]

Important note:

After camera just has been switched on, during the first connection the software/driver may not set all the settings correctly. It was always doing this (since the original Ukrainian version) but I just figured out what was happening. No idea why yet.

The solution for now: After the camera has been powered on for the first time: connect, disconnect and re-connect again.

For example:
camera off -> camera on -> connect to camera -> possible PROBLEM -> disconnect from camera -> connect to camera -> NO PROBLEM

The following disconnections/reconnections are OK, it is only the very first time after the power was off where the issues may arise.

[N_DD]

Luka, thanks: I have tried to uninstall and reinstall the driver and re-flashing the firmware, but still it is not working.
However, I have realized that even with the original firmware the cooler get "stuck" at 1.56%, so I suspect I might have an issue either in the computer or in the power supply. I will try swapping them and let you know.

I am using the latest firmware and ASCOM driver from github. Before I was running the ASCOM driver v0.73 together with the firmware 0.4 and it did work.

Nico

[N_DD]

Definitely a power issue: using one with higher amperage solved the problem!

What I think was happening is that the TEC was drawing more current than the power supply was rated for (1 A) and that caused a "brown out" (low voltage). The voltage was still fine to power the camera logic, but somehow resulted in an erratic behavior.

So if you are running into weird problems, check your power supply amperage!

Nico

[luka]

Ah, don't you love the "weird" problems. What current/voltage is your TEC rated for?

[N_DD]

...I love weird problems, but only if at the end I manage to solve them!!!

The TEC is rated at 3 A, so it was pretty demanding for a 1 A power supply... :lol:

I should maybe have realized before!

[Zoroastro]

Hi Luka, has the latest PCB been corrected for this issue?
Thx,
Luca

[luka]

Hi Luca,

Sorry for the slow reply. Haven't check the IIS forums for a while, usually I on it several times every day but other things got in the way :(

No, the PCB is still the same. The Ukrainian PCB has the same issue, although I the effect may be smaller there.
I have tried using other capacitors but the lines did not improve much. Patrice (from French forums) used a larger tantalum capacitor (on Ukrainian PCB) and that helped. However, the capacitor is only rated for 6.3V which is way too close to 6V for my comfort. With the tantalum capacitors I like to have at least double-the-voltage derating.

Having said that, I have found out that the vertical stripes are not an issue, the bias files correct for them 100%. Also the image corners usually get cropped anyway.

[mlago]

Hello everyone.
I have been following this thread, as well as the others of astroclub.kiev.ua and cloudynights related to the CAM8X project. I thank you for the great job you have done.

The doubt that I have, after reading them in both places and for the modifications that have been introduced in this time, is to know which is the most recent version. I believe that the most current version of the project is your IIS PCB. So I would be very grateful if you could tell me where I can look the latest CAM86 project files.

Thanks in advance.

[wasyoungonce]

PM Luka but I’m not sure what the files are up to atm. I had to stop the project due to hospitalisation and on going issues. Also the group would want you to actively assist on development not just grab the latest files.

I hope to rejoin devolpment but could be up to 6 months before I can. Also I think Luka is quite busy atm

[luka]

Hi Marcos,

Can you PM me regarding your request.

There are two versions of the PCB, ours and the original Ukrainian. Our version:
1. has improved TEC power
2. has an issue with capacitors being too far from one of the components (DD8) resulting in vertical lines on the left side of the image.
This is not really a problem as bias files completely remove the vertical lines from the final image.
Also the vertical lines can be overcome by using larger capacitors and some "creative" soldering.
(Note that the Ukrainian version also has vertical lines but less intense)

Luka

[mlago]

Thank you very much to both.

With his explanation now I have it more clear. I will send you a PM, thanks so much!!

[luka]

The project is still alive and kicking :lol:

New driver update, v0.8.3 can be found at the usual place (https://github.com/axsdenied/cam86_ASCOM). No change to the firmware.

Changes:
Fixed the bug where sometimes the camera parameters do not get set up properly if the camera has just been powered on.

Have fun and let me know of any bugs.

[Zoroastro]

Hi Friends,

I just completed the IIS CAM86 thanks to Luka's files. I have all the tensions right, flashed the eprom etc but the test image without sensor looks a bit weird :(

I double-checker all the soldering, they look fine. Any suggestion? Maybe a defective Vertical Driver?

Cheers,
Luca

[luka]

Which firmware are you using? Try the original Ukrainian one.
Also double-check the soldering on the vertical driver.

Otherwise the best is to ask the question on the Ukrainian forum (http://www.astroclub.kiev.ua/forum/index.php?topic=28929.new#new), Rim usually replies quickly.

[Zoroastro]

Hi Luka - I tried also the v01 firmware, no luck. The 1267AN joints look OK, in doubt I redid them again with a bit of solder. No improvements.

I have registered on the Kiev forum, let's wait their answer. Maybe an issue the 1267AN from China ... but I will solve it.

Cheers,
Luca

[N_DD]

Hi,

would it be possible to have a 64-bit driver for Cam86? I would like to try my Cam86 with N.I.N.A. (https://nighttime-imaging.eu/), but the recommended 64-bit version of it only accepts 64-bit drivers...

Thanks!

Nico

[luka]

Not easy.

The DLL with the basic camera functions is written in Delphi. I only have a really old version of the compiler which can only compile 32-bit. I am scared even to look how much a new version of Delphi costs.
So I may need to rewrite the DLL which is a big job.

Alternatively I could try using the 32-bit DLL from a 64-bit application but that requires writing a wrapper DLL as in Windows it is not possible to run 32-bit DLL from 64-bit application. Again more work.

Let me look into it a bit more...

[N_DD]

Hi Luka,

did you try FPC? (https://wiki.freepascal.org/Main_Page)
It seems it supports some Delphi, but I am not sure if it would work for the low level library of Cam86. I will give it a try, although I am not at all an expert in programming!

[luka]

Apologies, I thought that I already replied on the progress of the 64-bit driver. Mixed news, it is working but not well.

Embarcadero, the current owners of Delphi (after Borland) have a free version of Delphi for hobbyists. That includes a 64-bit version.

With it I managed to import and recompile both projects (FTDI driver + camera driver) but nothing worked. Our code was written before Delphi was migrated to unicode. I had to manually change every string and all string functions and eventually I managed to talk to the camera.

Unfortunately the new driver keeps crashing and debugging a DLL called from a DLL (which is called and calling another DLL) is not that trivial. And things being written in two different programming languages (c# and Delphi) does not help either.

I have not given up but finding where the problem is may take a while. It probably is something simple... but I still have to find it :mad2:

By the way, the main DLL went from 300kB to 1.6MB in size, simply by recompiling it with the new Delphi compiler :shrug:
I am not sure if there will be more issues once it is working properly.

[N_DD]

No need to apologize at all!
Thanks for trying and compiling a 64-bit driver: I am sure you will manage, eventually! :thumbsup:

Nico

[Zoroastro]

Hi Luka - any developments on the dedicated power supply for the Peltier?

Thanks,
Luca

[luka]

The 2nd version of the power supply is finished. It also provides 8V to power the Cam86 to reduce the heat generated from the regulators on it.

See screenshots of the TEC power before and after the smoothing (the purple line in the 2nd image, ignore the other two).

However, this was tested with the camera opened and on the bench. The cold finger was not touching the back of the sensor. We are currently redesigning the housing to fit the new power supply only then we can do the proper tests with the assembled camera and take the bias images.

In other words without the power supply being attached to the camera I cannot be 100% sure that it will eliminate the noise. But this is probably as good as it will get.

[luka]

I have attached images of the schematics and the finished PCB. Very crowded. The dimensions are 40x20mm and it is designed to fit in our slightly larger case. The barrel DC power connector is waterproof.

I can share the designs but as I said I am still not 100% convinced it will work perfectly.

[StevenR]

Hi Folks,

I'm new the forum -- I hope it's not tool late to join the discussion and build a Cam86?? I've got the sensor and many other parts and I'm keen to build the camera. Having spent many years as a software engineer I hope I can add some value to the firmware and software utilities.

I've spent a couple of week reading over the various fora covering Cam86 -- the resulting knowledge bank is a credit to the community.

Now my key questions?


Where is the best place to find Gerber files (or better still , the underlying CAD files) so I can order the PCBs?
What is the state of the firmware? Is https://github.com/axsdenied/cam86_fw current?


To assist other newbies I'm summarising my reading review at https://github.com/smr547/cam86

Any help would be greatly appreciated. Congratulation for producing a fantastic thread!

[pat30]

Hi Steven,
welcome to the adventure, help you will find to help you in the event of a difficult moment, I am Patrice from the French forum but as you can see, I am listening to other forums as well ;).

For Gerber, it depends on the model you want to build, there is the original one available here (http://astroccd.org/2016/10/cam86/) or the IIS version available at the start of this discussion.
Luka did a great job on the Firmware and it is compatible with the 2 versions they are available here (https://drive.google.com/drive/folders/0B33NUzWf6odbYUFBYlVuVTUwejQ).

Avoid taking the kit on EBay, a French member had problems with it, without having yet found the source ...

:welcome:

[StevenR]

Hi Patrice,

Thank you for the reply. I've requested access to the ISS GitHub files and will visit the French site soon. I'm slowly working through the circuit diagram and firmware code to understand the design and operation of the camera. Oh yes, I'll order some PCBs this week -- but not from EBay. Thanks again Patrice. Talk soon.

[luka]

Hi Steven,

Welcome to the build and to the group. Apart from the adventure of building it, you will find that the camera works really, really well.

Patrice already pointed you to the latest firmware/software on github. I would suggest using that over the Ukrainian firmware/drivers (but then I am probably biased as I wrote lots of additions to the original Ukrainian drivers and firmware).
I have been working on updates to the software/firmware since the end of the last year but the life got in the way...

Fire away with any questions that you may have.

[StevenR]

Thank you Luka, it's great to hear from you. I've been reading over various threads and love your work!

Like you, life is getting in the way at the moment (I'm getting married this weekend :D). But once the excitement is over I'll be back to the camera. My new wife knows about my CAM86 obsession and is very supportive (I hope it lasts)

Meanwhile, how do I get access to the Google Drive where design documents and source code is stored? Do you store your code in a GitHUB repo?

kind regards
Steven

[luka]

Steven, congratulations on getting married. Wait until the kids come, then there won't be any time at all left for cam86 ;)

The source code is all on github, see here (https://github.com/axsdenied/cam86_ASCOM) (and the links within).
The latest version that I am working on is not there yet:
1. It is still work in progress.
2. It is for a camera with a slightly modified hardware so it won't work on everybody else's cameras yet.

Can you PM me your email so I can share the GD with you.

By the way, the work-in-progress source code is on the GD but always use the latest version from the github. The software is quite mature and I am almost out of ideas what else to add, only small tweaks here and there.

[9artus]

This is my first post to the group. I have built and debugged many sma boards over the years as related to amateur radio; but, I am unable to get a CAM-86 running. The board voltages are correct and the the board appear to work through the steps of setting the fuses and programming the ATMEGA. I even tacked an ICSP connector and verified the fuses and program with AVRDudess.

However, I see no timing signals on my scope from PC1-6 ports on the ATMEGA. I installed the ASCOM drivers. The CAM86 viewer recognizes the camera but there is nothing but a black image. I did not install C15,C16 as noted the developers' site. Also, I have spent a great deal of time with a 10x loupe looking for issues. I am suspecting a failed component -- some of which I have had to source from China, but wonder if anyone else might have a suggestion. I am assuming that the failure to detect timing signals is indicative of the problem. Thank you for any advice.


Jack (Jack Generaux-- Kansas City)

[luka]

Hi Jack
Not sure what is causing the problem. Can I suggest you ask the question in the original Ukrainian forum (http://www.astroclub.kiev.ua/forum/index.php?topic=28929.0) (Google translate works quite well for it). Rim, who originally designed the camera, is very helpful and can hopefully diagnose the problem quickly, or point you in the right direction.
Luka