DIY ICX453AQ, Sony sensor CCD camera

[gehelem]

Anybody tried new firmware/camview ?
Quick test gived no result for me (black images)
Need to investigate, but rolledback

[luka]

No issues here with the new firmware/camview. I even tried it with your indi driver last night and it worked fine.

Also there is no white line in the first row under kstars with the indi driver (linux).

[gehelem]

Ok cool
No issues with cooling under windows ?
Did you try in your living room or under real sky ?
> you would be the first to run my driver with real stars, i would really enjoy to see a picture, even a bad one :lol:

[luka]

I only have uncooled Cam86 in 3D printed (plastic housing), i.e. no cooling yet to test. But it can take images fine with the latest firmware.

I don't have linux on my laptop (the old laptop died so linux is only on my desktop) so I have to figure out some way to use the cam86 with linux outside the house. Do you know if the old Raspberry Pi 1 (model B, 256BM of RAM) can run indi? I have a few lying around.
Actually I may have a Beaglebone Black as well somewhere...

I also played with your driver today. I tried to get rid of the horizontal stripes by changing the FTDI parameters. Could not see any pattern that permanently removes them. I am not sure what is going on. I want to check if taking images with cam86_viewer results in horizontal lines.

I checked the Ukrainian forums and few people use MaximDL for acquisition.

[luka]

Gilles, got the driver working on Beaglebone Black. Few observations:
1. The lines are really bad, present in every image. Quite often it is not just lines but "blocks" of "misplaced" data showing vertical artifacts.

2. Acquisition is very slow. After the exposure it does
...
Try 2000 since 11778624<>12008000
for few seconds and then it takes few seconds again to transfer the image. I timed 15 seconds to take, transfer and show 1s exposure.
edit: for comparison taking and showing 1s exposure on my PC takes 5 seconds.

3. The CPU usage is 100% for several seconds. This seems to be part of the bottleneck. Only one CPU core is used at time. Firstly ./indi_cam86_ccd takes 100% of the CPU (image processing?) and then indiserver does (image transfer?).

Have you tried using the driver on a Raspberry Pi yet? The lines are present in almost every image on the BeableBone Black and they probably will be on Raspberry Pi as well. This may make it easier to tweak the FTDI parameters. I tried changing the parameters and at one stage got few good images but the same parameters did not work few minutes later. There is something weird going on.

Also what do lines like this mean?
Try 2000 since 11778624<>12008000

[gehelem]

Quick explanations time - be carefull i have flu, my head is "high in space"
There are two libraries we can use to talk to ft2232


Original D2XX from ftdi
LibFTDI from intra2net

The first one is the one used in ukrainian sofware, under windows.
I've first coded my cam84 driver with this one on linux. It is working quite well, no lines, no transmission troubles.
BUT : under linux, using bitbang mode with this library forces to unload ftdi_sio module.
The delicate consequence is that you can no more use other ftdi device, in a classical usb/serial converter for example. This is really annoying : can't use Eqmod on raspberry, nor any device using these devices (arduino/Moonlite focuser in my case)

The second library allows to keep module ftdi_sio module loaded, you "only" have to unbind it from kernel for a specific device (purpose of the udev file).
BUT : function calls are very similar, but there are a few specific items.
One of the biggest is the bitbang reading process. when you start a reading call, if there is nothing to read, function returns immediatly. This is the purpose of "ftdi_read_data_modified", wich is a hack submited by Toups on Indi forum :
http://www.indilib.org/forum/general/1388-help-with-diy-ccd-driver.html#12731
This function is reponsible of the messages you get ("Try 2000 since 11778624<>1200800").
What do they mean ?
1200080 is the size of the data buffer we try to recieve (twice the number of pixels, in fact)
The function is trying to wait 2000x1us (max) that buffer is fullfilled.
I also have often these messages : i'm not really sure, but i think it is because the reading process is not synchronized with the "rythm" given by atmega.
Here, with "Try 2000 since 11778624<>1200800", we certainly have missed some data, because reading is starting too late.
In that case, your image is incomplete, and gives misplaced blocks you are talking about.
This is why i try to find good values of parameters : latency, baudrates and timeouts.

To investigate, we have a simple solution i've already done for cam84 : switch back to D2XX library. i will try to do that this week end.

Your point about CPU usage is really interesting, i didn't noticed that.
For sure it is the reading process itself
On my Odroid XU4, reading the image takes a few seconds (<5/6s)

I had no time to try my raspberry 3, too many things at the same time (wife's car KO...)

Gilles.

[luka]

Thank you for the clarification, I understand much more now.

See the attached image, taken with the BBB and hand-held lens in front of Cam86.
One thing I am unsure about is how some "lines" do not shift the image but some have very drastic effect (see how the whole blocks of the image have been shifted around). I have a feeling there are two types of artifacts happening here, data loss (image shift) and also data mangling (visible lines but no image shift).

Also note black line on the bottom showing the missed data.

BBB is slow so all effects get emphasised. It may be useful to use a slow device for debugging the problem. I have noticed the "blocks" also on my PC but they don't happen very often.

And the windows driver also has lines but only on some machines. The issue probably exists everywhere but some machines handle the data transfer better and the issues are less obvious. My guess is that if enough images are taken on a machine that apparently works, the lines will eventually show.

I am just curious how this was not reported before on the Ukrainian forums, apart from Pat?

[luka]

Some testing on Windows. I recompiled the Ascom driver with latest version of FTD2XX_NET.DLL. No other changes. Tried it out using cam86_view on my laptop that usually shows lines and it did not make a difference, the problem was still there.

However, after about 10 images I got one that not only had lines but also blocks, just like we saw with your driver Gilles. Also for this particular problematic image cam86_view reported reading time of 3.7 seconds instead of the usual 2 seconds.

[rcheshire]

Are some of those lines due to switching events? You guys are the electronic experts, but this problem seems almost universal. All my DSLR cooling mods required separating the analog - digital grounds and connecting the cold finger and camera chassis to power supply ground - no more lines.

Looking at the schematic and PCB, an inductor between mosfet source and ground, as well, might help.

[gehelem]

Thank you for suggestion
I don't know, it might have some influence, but we have these lines even when cooling system is not plugged (ie no TEC on board)
We are searching on hardware/PC side, since some configuration seems to give more bugs than other (old laptop vs brand new vs arm ...)

[gehelem]

i've added possibility to compile linux driver against D2XX library.
Not committed on github as it gives even worse results :confused2:

New trick noticed : i have no problems when i use 2x2 bining

[pat30]

The camera works better with my notebook (Toshiba nb250) quite old, same software, even Windows ?????

The only thing noticed is that the reading time is longer when there are lines.

[luka]

Rowland, thanks for the tip. Any ideas are greatly appreciated as we seem to be stuck. Mosfet switching is not likely to be the cause as, at the moment, I am not using any cooling and mosfet is off.

Gilles, I rewrote the ftdi_read_data function to use timeouts instead of a fixed number of loops. Check out my pull request on github.
I have set the timeout to 3 seconds as normal image reading should take about 2 seconds. Anything much over 2 seconds is bad and indicates problems.

Note how no data arrives for about first 1000ms and then we usually get all of it. The image may still contain lines indicating data corruption but no data loss. But if data is missing (blocks in image) we will get timeout.

Also I read somewhere that latency of 1 should not be used as it can lead to data loss. I changed the default values to 2 but it did not make any difference.

Then, what is 1 second delay (usleep ( 1000*1000 )) in readframe() doing (line 349)? I could not see any difference when I removed it. It is quite a long delay.

I tried 2x2 binning and it took lots of attempts but I got one line (on PC). So the problem is still there but less data to transfer means less chance for the problem to show itself.
When doing binning I noticed message
grabimage width=3000 height=1000 BPP=16
If we are doing 2x2 binning, why is the width still 3000?


Anyway, the problem is evident on Windows and Linux. Linux may be caused by drivers or our bugs and is worse but Windows... don't know. I noticed the same as Pat on Windows, longer reading time when there are lines or blocks. It seems to be machine dependent. I have one old laptop which has lines in 50% of the images (on Windows). Good for testing :-)

I am more convinced that there is either a bug in the FTDI drivers or in the Cam86 software/firmware. I mean at least under Windows the cam should work properly. I may need to join the Ukrainian forums and ask the guys there. It is weird how nobody there complained about the lines but we all are...

Filip, did you see any image corruption on your Cam86?

[pat30]

Luka, dont you sleep ?? :lol:
I still asked the question, on the forum Ukrainian, Rome gave other tracks but I think not good, for me, there is a problem with the driver but you never know.
Do you have an oscilloscope?

[luka]

Plenty of time to sleep when I die :lol:
It is "only" midnight here (in Perth), just going to bed now.

Yes, I do have an oscilloscope.

[pat30]

It is a good vision of life :lol:

I thought later.

View forum Ukrainian to test with oscillo.

[gehelem]

Thank you very much, i've merged your code (first time i do that !)
I've corrected the readframe function : i've removed the unnecessary buffer purge, and the delay (don't know why i left that here...)
I fact, this way i've no more "blocked image", very good point, thanks again.:thumbsup:
(EDIT : Do you want to be mentionned in author file ?)

Also, when you start an exposure, the message displayed was width=6000 (and 3000 when binning 2x2) it was just because we are working on 16bits and frame buffer is twice larger...
Correction done : i've divided by 2 when message is displayed :D

I think it's time to try on other platforms.
Raspberry 3, here i come !

[rcheshire]

Pat and Luka.

I'm out of my depth in that case. I recall laptop monitor interference years ago with USB connected to an Arduino board for serial output to the monitor, but cooling was running. Interestingly, I no longer see this, even with switching events in the images. Software related. I take the point.

[luka]

Rowland, as I said any suggestions are greatly appreciated, thank you. You are probably predicting the problems that we will soon have, once the cooling comes on :lol:

Pat, I had a look at your images at the Ukrainian website and mine are slightly different. My images show vertical noise and the StdDev is higher than yours, I believe within the expected range (see image 1). But the lines in images are common. I did not have time to check the 15V power yet but I have a feeling it is not a hardware issue (at least not for my cam86).

Now, I made some progress with my tests. On one of my laptops I took 1000 images and all were 100% line-free. Then while taking images I started copying large files over WiFi and bang... see the attached image 2.

The issue was easily reproducible every time I started copying files over WiFi. I think WiFi card inside the laptop is connected to the internal USB hub and the bandwidth is shared. Hence simultaneous copying and imaging puts load on the USB bus and we get corrupted images.

Of course if you are using a desktop PC there may be multiple USB controllers and connecting the camera to a different USB port may give different results.

Gilles, this was all on Windows. The latest code still gives lines/blocks here. I actually tried a different USB port and it is worse, much much worse :shrug:
I started working on new code to use ftdi_readstream as it may improve the reading performance but it is not working (yet), I just get blank images. Not sure if I am using it correctly, there is not much documentation out there.
Happy to be listed as an author, thank you.

I will do more tests tomorrow, need to stop now. Need to fix the power supply for my cooled 450D... can't wait for this build to be fully working :D

[flolic]

So far, no.

[gehelem]

Ok give me your name, or if you prefer i can just say "Luka from IceInSpace Forum" with a link to this thread.

I've also awkwardly tried these "asynchronous" functions with cam84, but with no chance...
If you achieve this it will be fantastic !

BTW : have you simple hints to use github correctly ? i've reached my limits and i'd like to understand the way things should be done (how should we work on the same file ? if i merge your pull request, i loose my local changes for other stuff, a fiew lines further... should i merge manually ?)

[gehelem]

One litte guess :
Flolic, obviously you look to build your stuff very wisely :2thumbs:
I've seen on your pictures that you are twisting wires : what is the purpose ? is it like on my valve amps, where we have to twist wires to avoid interferences between heating circuitery and signals ????
Might it be the same for usb signals and alimentation ?
I think there might be something here because when i move my cam86, i sometimes get no "lines" and sometimes i get some...
My power supply is a mini switching one, and it might be a point i should have a look at.
Gilles.

[flolic]

Gilles, USB data wires should be twisted and shortest possible. The purpose of that is to preserve signal integrity, by reducing electromagnetic interference and possible crosstalk.
Googling "twisted pair" will give you much more info ;)

[gehelem]

Thank you, that's it, i'll do that tonight.
And what about power supply wires ?
EDIT : i googled that last point, and it seems not to have any effect.
i will try to plug another regular supply (ie not switching...) just to test...

[wasyoungonce]

Finally an update.

Managed to fit FTDI LQFP64 and ATMega328P and associated power then tried programming them...ahhh yeah didn't go so well at first. I was getting the following error... "Error reading device" in MProg.

Apparently I needed to fit the EPROM IC DD2 to the PCB, MProg was not reading the FDTI properly because its EPROM was missing! Go figure. Sigh!:sadeyes:

Anyway after installing it ..all went well. Fusebits done, ATMEGA328P programmed, cam86 ASCOM installed ok, connected to cam86 view fine. Although not much to see as the PCB only has enough fitted to do firmware.

[pat30]

Luka you should post your pictures on the Ukrainian forum, because we are not alone now, 1 others to the same problem.
Between all should have found the solution!

[luka]

Gilles, I PM-ed you my name for the github. Thank you for including me.

Also, if I can add to Filip's comment, the keep the lengths of the twisted data lines the same.

Regarding the github, I am far from expert but when you start changing code you should never do it on the master branch, i.e. start a new branch, do coding and when happy with it merge it. That way the overwriting code can be avoided. Also you can (somehow?) give me permissions to the repository which will give me the same rights as you. This will let me start a new branch and do changes there. You can always change branches and see what I am doing and otherwise. But if you give me permissions you lose 100% control :D
Right now I had to fork your code, do changes on my fork and do a pull request for you to review. It gets messy that way as you have seen.

Great work Brendan :thumbsup: Keep populating the board, you are almost there.
And that was a great shot of dark matter :lol:

Pat, I am waiting for approvals to join the Ukrainian forum.

By the way, some info for our European friends, I am in Perth which is at the moment 7h ahead of you. Few other guys are on the east coast of Australia which is 10h ahead of you.

[pat30]

It's really complicated for the Kangaroo, 1 country and five different times :lol:

https://upload.wikimedia.org/wikipedia/commons/thumb/2/2a/Australia-states-timezones.png/220px-Australia-states-timezones.png:confuse3:

[luka]

It is even worse, some states have daylight savings while some don't. I never know what the time difference to the east coast is and need to use google to find it out.

[gehelem]

Your name is in the author file.
I don't want to keep 100% control on what is not 100% mine : i've tried to add you as a "collaborator", i think you have to accept before i can grant any access to you...
Let's give it a try.
And i'll follow your advice : for now i will try to work only a branch ("gehelem"...)
Gilles.

[Gary47]

Brendan, Luka.
These are for you. Waiting for anodizing.
I don't mind Christmas but why do people I need have to take holidays.?
Gary

[luka]

Gary, they look fantastic :eyepop:
Many, many :thanx:, you made my being-sick-in-bed much, much more bearable :)

After a LOOOOONG wait (2 months or so?) my TECs arrived today. One is 6.58-6.59mm thick while the other is 6.57-6.58mm thick.

[wasyoungonce]

I 2nd that. They look really good, excellent job Gary.:thumbsup:

[wasyoungonce]

ok camera is alive.

It has some vertical banding issues I am dealing with thru testing various horizontal driver filter caps, and frame std deviation is high, I need to work on this as well.

Here is an image with camview. gain offset at zero, sensor covered (if I uncover it the frame is all over the place).

[pat30]

Test without sensor, I think a parasite light.

[wasyoungonce]

Hi Pat I'm pretty sure you're correct...but in the mean time...fiddling around DD8....with caps...all of sudden it won't connect to camview...the 3.3V reg is getting hotter and I draw is now higher 238mA.

Which is not a lot but the regulator is sure heating up more.

I did some more "dark tests" and the camera was performing ok a little high on std deviation but could be sensor heat.

So I need to go back to find the failure!:mad2:

Brendan

edit edit:
Hey the previous I draw measurements were wrong ...the following is correct:

...Anyway looking at the I draw I said I have 230mA. Other users mention ~220mA so this is not "out of this world". My previous I draw tests were incorrect as I was measuring total I draw not just 3.3V I draw.

I cut the gnd of DD12 (3.3V reg) and put an ammeter in series. It draws 107mA. @10V in (actually 107mA 8V ~12V in). That's a 6.7V drop across the regulator and this at .1A is ~ 0.67Watts VDrop across the regulator! Its a little too much too much its rating is ~100mA and we are there now.

Brendan

[gehelem]

@Luka
i've just made changes to our driver, to merge with the recent Delphi code given by Rome from the Ukrainian forum.
I've also discovered a "FTDI read data hack" into library provided for QSI camera
They obviously seem to use ftdi chips, and i've taken their code.
=> i have no more "blocks" ! (for the moment...)

Gilles.

[luka]

Gilles, did you try the new code on the Raspberry Pi or are blocks gone only on your PC?

I tried it here and I still get blocks on my PC. The new code for ftdi_read_data function is very similar to our old code with timeouts. One thing that did change is the reduction of the size of the read buffer from 65536 to 16384 (1<<14) but this is giving me more lines/blocks.

My attempts to use asynchronous reads are not going anywhere, it reads data even when there is none to be read :shrug:. I was sick but am feeling better now and may have another look at this.

Also my Windows laptop that had lines has died, now I only have the new one that almost never shows lines.

Luka

[wasyoungonce]

Damn that's good of the Ukrainians to make it open source:thumbsup:....is it open source or just the source code? This will kick it up the road a lot!:thumbsup:

Hope you are feeling better soon Luka.

Brendan

[luka]

Grim released the source code only. I did not see any license or anything else said about the code or any restrictions about its use.

I assume we can add whatever we want to the code... so start throwing ideas around :D

A humidity sensor (if we can wire it and fit it inside a case) would be useful for example.

[gehelem]

I asked Rome (aka Grim) before to publish anything :
He asked 2 things : code must remain free, and we must keep his name
That's why i published mine under gpl 2.1 (i think i have to because of libftdi)
I'll ask Rome if we can do the same with his firmware

[luka]

Excellent idea Gilles.
Can you please ask him about the firmware, the Ascom driver and the viewer software... at least two people are involved in the software.

[gehelem]

I've just asked on Ukrainian forum.
Rome is the only one : Sergiey Vakulenko told me he is "only" the author of Ascom driver. Nevertheless, he is already in the author file on my github.

Regarding your tests : did you flash your cam with new firmware ?
i've not ported everything ATM : i've just changed things I though the most important, especially the place of "Spi_comm(0xcb,0)//clear frame"
I must check everything else (role of CameraReadingTime for example)
There's also a rework around temperature reading, my version gives silly readings now...

BTW, I found a lost treasure : the box where I had stored my collection of Raspberry Pi
So now i can test B, B+, 2B, 3B
Wich one is yours ?
I'll test tonight on RP3

Gilles.

[gehelem]

Raspberry pi 3 is giving good results.

But let me explain the way i play, as it might explain differences :
My RP3 (or Odroid xu4) is running headless.
I launch indiserver trough ssh.
Then, my kstars session runs either on big ubuntu PC (intel i5) or an old Windows Seven. I connect to distant RP3/Odroid indi server (especially this is awesome !)
Yes, there is a windows version of kstars, that suports distant connections.
This way, for 24h, I never get blocks neither lines.

I get blocks and lines when I open a full RDP session to RP3, and run kstars on it. (same on Odroid, but less often)
But we know that : CPU/ressources load is the issue, am I right ?

Gilles

[luka]

Hi Gilles,

I did not flash the new firmware, I completely forgot about it. Well that is not quite right, I did some tests with it initially and then I flashed back version 1 and forgot about it.

A question, which firmware did you use? The latest firmware called cam86 prob3.hex did not work for me, its uncompressed size (18kB) is much smaller than the earlier firmwares which were about 75kB. I downloaded it several times and it was always the same.

My Beaglebone Black (BBB) setup is similar to yours, running headless. Kstars runs on my PC (debian). The lines that I was getting was all on my PC, I did not test the BBB recently but after you mentioned the firmware I will need to test with the new firmware.

Also I did more work on the synchronous/streaming data transfer and gave up on it. It will never work with our current hardware. The high speed transfer is clocked at 60MHz which our ATMega cannot do. Also the wiring for the control of synchronous transfer is not connected (pin27 TXE#) so we are out of luck. It is a dead end unless we change the hardware.

Great find of your RPi collection :lol:. I have quite a few as well, 2x RPi B (unused), 2x 2B and 2x 3B but the last 4 are all used. I can always take one down for testing but I thought I will try with a BBB first as it was unused and faster than the original RPi B.

Luka

[luka]

Tried firmware "cam86 prob2" on my main PC, I still get occasional line but no blocks any more. This is a relatively fast machine with i5-4590 CPU.

[N_DD]

Hi!
first post here: I was following the cam84 thread on cloudynights and on the Ukrainian forum and eventually built a cam84 and a cam86 (and already have a chip for building a cam90 once it will be published! :D).
Now I somehow got lost with the firmware versions (I am still using the original one for my cam86) but with it my camera is exposing even when it should not: I am getting around this by acquiring and discarding a short exposure before starting a long sub, but I think this could be addressed at the firmware level (or has it already?!). Which firmware is the most up to date/best?!

Thanks for keeping this project alive and CS,

Nico

[luka]

Hi Nico, :welcome:

There were several versions of Cam86 firmware.
1. Initial release (cooler off during frame reading)

2. The same as 1 but with cooler on during frame reading

3. cam86_firmware_prob2
"Add at the end of each line read adjustable delay. Delay increases the reading time frame for 2 seconds later."
This version came with a new cam86_view software that has a slider for adjustable delay.

4. cam86_firmware_prob3:
"The delay in each pixel. Casting Time of 3.8 seconds."

Firmwares 3 and 4 have been released as some people had horizontal and vertical lines in their images. The adjustable delays fixed problems for some.

I was unable to use the firmware 4. The downloaded firmware file was much smaller than the other firmwares and did not work at all after flashing.

Regarding camera capturing light when not exposing, this is something all? sensors do. If I remember correctly what Grim explained once, the charge accumulates in the sensor at all times. The firmware does some cleaning before exposure but this does not work completely. The only way to fully clean the sensor is to do a short bias exposure before a real frame, just like you are doing.
Another example of this is that we can see light signal in 0ms exposures.

This can be best fixed in the ASCOM driver and not in the firmware. There was some talk about this being done but I have not seen any ASCOM driver releases since the initial one.

I will have a look at the ASCOM driver...

Luka

[N_DD]

Thanks Luka!

I am not getting any broken images, and the cooling off during download is also ok for now, so I think I will stick to my firmware. It would be great to have a modified ASCOM driver to address the charge accumulation: how do the commercial cameras deal with this problem?

Nico

[luka]

Hi Nico,
I don't know how the commercial cameras deal with the charge accumulation as I never had a commercial camera before (just DSLRs). Anyone else?

Modification of the ASCOM code seems simple enough, just not sure what is the best way to do it. See the quoted Grim's post below, he suggests to do a bias before shooting if there is more than 30 seconds between the shots. Would this be OK? I can probably add an adjustable gap instead of fixed 30 seconds between images to trigger the bias-before-imaging.

Note that doing a bias shot before exposure would add 2 seconds reading time to each shoot (probably shorter if 2x2 binning is used for the bias?).

I am curious, which imaging software are you using now? How do you do a short exposure before a real one?

Here are translations of Grim's old posts from the Ukrainian forums describing what is happening:
Post 2030:
Post 2064:
Luka

[gehelem]

I think commercial cameras use hidden pixels on each row to evaluate the charge...

[luka]

Now that is very interesting information Gilles. Our sensor is 3008 × 2000 pixels and we are using "only" 3000 x 2000 pixels so there would be 8 unused pixels in each row. This could potentially be used to evaluate the accumulated charge but would require modifications to firmware and drivers.

But is this approach really useful for astro-imaging considering that our image consists of areas of extreme contrast (stars vs background). For example, if there are no stars in the hidden pixels the evaluated accumulated charge would be zero there... but there may be very bright areas in the rest of the images from star light.

[N_DD]

Hi Luka,



I am using APT (www.ideiki.com) and setting up an imaging plan with a short (0.1 s) exposure followed by the actual long exposure. I am dithering every 2 frames, so that the long exposure starts immediately after the short one.
Thirty seconds sounds ok: exposing this value in the ASCOM driver would also be great! Another approach would be to acquire a bias if the requested exposure is longer than say 10 s: in this way, longer sub will be "clean", while shorter ones (presumably acquired either for "live view" or for focussing) will still download faster.
I was wondering wether it is really necessary to download the bias frame: would it be possible to simply apply the vertical clock to the sensor and dump the result? Kind of a 2000x bin! Or what am I saying makes no sense?!

Nico

[luka]

Working on the ASCOM driver now, may even have something later tonight.

Nico, I am not sure how the sensor works and what can be done. We will probably have to experiment to get things working as good as possible.

Gilles, did you manage to use the firmware cam86_firmware_prob3 or did it fail to flash for you as well?

[gehelem]

No I had the same problem (suspect file size)
I didn't went further

[luka]

Did lots of changes to the ASCOM driver but it is not finished yet and there are still few bugs to sort out. Debugging dlls running from dlls running from ASCOM is a pain.

I have started adding options to:
1. adjust reading time like in the latest cam86_viewer (done)
2. adjust time for taking bias before exposure to clear accumulated charge (done but untested)
3. have option to chose between TEC on or TEC off during reading
4. option to switch between mono/colour sensor (not sure if any software uses this information).
5. store options between sessions (it seems to be in the code but it is not working)

Nico, when I tried to test the new driver I could not get the cam86 to show effects of charge accumulation while not exposing. I could not see it either with the original driver/firmware. Can you describe how to replicate the issue?

[luka]

Gilles, which OS are you running on your RasPi3? I want to replicate your setup and try it out.

[gehelem]

Ubuntu Mate 16.04

[pat30]

Super luka for the modifications of the ascom driver especially the 1.
If you want to try the firmware Prob3 (https://drive.google.com/file/d/0B33NUzWf6odbY3prQkJ4d3RkM0U/view?usp=sharing) here is the link of my drive or you can download it, this firmware does not work with APT just with Camview-prob

[N_DD]

Luka, that's great, thanks a lot!



In my case it is pretty obvious: I leave the camera illuminated without exposing, then I take two consecutive exposures of same duration. The first one has much more signal than the second.
Tomorrow I will check the SUB signal of my board, just to be sure that I don't have any hardware problem.

Nico

[luka]

Thank you for replies.

Also let me know if you have any other ideas to add to the options window. Or any other general ideas how to improve things.

I though of another one, to change the colour scheme to black/red to preserve the night vision.

The only one issue I have is that the settings window is getting larger with all the additions. Is this a problem?

edit: Screenshot of settings is attached (needs a bit more work of course)

[pat30]

Once the settings made, I close the window so even if it is big it is not very serious, bravo for your work is great :thumbsup:

[gehelem]

Thank you for ascom driver :
I think you should tell Sergiy Vakulenko on Ukr forum, as he is certainly working on it too
Gilles

[luka]

Gilles, once this is sorted I can make similar changes to the indi driver.

I have noticed some small but significant differences between the source code of the ASCOM driver and the cam86_view (which does not use ASCOM, most of the code is shared). The biggest differences are in the FTDI initialisation and exposure. I assume that the viewer has newer code than the several months old ASCOM code. I am comparing files line by line, this may take some time :(

Gilles, see Cam86.pas, lines 286 and below if you want the latest settings.

On another matter, I have noticed that APT sends temperature and cooling power read requests while image is being transferred. The driver passes these requests to the ATMega328P and this interrupts the image transfer. This could possibly explain the white line we are seeing in the first row of the image... Another thing to add to my list :rolleyes:

[luka]

Stopping for tonight, time for :zzz2:

Gilles, I want to finish something before posting on the Ukrainian forums. I am soooo close... but soooo far. Everything is working but I managed to break the offset setting somehow :shrug:

Some good news for the APT users, I modified the driver to return cashed temperature and power requests and the white line in first row disappeared :party:

Did anyone try to compile the firmware yet? Any idea which compiler was used?

[luka]

Volunteers needed to test out the new ASCOM drivers :D

My camera does not have cooling yet so I did all testing inside with room lighting. Also while I did not touch any of the cooling code I could not test if anything got messed up. So please pay attention. This is a major update.

Changes:
1. Update driver code to match the newer cam86_viewer
2. Update to the latest FTD2XX_NET drivers
3. Added reading time adjustment like in the latest cam86_viewer
4. Added (partial) night mode
5. Fixed bug causing image corruption in APT (a white line in the first row of images). This also fixed the histogram in APT. Basically APT was requesting temperature and cooler power while image reading was in progress and this corrupted parts of the image.
This may not work as intended as I don't have a working cooling. See below how to test.
6. Added min/max intensities, reading time and StdDev. Not sure if we should keep this information but at the moment it is useful for debugging.

Todo:
1. Option to chose between TEC on or TEC off during reading. This will require firmware modification and I did not get that far yet.
2. Option to switch between mono/colour sensor.
3. Have to look into our main settings window. We may be breaking ASCOM guidelines which clearly state:
Setup Dialog form is not the form with all the settings that automatically pops up. As far as I understand this means that the floating settings window is not allowed and that all settings should be in the other settings window (currently empty) that can be accessed when selecting the device. In other words, no changing of settings is possible while the imaging session is running. I will post a question in another thread to see how settings are set in commercial cameras.
4. Saving of settings - it does not work as I believe that the settings are in a wrong place (see point 3). We don't even have OK button on the current main settings form.

I have also uncovered a possible bug for which I may need Grim's help. I will post in the Ukrainian forums.
Gilles, if you are trying to include "reading time" in the indi driver, you have to set it before setting gain or offset as it messes with the gain and offset. My ASCOM drivers sets "reading time" first and things work but I do not know why and don't like it.

Nico, I removed the sensor clearing for the time being.


The driver is too large to attach here so it can be downloaded from here (https://drive.google.com/open?id=0B17xefQsw2ktNVV3TkpMX3FPOX M).
This ASCOM driver requires to flash firmware "cam86 prob2.hex", I have included it with the driver. The driver will not run with the initial old version of the firmware.

Source code will be released later, once the bugs are fixed and once Grim/Vakulenko let us know which license they would like to have.

Please test and pay attention to everything. And any other suggestions are welcome.

---------------
Cooling test:
It could be that the temperature is not being updated during imaging. Test if you can disconnect TEC power and keep camera running:
- let the temperature stabilise.
- start 1 minute exposure
- unplug cooling power
- watch the temperature and see if it changes
- see what happens with the temperature at the end of exposure

[N_DD]

Awesome Luka, thanks a lot!

I will test the ASCOM driver and let you know if I have any issues with it. I will also test the cooling.

Nico

[luka]

Great news, I managed to compile the original firmware for the ATMega328p and it seems to work!!!

Also Grim agreed to license his code as open source (GPL 2 or 3?). Gilles, what did Vakulenko say about licensing his code?

[gehelem]

Sergiy told me about ascom that we can publish it under free, non-commercial license.
Neither him nor Rome (Grim) said anything about wich gpl version we should use.
I've suggested gpl 2.1 because of libftdi and indilib, and Rome is ok with that

[luka]

Gilles, did you mean LGPL 2.1? I am not aware of GPL 2.1, only of GPL2 or GPL3.
The small problem with LGPL is that the source code can be used in proprietary programs, i.e. that someone could start commercially selling cameras using cam86 software/firmware. GPL does not allow this.

I started adding few more options to the driver but will wait for comments/bug reports before releasing the new version. It is not finished yet anyway... I also want to test the new firmware over a longer time.

[gehelem]

Ouch ! i must say i'm confused, i misunderstood the purpose of LGPL.
I've chosen this one because of Indilib, wich is using the same.
I understand in what you are saying that LPGL is not suitable for what Rome & Sergiy asked ! Argh...

But can we use pure GPL2/3 with d2xx and/or libftdi ???

That said, I think I have two options
- switch the cam86 library into a separate project published under GPL.
- ask Indilib maintainer his opinion regarding 3rdparty drivers

[luka]

A good reading why not LGPL is here (https://www.gnu.org/licenses/why-not-lgpl.html).

There is no problem of releasing "our" code as GPL on the top of LGPL libraries (libftdi and d2xx). As per LGPL, other portions of the project are permitted have other licenses, even being commercial.

But other way around, i.e. releasing LGPL code on the top GPL libraries would have not been possible. For example if libftdi or d2xx were GPL we would have to be GPL.

To summarise, releasing as GPL is fine, it will not break the LGPL license of libftdi and d2xx.

I will need to do more reading to remind myself what the difference was between GPL2 and GPL3...

[luka]

Finished soldering another Cam86, for my mono sensor. Working fine :D

[gehelem]

:thumbsup:
You're on everything at the same time ! Bravo !
What time is it for you now ?

[luka]

Just before 9pm. Thinking about testing it outdoors (no cooling so the images won't be that great...).

[luka]

Didn't get any feedback regarding the ASCOM driver so I assume it worked fine? It has been cloudy and rainy here for a few weeks now so I could not do anything outside.

I have uploaded the new version of the ASCOM driver (cam86_v0.3L_setup.exe) and the new firmware (cam86_fw_v0.2L.hex) to the folder on the GoogleDrive above. You will need this new firmware if you want to try this version of the ASCOM driver.

Changes:
- minor bug fixes
- option to have TEC on or off during reading of a frame
- mono sensor (unsure if this is ever used)
- version info for firmware, low level driver and ASCOM driver shown in the window

Again, I could not test anything related to TEC so comments are welcome. Or any ideas for new features...

[gehelem]

Sorry => on holidays atm
Will be back in 10 days
Gilles

[luka]

There are some news regarding cam90 (ICX493AQ sensor), Grim released the full pack for building, Gerbers, BOM, firmware, programmer and viewer. I put the files on our GoogleDrive.

Also found this thread (http://forum.astronomie.de/phpapps/ubbthreads/ubbthreads.php/topics/1216512/9) about Cam84/Cam86 build in German. Not much new there ATM.

[rsevs3]

Hi Guys,

Just signed up to the forum to say wow!

A very late night last night followed by total distraction this morning reading this thread instead of doing what i should have been doing. :D

I am new to astronomy and AP, just got my scope for chrissy, but AP is something I have wanted to do for as long as I can remember. Loving the DIY nature that a lot of people take.

I was thinking I was going to have to buy a cheap DSLR but maybe this is a better way to get into it. I dont want to have to modify my Sony a7 and getting adaptors etc has been a challenge.

Is there any chance of getting read access to the GD so I can see what parts I already have/need to order?

Keep up the great work guys!

[luka]

Hi Ryan, :welcome:

Sorry to "ruin" your evening and morning with this thread :rofl:
I remember getting similarly brain-stuck for several nights with a 90-ish page long thread about debayering the DSLR sensors.

AP has a very, very, very, very steep learning curve. The camera is only a small part of the whole picture, which also includes the mount, the scope, dark skies etc. For beginners DSLR is usually recommended as it is much easier to master, while you learn to know your mount, polar alignment etc. But soon you will be longing for more and this project offers a relatively cheap way to jump straight into CCD imaging. If it is a smart step, not sure, that will depend on you. For example, you could just get a t-adapter for your DSLR and start with that... while building this camera :lol:
(You can post a question in beginners threads regarding the adapter for your DSLR).

Can you answer few questions which will help us give you a better advice:
What scope/mount do you have?
Where in Perth are you (how far from CBD)?
The project requires good DIY skills. How good are your with soldering SMD parts? (If you decide to do the build I could help with the difficult SMD parts, if required.)
Also the camera housing will require machining. The G106 housing can be purchased from Jaycar/Altronics but requires modification, especially for cooling.

If you PM me your email address and I'll give you access to the GD files.

Luka

[rsevs3]

Thanks Luka,

All of astronomy/AP has been a big learning curve, but man I have been loving it.

I agree about having another means of AP while i build something like this, I might get a webcam just to get me going, but I know full well I will quickly be longing for more than a webcam. I figure if I am going to drop some cash, I might as well get the best bang for buck that I can. Plus I am a sucker for DIY...

Scope is a SW 150/750 mounted on a EQ3 with tracking motors. I realise this mount is no good for long exposures, but one step at a time.

I am in the hills, in the Armadale area.

As far as the electronics go, I have been building/playing with them for many years including designing/making my own boards. Nothing at the level you guys are doing for board design though. Its been a while, but it is faster to refresh memory than to start from fresh. I should have most of the gear for building/testing my boards (soldering/rework station, variable psu, o-scope etc)

For the case, I dont think I will have too many issues. I have a small CNC router, have access to a lathe and mill and also access to a manufacturing shop through a mates business.

Hopefully I can be some help, but it could take a while to get up to speed on the camera and the AP thing in general. I will probably try to join a club or something to reduce the learning curve somewhat.

[N_DD]

Hi luka,

sorry for the delay, I still didn't manage to upload the firmware and test your ASCOM driver (my 2 y. o. son decided to bring home a nice collection of viruses from the kindergarten!!!). How can I get access to the Google drive folder?

Nico

[luka]

Nico, hopefully things will get better soon. I know the feeling when kids bring all kind of sicknesses home. Luckily it is summer here so we are in the clear for a bit longer.
Do you have access to the whole Google drive folder? If not can you PM me your email address. The drive has all documentation about cam86 (and cam90) and the source code, also with my modifications.
Alternatively few posts above I posted an open link to a folder with the latest ASCOM drivers and firmware. This should be accessible by everybody.


Ryan, welcome to the club of DIY addicts :D
Sorry for the very short PM today but I had to rush out. You should have the access to our GD by now. The BOM file should have all the components listed and the Eagle CAD should have the build files.

It looks like you are very well geared up for building the electronics. I have few spare cam86 PCBs so you can have one if you want. Also there is a difficult to solder FTDI chip in LQFP-64 package. Let me know if you need help with this as I can solder it under a stereoscope. Otherwise you will need a magnifier of some sort to do it properly.
And for the machining of the case, clearly it should not be a problem for you. My resources for this are very limited (hand drill, hammer and few screwdrivers :lol:) but some very nice people from IIS are helping me with the case.

One thing to keep in mind is that the Ukrainians have just released the build files for Cam90. It is very similar to Cam86 but with a 10Mpixel sensor (ICX493AQA instead of ICX453AQA). I am not sure about the noise levels but you may want to consider building this one instead of Cam86. Actually if you are considering Cam90 then I would advise waiting few weeks for the issues to be ironed out before starting. And few of us may do the build as well, not sure. The advantage is really only in megapixels which is not that important for AP.

Also few of us were (loudly) thinking of building Cam10 which is a guide cam. But this has not gone anywhere yet. Cam10 is much simpler than Cam86.

(Hope I did not scare you with all the different builds ;))

Regarding your gear, not all webcams are made equal for AP but the good ones are not cheap (I am not very knowledgeable on this). It may be easier and cheaper to mount your existing DSLR onto the scope, not sure. Nikon/Canon adapters can be easily bought for <$50, not sure about Sony. Webcam would be more suitable for planetary imaging... what is actually your AP interest (planetary, DSO)? You should have much darker skies than me (<5km from city).

Your mount will limit the exposure time but even then building this CCD will significantly reduce the noise (as it is cooled) compared to a DSLR. Also the unmodified DSLRs block a significant proportion of Ha which is not the case for us.

[rsevs3]

Thanks Luka. I was flicking through the GD yesterday.

I would be keen to grab a spare board if there are a few, saves having to get another batch made up. Unless there is enough interest to get another batch made with any revisions since the last lot was made.

Help would most definitely be welcome for the FTDI chip. I have one of those magnifying lights, but experience and the right equipment can make life a lot easier. I am sure some kind of beverage could be supplied to say :thanx:

I had a quick look at the BOM, I was hoping to have more of the parts but it looks like I might only have some of the passives. Better some than none I suppose. I might start a spreadsheet on the drive to track what I need and if anyone down under needs some more parts can chuck them on that order (within reason of course :rofl: )

I think I might go for a Cam86. It will give me a chance to get up to speed with you guys, get some experience with this kind of thing (my last CCD project was a failure). A Cam10 would be sweet as well, but i have to make a start on Cam86 before I worry about that.

My AP interests are everything that is in the sky, but I suspect that like most, I'm guessing, DSO will be the majority. There is just so much too see. I spoke to the place that my scope was purchased from to get the e-mount adaptor and they were going to have to start calling all their supplies. Im sure I could find one online but I have a webcam lying around that I dont use, so I started butchering that up last night just to get me started.

Last night while I was playing around with my webcam I had my first experience with dew. Got me thinking, the TEC for the CCD is a decent heat source. Would that have enough heat on the hot side to be used as a dew heater? I was thinking if it was water cooled with the scope as the heat sink. A closed loop water circuit that is bled up properly might not even need a pump, just convection could be enough to get the required flow. I have to stop getting ahead of myself. :P

Being so close to the city, it would be easy to get some viewing in and the go enjoy the nightlife. If you find yourself wanting some darker skies, hit me up and we can go explore the hills to find somewhere good.

[luka]

Hi Ryan,

You can have a spare board, no problems.

If anyone else is interested in doing the build please let me know now as there may be more spare boards.

There are two small issues with this PCB and both can be easily overcome:
- One capacitor is not in the right place and that this is causing noise. This was solved by scraping off the soldermask from one track and soldering the capacitor onto the scraped section, to move it. Not a big issue.
- Somehow the silkscreen only partially got printed on the boards so you will need to have a paper printout while soldering to see which part goes where.
Definitely not worth redoing the PCBs because of this.

I can also help you with some capacitors/resistors. Some cost only few cent but they are sold only in bulk packs, for example in packs of 100. This makes the cost per unit expensive (few $) when you really need only one or two. And there are several parts like this so it does add up quickly.

My BOM should be a good starting point and it has Element14 and RS components part numbers for most of parts. The stock levels are not accurate but you should be able to see what I have bought in bulk packs (marked in orange). Some parts have to be bough on ebay and it may take several weeks to arrive. The sensor comes from a donor Nikon D40, D50, D70 or D70s (not D40x!!!). Broken cameras on ebay can be bought quite cheaply if you are patient and the sensors from those cameras are usually fine.

Also consider getting spare parts (I got spares for the cheaper parts). For example, cam90 uses most of the same parts so if we ever go that way...

Did you buy your scope in Perth from a proper astro shop? If yes, which one? All the stores I know of are in the Eastern states so anything local certainly may have advantages.

Regarding using the heat from TEC to deal with dew, there are two main issues. One is the extra weight and the other one is the rigidity of the pipes. Also you get no dew control if you are not running the camera. Furthermore, without a pump there may not be enough cooling for the camera. Glen (glend from IIS) experimented with water cooling for his cold finger modded DSLR (with pump on the ground) and found out that the pipes are quite difficult to deal with.

The usual way to deal with the dew are heating tapes. I made mine with Nichrome wire (Jaycar stocks them) and duct tape. Resistor ladder is another way. There are plenty of recipes on google and they are really easy to make. There are also lots of ways to build a power supply, check the DIY forums on IIS. Mine is roughly based on Chris' idea from here (http://www.iceinspace.com.au/forum/showthread.php?t=144679). There are lots and lots of options, again, google is your friend. You could also get a cheap adjustable power supply and manually control the heating power.
But really the last few nights were quite extreme in humidity. Usually in summer there is hardly ever any dew here in Perth but you will need definitely something for the winter.
Another DIY project for you :lol:

Unfortunately there is no good viewing so close to the city as there is too much light pollution. Part of my motivation for this build is narrowband imaging which can be done from light-polluted areas. I'll definitely take you up on the offer to find darker skies but will need to sort out few issues with my mount. Also ATM I am using mains power in my backyard but moving to a darker skies will require portable power source of some sort. You will eventually also need something, for the camera and for the heating tapes to start with.


Again, if anyone else is interested in doing the build please let me know now as there may be more spare boards.

[rsevs3]

Thanks Luka, I will take you up on the bulk items. Plus it will help to reduce your cost/board. Win win.

I have just ordered the parts that you have listed as a ebay purchase (camera sensor and vertical driver), I should have those parts in the next couple of weeks. While I dont expect to be ready, I will potentially be in some fairly dark skies at the end of March and I would be annoyed if I was waiting on one part to be shipped.

I will just use your BOM and add a column for my own stock. Thats the plan anyway. Just have to pull my finger out and do a stock take on what i have here. :rolleyes: I know I have a lot of the caps/resistors in the correct package sizes, I just have to confirm that they are the correct spec.

I got my scope from over east. I have not yet found anywhere locally that stocks much for scopes.

My thoughts with the dew control was to not have anything down to the ground but use a jacket around the scope with the flex water pipes zig zagging inside. Just an idea and wildly speculative on whether to would do anything at all. I will have a play around when I get something that moves some heat :) Good point about when the camera isnt in use, but you could still use a normal one during those short periods or when you are observing. I was just thinking more to try and reduce the portable power supply requirements.

There are so many things you can do DIY if you are so inclined. I have already been mulling over making my own mount... The hardest part is doing something to completion!

WRT portable power to go observing in the hills, I have 3 x 125AH (from memory) UPS batteries sitting here that you are welcome to use for the night. If you need more power than that then you had best buy a really long extension lead :lol:

[N_DD]

Hi luka,

thanks, my son recovered now, but I am really looking forward for the spring to come!

I managed to flash the camera and test your ASCOM driver using APT: everything works, including the temperature controller. I have uploaded two 1s darks, this (https://my.pcloud.com/publink/show?code=XZTApdZEPuPGiWf7dRcdV9Yy1 yHHfyyyNCy) one with maximum read speed, while this (https://my.pcloud.com/publink/show?code=XZ1NpdZ8FlbqNdY5VzJh4sszA hWjjPo0YHX) one with slowest reading speed. No substantial difference in StdDev, so I think I will stay with fastest download speed for now.

Let me know when you can implement the "double reading" for getting rid of the charge accumulation!

Thanks,

Nico

[luka]

Ryan, regarding the end of March, you will be cutting it very close to have it completed. You can probably get the parts in and the electronics working, however the housing will require lots of thought to implement. The G106 case has to be modified and adapters made to fit the focuser. Also the case has to be hermetically sealed to keep moisture out. Our plan is to use silica gel inside to trap moisture and also to fill the case with dry gas (argon for example) before closing it. That will prevent condensation on the cold finger/sensor which will be at sub-zero temperatures.

The TEC we are using is TEC2-19003, from ebay as well. I waited over 4 weeks for mine, stuff from China usually takes 4-6 weeks. By the way, I have just uploaded a new BOM with the TEC model (last line of the file).

I do have a 3D printer and have printed myself a very simple housing which works fine but the sensor is not cooled. It also leaks light through as I only had red filament so I used black electrical tape around it. Enough to play around but with cooling the camera will go to the next level. If you finish electronics before your trip I could print one housing for you as well.

And regarding finishing DIY projects, see my post here (http://www.iceinspace.com.au/forum/showthread.php?t=153591).

Are the UPS batteries 12V?

[luka]

Hi Nico,
Thank you for testing the driver. Did you test the latest one (v0.3L driver and v0.2L firmware)?

Slowing down the speed of reading is useful if you see image corruption, for example horizontal or vertical lines in images. Some people have them and some don't. It is related to computer not reading data fast enough, however, it is not linked to the CPU speed, i.e. even new computers can have the problem.
If it works, keep the fastest reading speed. But make sure you check the images again if you change computers.

I did have the bias-before-image (probably) working but could not reproduce the problem here so I removed it from the driver. It should be easy to put back. I'll try to do it tomorrow.

Luka

[rsevs3]

Yeah I dont expect to have it finished, certainly not cooled or anything. I would be pretty happy if it was at the point that I could play around with it. Having said that, once I have seen a board and can more properly visualise the housing, I think I can design something fairly quickly.

I have a couple of TECs ordered too now.

I had read your warning the other day, a very lucky escape.

Yes, the batteries are 12v. I use them for power backup for my aquarium, but they are not being used while I adding the new aquarium. More DIY :shrug:

[N_DD]

Hi luka,

yes, I tried the latest firmware and ASOM driver, downloaded from the open link you shared few messages before.
Thanks, I will try the clearing option if you put it back. Hopefully there will be some clear night and I hope I can test it in the field!

Nico

[luka]

Hi Nico,

Sorry that it took so long but I had a food poisoning :(

I have modified the ASCOM driver to clear the sensor via a bias shot before exposures. In the settings there is a text box that you can enter time into. If the exposure is longer than this time then the bias will be taken (and discarded) before the exposure. This takes about 1.6s extra. The firmware may be able to do it faster but I still have not figured out the details how it actually works so at the moment we are just taking a 2x binned image before the real image. Binned so that the reading is faster.

For example, if you take 1s exposure and:
- the text box has >=2 then the total imaging time will be about 3s.
- the text box has 0s then the total imaging time will be about 5s.
The real duration of the exposure is shown in the bottom of the settings window.

Note that I could not test this as my cam86 does not seem to show the problem. The cam86 firmware actually does some sort of clearing of the sensor before every exposure but as Grim commented long time ago, it may not work too well. I am not sure why I don't see the issue.

Can you try and see how you go. It is hard to make any changes without being able to test anything. The new driver (cam86_v0.4L_setup.exe) is in the same folder as the old drivers. The firmware is the same as before.

Luka

[N_DD]

Hi luka,

sorry to hear that, hope you recovered and that you didn't have too many troubles... food poisoning can be really annoying!

Thanks for the new ASCOM driver: I have installed it and everything seems fine. I will test the image clearing when I get a clear night: I found it difficult to clearly see any difference indoor, but on real targets I was seeing a lot of artifacts due to charge accumulation (like lots of star trails as a result of the previous slew!). I will let you know.
Meanwhile I am upgrading the TEC with a two-stages element, let's see if I can cool more efficiently the chip...

Thanks again,

Nico

[luka]

Thanks Nico, I am 99% recovered. I should have know better than to eat food from university cafeteria during holidays, who knows how old it was :mad2:

I never tested the effect of the charge accumulation outside. We have a clear night tonight and I am just setting up for some DSLR imaging. If the mount plays along I will test my cam86 as well.

[luka]

Nico, I did not manage to see the effect of the charge accumulation.
1. I tried slewing (west to avoid trailing due to backlash in the mount), stopping slewing and then taking an image. Could not see any trailing.
2. I also tried shining a torch through the telescope, removing the torch and taking image - again no difference.

Now, at the moment my camera is not cooled - could this be the reason I don't see the effect? How big is the effect? What is the best way to observe this?

[pat30]

Luka, I have been absent for a while (traveling to the north country to see the aurorae )
I want to try your driver but I can not install it, the box opens again with gain and offset not the rest and In the choice it remains displayed in V1,while I deleted the old !!!! :shrug:

I am attaching a schematic of an improvement to be done to avoid the disconnections of the CAM86 with the recent computers (win 10) we owe this trick to George a French constructor.
http://www.webastro.net/upload/minimages/30683-1487245087.jpg

Why my images do not appear on your forum?

[luka]

Hi Pat, welcome back. Hope you managed to see the aurorae.

Which filename was the driver you installed? On our Google Drive go to Luka_latest_ASCOM_driver and there you will find the driver called "cam86_v0.4L_setup.exe" and also the firmware called "cam86_fw_v0.2L.hex". That is the latest.
Sorry, I just realised there is also a folder called latest firmware which is probably where you are looking. Will sort the files out tomorrow, it is 2am here right now :D

With attaching of the images I usually click on the paperclip and in the new window click browse, pick an image and click upload. Once uploaded the image will be in the list in the window and then you can close the window.

I still do not have any cooling so I did not notice Win10 disconnecting from the camera.

Luka

[luka]

By the way, which debayering option do you use in APT?

The camera driver reports RGGB but in APT I get weird colours with this setting.

[pat30]

it's good:
Cam86_v0.4L_setup.exe and cam86_fw_v0.2L.hex that I installed but in the properties it remains in v0.1.

Yes I have seen auroras there are some pictures here (http://www.webastro.net/forum/showthread.php?t=145796), it is a magic show.

[pat30]

the matrix is GRGB

[luka]

Pat, can you try uninstalling the old driver first from the Windows control panel. Then install the new driver.

Also in APT hold shift while clicking to connect to the camera. This will bring the camera selection dialogue. Somehow there may be more than one version of the driver installed.

Thank you for confirming the Bayer matrix arrangement. The camera driver is reporting it incorrectly but I think APT does not use this information. That's why nobody else noticed it.
Will fix in the next release of the driver.

[luka]

Another thought, the drivers are usually installed in folder
C:\Program Files\Common Files\ASCOM\Camera
(Program Files x86 for the 64-bit systems).
There should be a subfolder Cam86. You can delete this folder and then reinstall the drivers.

And if all fails copy three dll files from the Google Drive/source code/luka/cam86_v0.4L/cam86/bin/Release/ to the folder Cam86 in the above folder with ASCOM drivers. That will overwrite the original files.
Probably restart the computer after this just to make sure the files are registered properly.

[pat30]

Nothing works, I do not have a file in ascom I made one with the DLL but it does not work.
I also supressed in the register!
I have windows starter

210489

210490

210491

[luka]

Hi Pat, I could not see GRGB in APT, only GRBG (or GBRG). Did you mean GRBG?


Also ignore my comment about the driver having incorrect Bayer sensor type. I tried fixing it and realised that ASCOM uses RGGB indicating a sensor with a Bayer matrix. It says nothing about the actual arrangement of the matrix.
(The other options are monochrome, colour, CMYG, CMYG2 and LRGB)

[luka]

Almost missed your post as you posted a minute before my post about the Bayer matrix.

Can you:
1. Uninstall the driver
2. Delete the C:\Program Files\Common Files\ASCOM\Camera\Cam86 folder from Program Files and see if you can connect to the camera.

[pat30]

I look tonight for the pilot ,.
For the matrix, there is the choice in APT GRGB.

We do not work with the complete matrix that's why I think there is a difference with the datasheet

[luka]

Pat, my APT does not have GRGB, see the attached image. By trial and error I found out that GRBG works, is this what you meant?

Also it is worth noting that GRBG works in DSS. Do not use Nikon D70 profile, Pat is correct to say that we are not using the whole sensor and that the datasheet does not apply any more.

Which stacking software do people use?

[pat30]

Yes, that's right, a thousand excuses for my error.
For stack, I use IRIS, I did not have good result with DSS ( it delete 1 color)
what is you result with DSS ? Not problem ?

[N_DD]

Hi luka,

hmm, I cannot reproduce the issue indoor... when I was observing this kind of "ghost images", my camera was powered using a battery and the input voltage could have gone below 12 V. Maybe the signla for clearing the CCD wasn't properly generated? I will try and power the camera with my battery this weekend and let you know. I will also try and find some images where the star trails from the slew were evident, but I am not sure that I have kept them.
I can confirm that the right pattern in APT is GRBG.

Nico

[pat30]

Luka, that was the problem, we had to delete the file Cam86 in common files :thumbsup:.

Thank you

[luka]

Patrice, that is great news. By the way, did you ever see any effects of charge accumulation, like Nico has been mentioning?

Also I completely got put on the wrong track with the RGGB that was mentioned in the software source code and only last night I figured out that it did not mean that the matrix was RGGB :screwy:
So, while I had few nights of data (taken with uncooled cam86) I never managed to process anything properly because of the wrong Bayer matrix information. I just stacked data from Carina nebula with DSS and the resulting image is here (http://www.iceinspace.com.au/forum/showthread.php?t=153829). I did not spend much time on it but don't think I am missing any colours. I used the following options:
In RAW/FITS DDP Settings and then in FITS Files I ticked the Monochrome box on the top and then selected the camera as Generic GRBG. The transformation was left as bilinear.

Again, selecting D70 does not work.

[pat30]

Strange, I would stay with your DSS settings!

With the original driver, never artifact. I would test with your pilot.

Nico, please post 1 picture to see the problem.

[luka]

Regarding the Bayer matrix, we have a shift of 1 pixel in the Y-direction. The standard D70 sensor is
BG
GR
while we have
GR
BG
That is 1 pixel shift down (or up).

[luka]

Nico, if you still cannot reproduce the problem can you try going back to the original firmware/software and see if it appears there.

[luka]

For the local crowd, here (http://www.webastro.net/forum/showthread.php?t=141764&page=27) is the link to the French forum about Cam86 and here is the google translation (https://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.webastro.net%2Ff orum%2Fshowthread.php%3Ft%3D141764% 26page%3D27) of it. Several people there (including our Pat and Gilles) have built Cam86s and are discussing improvements to it.
Lots of useful info there. Great work :thumbsup:

[gehelem]

Yes, and we have just openned a new site to share all this information (searching on thses forums is not easy). Pat and I wrote several articles on our work.
It's in french, but any contribution is wellcomed :
https://www.diycam.fr/index.php/fr/
Gilles.

[luka]

I was already reading it in Google Translate Gilles. When I read your section about setting offset/gain I realised that I was doing it incorrectly. Thank you.

How much do gain/offset vary with the ambient temperature? Would, say, 5 degrees C make much difference?

[gehelem]

I don't know, I let Patrice answer you.:)

[pat30]

Luka, thanks for advertising!

I would detail a little more the article for the settings OFFSET and GAIN because it lacks explanations.
I have not yet made any real measurement of the increase of the Offset with the temperature but it is necessary to remember that all the commercial cameras are not adjustable and the manufacturers have factory values between 200 and 1500.
500 it's good !

I would take steps to put on the site!

[gehelem]

Open source world is marvelous :
i've added gtranslate module to our site, hope it'll help

[pat30]

With the bad weather this evening I tested the average values according to the temperature, contrary to what I thought, the variation is not huge, the curve (https://www.diycam.fr/index.php/fr/10-all/software/13-reglage-du-gain-et-offset) is even surprising, I let you judge for yourself !

I allow myself to put a test that I carried out on the cooling during the reading of the image.
The picture on the left shows a Bias,"cooling off" during playback and right "cooling on".

These are 2 Bias of 0.001 sec, the StdDev for the picture without is 14.86 and with 20.66.

It is recommended to turn off the TEC during playback, I will try to filter to see if this improves things.

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

[luka]

Pat, I saw the two bias images with cooling off/on yesterday and I am not sure what to make out of it :confused2:

The cooling stays on or off during the duration of the whole frame reading, it does not get switched. From that point of view there should be no noise.
Can you try using a different power supply? Perhaps when it is loaded (cooling on) it puts out more noise? Or can you ask someone else with a working cooling to do the same test and report.

Also there seems to be a pattern in the right image, which, again, I cannot explain :shrug: The frames are read line by line but the pattern seems to follow in rows as well. This would indicate that the sensor itself was affected by whatever the source of "noise" is.

Interesting...

[luka]

ASCOM compliance:

Guys, I will need some opinions on this as this is potentially a change in the workflow. At the moment our driver is not ASCOM compliant. The settings window that opens when you connect to the camera (in APT for example) should not exist.

At the moment:
1. Saving of settings does not work. They have to be reentered every time the imaging software is started.
2. ASCOM says that the driver must open only one window for settings. That window can be reached via options when connecting to the camera. At the moment it looks like in the attachment and does nothing useful unless you are debugging the software (the "Trace on" option).
3. As far as I can see, in the normal operation of the camera the settings are set once and probably never changed. There is no need to have this window open at all times.


I want to move all settings to the correct window.
With the change:
1. Settings will be automatically saved and restored when the imaging program is opened
2. We will be ASCOM compliant
3. We can use the Cam86_view software to setup the gain/offset etc. I can modify this software as well if people have ideas how to improve it.
4. The new settings window will not open automatically and will require few mouse clicks to get to, but in reality we should almost never need to get to it.

If you have an opinion about this please post here and let me know.

[N_DD]

Hi luka,

seems reasonable: usually you want to set the gain and offset once, then keep the settings for your camera. The only occasion one would need to change them is if bin 2x2 is used, but I am not sure if binning makes sense for a one-shoot color CCD.
BTW, what does "mono" means in your current ASCOM driver?

Nico

[luka]

Hi Nico,

Ticking the mono box makes the ASCOM driver report the camera sensor as mono to the imaging software. Few people have removed the Bayer matrix from their sensors so they are using a true mono camera. I have done this and have two cameras, one mono and one in colour.

However, I don't think the mono option does much at the moment:
1. All saved fits files contain raw data and have to be Debayered later for colour sensors. So it does not make any difference here.
2. In APT for image previews you can select if you want to use a mono sensor or not. So APT is not likely using the information from the driver anyway. However, the other imaging software may behave differently so the driver operation should be correct.
3. If the imaging software is using this information, it is likely to read it from the driver on startup. Ticking the box in the options after everything has started would likely not have any effect. Moving the options to where they belong, as I am proposing, would help with this.

[pat30]

After some research, it is my regulator for the TEC that is at the origin of the noise :(.

Luka, at home the parameters are well saved, I do not need to put them every time, still a strange thing :screwy:

[N_DD]

Hi luka,

thanks for the explanation.
I could not reproduce the issue even powering the camera with my field battery, so I assume it was either a temporary glitch, or something not camera related which I will need to investigate.
I have taken some test darks and biases, cooling my camera at 0 C, and the result can be found here (https://my.pcloud.com/publink/show?code=XZ28yqZk9zTqXTVI0JmeuB5II TKeXXjTWg7).
Now if I just had some clear sky...

[luka]

Nico, as a possible explanation, I saw star trails after doing exposure straight after slewing which were caused by backlash in the RA drive. It was visible only after slewing east as the motor had to catch up to the backlash. It was not visible after slewing west. Keep in mind that my mount is not that great...

Any objections to removing the option to do bias-before-exposure from the driver? It is probably just adding about 2s to each exposure without any effect. The sensor clearing in the firmware seems to be doing adequate job.

[N_DD]

Hi luka,

maybe you are right, although I am pretty sure I was seeing some very long trails...
If you don't mind, could you leave the option in the ASCOM driver? If one does not need it should just be left unchecked, I think it is not bothering too much...

Thanks,

Nicola

[luka]

Will do Nico. I will change the default exposure time before the function is activated from 10s to something large so it does not triggered unless people intentionally switch it on.

Ryan, how are you going with parts for your camera?

[pat30]

Luka, have you seen the latest firmware from Rome, the cooling starts at 60%, not at 0 as now so the cooling will be faster, I think this is very good option + support for humidity sensor !

On this subject, it is possible to have a setting for the power maximum of the TEC ?

[gehelem]

Hi
I made a quick test with dht22 : it seems ok
Don't know for 60% threshold as my tec is directly plugged on my power supply to make tests
Gilles

[luka]

One thing to note, ASCOM does not support the humidity sensors inside cameras so the humidity can be read only from the cam86_view software. There is nothing we can do as it is not part of the standard.

I will need to get the source code updates from Grim to add them to our firmware...

I found several bugs in our ASCOM driver, working on them. Binning is actually completely broken but luckily APT is "smart enough" to work around the bugs.

[rsevs3]

Still lurking, but nothing to contribute with you guys fault finding. Yet :thumbsup: I have been busy tying up a few loose ends on other projects before I dive into this one.

I have the ebay parts ordered. I had a D70 arrive yesterday, advertised as working condition but worn. So sensor should still be good. Will probably order another one or two, one for debayering and one for a oops situation.

I'm thinking I might just do a complete order of parts minus the bulk parts you have. The expensive parts it looks like I don't have any of the specific items. That way I can get the ball rolling without having to sort every single item I have. I have been slowly trying to enter them into partsbox.io (https://partsbox.io) to see if it is of use.

[luka]

I made some MAJOR changes to our ASCOM driver. Probably 1/3 of the driver code was modified in some way.
1. I fixed the binning bug. Binning never worked properly but whoever wrote APT was smart enough not to trust the driver and worked around it. Most likely nobody is using binning as they don't have mono sensors.

2. I moved all settings to an ASCOM compliant properties page.

3. I made the settings accessible from the imaging software via settings button (in APT look at bottom right corner). This will pop up a (limited) properties window similar to what we had, but done in a completely different way and ASCOM compliant.

4. Numerous ASCOM improvements and small bug fixes. Too many to list.

5. Finally, the ASCOM conformance checker passes with:
No errors, warnings or issues found: your driver passes ASCOM validation!!

Believe it or not, but the ASCOM simulator drivers do not pass the conformance checker without issues!!!


The new driver version 0.5L is in the usual spot and the source code is on our GD. No updates are needed to our firmware (Grim's new firmware will not work).

Note that Grim released a new firmware today which has humidity measurements and improved cooling. We don't have source code for this yet but once released I will combine Grim's and my improvements.


PLEASE TEST everything. This was a big change and I am finally close to being happy how things are done.
Let me know of any bugs or ideas for improvement.



Ryan, debayering will most lead to the oops situation ;)
If you want a good "several-nights-horror-reading" about debayering have a look here (https://stargazerslounge.com/topic/166334-debayering-a-dslrs-bayer-matrix/) :D

[pat30]

Luka,
On the new driver the speed control does not work, I have several images with adjustments on each side but it remains identical (see pictures)

210839

210840

Do others have the problem ?

[gehelem]

Hi, thank you very much Luka, great work !
I can't test with my actual setup, i'm in hardware ATM. I will test your driver ASAP.

I've added 2 articles on our site :

Influence of wiring on measurments (https://www.diycam.fr/index.php/fr/11-all/refroidissement/17-ds18b20-et-enroulement-des-cables-sur-le-doigt)
DHT22 setup (https://www.diycam.fr/index.php/fr/9-all/construction/18-cam86-ajouter-le-dht22)


Gilles.
(btw : what is your opinion of translation module i've added ? Is it usefull/accurate ?

[luka]

Patrice, thank you for doing the tests. I will fix the bug. Anything else you noticed?

Also Grim sent me the source code changes for the humidity and the improved cooling. I will incorporate the changes to our software. I also realised that we can display humidity in our settings window. Ascom/imaging software does not support it but we can display whatever we want in our window.

Grim also commented that 60% of cooling to start may be too strong for some cases. For example, if you want to go from 25C to 20C the temperature will go below 20C before recovering. I think I may have a smart solution for this...

I am expecting one more version to be released for testing and debugging and we will probably be ready to release the final version and the source code then


Gilles, I very much liked your article about the wiring. I never though the heat conduction in wires can have such effect. Very enlightening.

The translations work well, depending on the content but usually I can figure out what is going on. I noticed few interesting things:
1. The labels in images are of course not translated. Nothing can be done about this but it can make the understanding difficult at times. For example, I had to look at images to understand the difference between "cables pas enroulés" and "cables enroulés".
2. Different languages are translated differently. The German translation of the wiring article was better than English (or Croatian).

I also noticed a small "bug", clicking on flags to select a language does not refresh the language in the selection box. For example, pick French in the selection box and then click on the English flag. The whole page will be in English but the selection box will still show French. But otherwise, the translation is a very, very useful tool. Thank you for doing it.


I forgot to mention that the v0.5L of the driver has tooltips in settings. If you hover the mouse over a particular element it will tell you what its function is.

[pat30]

Nothing else, the rest works (about 500 Bias captured).


The faster cooling will be a good thing on my model 60% is well (you must try), I installed yesterday at the break of lunch for tested the Rome version.

[luka]

Working on the code now. I also want to make 60% adjustable so if people want to go from 25C to 20C they can reduce this number. Or cool down the camera starting with 100% if they desire...

Also I am thinking of removing the scroll-bars for offset/gain/reading time. Considering we already have the scroll boxes, the scroll bars don't really add much functionality but take up lots of space. Not sure.

[pat30]

error

[pat30]

Yes the scroll-bars do not serve, it takes too much room unnecessarily.

For the TEC the ideal would be to be able to regulate the starting power and the maximum power (I do not know if it is possible), like that, each person would make its adjustment according to its TEC.

Thank for you work.

[luka]

Brilliant idea Patrice, I will look into limiting the max cooling power as well. It seems possible...

This will be another major software change...

[pat30]

To go even further and have a much better cooling, it would also be necessary to add an adjustment for the frequency of the PWM because 1hz is too little and there are losses.
Normally a TEC should never operate at a frequency lower than 45hz.


I make the difficult :lol:

Sorry I do not know how to program, I looked at the source code to try to learn with my little notion of ARDUINO but I did not understand even the name of the exit doors :confused2:, so I only have the ideas .

[luka]

Hi Patrice,
Unfortunately the pulsing of the TEC is done as software loop with adjustable on/off switching and not as hardware PWM. I already had a look and it is not possible to convert it to hardware PWM as the pin B0 does not support PWM. So we are stuck with software on/off switching.

Now, while ATmega can probably handle the software switching frequency of 45Hz, I think that 45Hz is too low. The thermal stress on the TEC during the on/off switching is high and the PWM frequency should be faster than the TEC's thermal time constants. To avoid premature death most of places recommend PWM of at least 300Hz, some even suggest using between 5KHz to 40KHz.

Changing the timings of the loop is possible but it will have to wait because I don't even have a working cooling on my camera. Plenty of other things to fix at the moment :D

[pat30]

That's what it seemed to me, but I did not want to say nonsense, but we just have PB1 and PWM in it, but nothing urgent, being able to set the starting and maximum power will already be a Enormous advanced :thumbsup:

[luka]

Working on it, working on it. Have to completely change how settings form interacts with the main ASCOM driver... again.
It may be linked to the bug you found.

[gehelem]

Again... thank you !

[luka]

By the way, here (http://ascom-standards.org/Help/Platform/html/Properties_T_ASCOM_DeviceInterface_ ICameraV2.htm)is the description of the ASCOM camera interface. If you look carefuly you will notice that gain is supported but offset isn't. In other words, the imaging software (APT for example) can read/change the gain but not the offset. In principle APT should not be changing either of the two but if ASCOM provides gain, why not offset as well :screwy::confused2::shrug:

[luka]

Just letting you know that the driver won't be finished today. It is close but not there yet. Also the more I change the more I want to change :lol:
Time for :zzz:

[pat30]

It is true that I ask a lot .



No, defended to sleep, at work faster than that :computer: , it should have been finished yesterday :lol:

Joke of course !


I see that I am not alone to have ideas :lol:

[luka]

New driver is in the usual spot, version 0.6L and also the new firmware 0.3L.

Changes:
Humidity/dew point information (untested)
Option to enter TEC starting power and TEC max power (untested)
Warnings about possible condensation
Complete rework of how settings work behind the scenes
Added about box
Bug fixes etc...

As before I could not test anything that involves cooling, including any of the new options. I will leave that to the guys with working cooling.

I had a last-minute idea to add warnings when the sensor temperature gets close to the dew-point. There is a box on the top of the settings window without a label with "5" in it. That means that you will get a warning if the sensor temperature is less than 5 degrees above the dew point.
I will need to rework the interface to fit this and a label for it somewhere but not tonight, need to get some rest. Also this value is not getting stored if you close the program (yet), as I said, last minute addition.

So, can you please test everything, and especially things that involve cooling. Again, lots of things were changed so don't rely that anything that worked is still working.
:thanx:

I think we are close to the final version... hm, don't I say that with every new version :lol:

P.S. I rearranged files on our GD. Everything is still there but it may have been moved.

[pat30]

THANK YOU VERY MUCH luka :thumbsup: , I download and test tonight.

[luka]

Just to warn you to expect bugs :bashcomp:
TOO MANY things were changed not to have any

[pat30]

Luka, a first quick test shows some bug:
I do not have the DHT22 just 18bs20 but the temperature and humidity displays Hallucinating values and alert displays.
The Max setting of the TEC is not right there is an offset (set to 80%, stop at 82%)
The gain and offset settings are not backed up correctly after has reopened the box, error of 1 or 2 different, not always the same value (example setting gain 16 offset -17, after Reopening the dialog box gain 15 offset -15)

The departure of the TEC works well and read time also.
No OK button, is it normal?

Here is a first return I continue my search...

Screenshot with error here (https://drive.google.com/drive/folders/0B33NUzWf6odbT2tTbk9RSTZBTmM?usp=sh aring)


Edit: It seems that if you go through the properties before connecting the camera (shift-click) everything works correctly, the settings are saved, and there is the OK button going through there; The bugs are just going through the APT button setting.
The Min setting of the TEC is really useful, descent much faster :2thumbs:.


Great job Luka THANK YOU, THANK YOU, THANK YOU :party2:

About the cooling power setting, it acts on what in reality because it is not on the frequency and you said above that PB0 is just a switch ???

[luka]

Thank you for testing the driver Patrice. I have uploaded the new version, 0.6.1L. The firmware is the same, v0.3L.

I almost had a heart attack when I saw the list of bugs... luckily it was all caused by one problem which was copied and pasted to multiple places. Imagine holding the offset up button so offset goes from 0 to 127. As it increments by one, normally it would send 127 messages to the camera to increase the offset by one - slow and not very good. I had to slow them down using timers and there was a problem there. Of course the same code was reused for multiple parameters (gain, offset, reading time, cooler start and max, slow cooling setting and the condensation warning).

Here is what is going on, I should have probably explained this earlier:
- There is only one settings window now. The parts of the window get hidden, depending if it is opened from ASCOM properties or from the imaging software.
- The missing OK and cancel button when opened from APT is fine as they are not used.
- When opened from APT, the settings are updated "almost" immediately. I said "almost" because, for example, we don't want to change gain half-way through taking an image.
- The result of this is reduced imaging time per image by about 0.2s.
- Note that if you type any values into any of the input fields, you will need to press enter or to click somewhere else before taking a shot. To give an example, if you go to offset box and type 5 and then click "shoot" in APT, the Windows will first start the shooting and then immediately change the gain. The result is that the image will be taken with the old gain and then the next image will be taken with the new gain of 5. This is a Windows thing. You should enter 5 and then press enter and then click on "shoot". Alternatively using the up/down buttons, no enter is needed then.

New additions:
1. I made the software remember and restore the position of the settings (only if settings are opened from APT). I got annoyed with continuously having to move the window out of the way when it got opened.
2. I finished the condensation warning code so it checks for errors now. You should not see false warnings any more. I have also noticed that occasionally the humidity reading returns weird values, probably because we don't have the humidity sensor installed. Not sure.

By the way, the ROI (Region of interest) option in APT is working since I fixed the binning bug :)

Can you please check for bugs again and if it is working fine redistribute on the webastro so they can do more testing.
:thanx:

[pat30]

OK, I try again.
Maybe with the MAX setting of the TEC I can remove the regulator for it? How does PB0 work?

[pat30]

It looks good, I had a small problem with the cooling, the power dropped instead of rising but after I stopped and started again it works, so do not take it into account now.

I give on Webastro to know if someone can test with DHT22 otherwise I would put one.

Thanks again

[luka]

Ah, sorry I forgot to answer that. The TEC settings are percentages of full power. So if you set max to 80, the power will be limited to 80%.

Regarding the PB0, one loop = 1020ms. Within a loop the software:
1. calculates the cooling on and off times using a PID loop. Then
2. Sets PB0 = off
3. Waits the calculated off_time
4. Sets PB1 = on
5. Wats the on_time
repeat

For example, if the cooler is calculated to run at 50% the on_time and the off_time will be 1020ms/2 = 510ms.

Now, in theory we could reduce the time of 1020ms for one cycle to something smaller and this should increase the TEC switching frequency. In theory... but the resolution will suffer. For example reducing this 10x will only give us 10Hz and 100 step resolution. It may be possible to change delays to us... ask me once the main code is done ;)

edit: just saw your messages that arrived while I was typing my message. Regarding power going down, can you try to reproduce what you did when you got a moment and see if it happens again.

[gehelem]

thank you Luka
i can't make deep tests atm, it' my wife's birthday, 65/70 friends at home tonight...
Just a quick one :
i use Nebulosity, it claims the driver is incompatible :
http://www.webastro.net/constellia/image_pleine.php?photo=58347
Where is this log file located ?
But it works under APT :
http://www.webastro.net/constellia/image_pleine.php?photo=58348
I can't test cooler regulation, but DHT22 seems to give good results :-) (same reading under Camview)
Gilles.

[gehelem]

Ascom diagnostic tool :
09:17:10.963 FileDetails C:\Program Files (x86)\Common Files\ASCOM\Camera\Cam86\ASCOM.cam8 6.Camera.dll
09:17:10.963 FileDetails Assembly Version: ASCOM.cam86.Camera, Version=6.0.6272.26478, Culture=neutral, PublicKeyToken=null
09:17:10.963 FileDetails Assembly Framework: v2.0.50727
09:17:10.963 FileDetails File Version: 6.0.0.0
09:17:10.963 FileDetails Product Version: 6.0.0.0
09:17:10.963 FileDetails Description: ASCOM.cam86.Camera
09:17:10.963 FileDetails Company Name: The ASCOM Initiative
09:17:10.963 FileDetails Last Write Time: 04/03/2017 14:42:36
09:17:10.963 FileDetails Creation Time: 04/03/2017 09:01:55
09:17:10.963 FileDetails File Length: 322,048
09:17:10.963 FileDetails Attributes: Archive
09:17:10.979 FileDetails .NET Assembly: Not a valid PE executable
09:17:10.979
09:17:10.979 FileDetails C:\Program Files (x86)\Common Files\ASCOM\Camera\Cam86\cam86ll.dl l
09:17:10.979 FileDetails Assembly Version: Not an assembly
09:17:10.979 FileDetails Assembly Framework:
09:17:10.979 FileDetails File Version: 0.3.0.0
09:17:10.979 FileDetails Product Version: 0.3.0.0
09:17:10.979 FileDetails Description:
09:17:10.979 FileDetails Company Name:
09:17:10.979 FileDetails Last Write Time: 02/03/2017 22:08:52
09:17:10.979 FileDetails Creation Time: 04/03/2017 09:01:55
09:17:10.979 FileDetails File Length: 379,904
09:17:10.979 FileDetails Attributes: Archive
09:17:10.979 FileDetails .NET Assembly: False
09:17:10.979 FileDetails Bitness: Bits32
09:17:10.979 FileDetails Subsystem: WINDOWS_GUI

[luka]

Gilles, when selecting the driver can you go to properties and tick "Trace on". That will enable logging. The logs can be found in Documents/ASCOM folder.

:birthday: to your wife

[gehelem]

This button isn't enabled (see screenshot)
Impossible to find this "ascom application event log"
i've tried to tweak with "profile explorer" (set "True" to Trace under cam86 driver). Still no log file...

[luka]

Gilles, I had a trial version of Nebulosity 4.1 installed from long time ago and it connected to the camera and took preview images without issues.

Is your Nebulosity 64bit? I saw this on ASCOM FAQ page:

[pat30]

Luka, the problem is not reproduced despite my attempts.
I tried to remove my regulator, the result was not good so I reassembled it.
If you want to understand a little better my montage which is a bit special I put an article on the site (https://www.diycam.fr/index.php/fr/realisations/19-la-cam-de-patrice).

[luka]

I suppose that is good news, there is nothing to fix :D

Pat, hat is a very interesting design that you have :thumbsup:
We were considering a small dry chamber but you took that idea to a new level!!!

[pat30]

You did a great job, bravo and thank you again :thumbsup:.

For me, the dry room and the best solution, but I have to take a larger box to be able to put a larger heat sink.
I also think that adding a smaller Tec over the other would be a good thing but I do not find the right size, so I think I'll try as flolic to cut a TEC to the right size.

[luka]

Patrice, the stacked TEC must be matched, I am not sure how well the cutting will work. But it is worth a try.

Regarding a larger case, have you seen Hammond 1550Z111 (http://www.hammondmfg.com/1550Z.htm)? It has the same width and length but it is deeper than our case. Maybe you can fit a larger heatsink in it?

[pat30]

Yes I know this case, but I had already ordered the 106, before changing I want to know the price for a custom heat sink, I have to draw and provide the plans, I think start this next week, and the rest of the box can be ABS with the printer.

But I'm afraid of the price !:confused2:

You have news from Brendan ?

[luka]

Another day, another version of the driver :D

Version 0.6.3L, the firmware is the same as before 0.3L. In the usual spot.

Changes:
1. Exposures over 999s are possible now. This has turned out to be limit of the Windows timer. The original Ukrainian driver has the same limit of 999s.
2. Added option to open settings window automatically when the imaging software connects to the camera.
3. Fix bug in the humidity warning. Note that without the sensor every now and then I get a false reading of humidity which may trigger the warning.

I am close to being happy with this and have started preparing the code to be released as open source with GPL2 (or later) license.

[gehelem]

I'm very, very happy with my TEC2-19003.
For now, i can reach DT -45 under 12V/2.5A
But i need to make a joke.
<joke>
Make a search on eBay with TEC2-19003.
9/10 of sellers are downunders.
Why ? Why do usually people have to use good TECs ? To refresh Beer !
</joke>

EDIT : Thx Luka for the new driver. I will test it this week end
Gilles.

[wasyoungonce]

Hi Pat

Yes I'm alive. Had to send some PCBs to Luka as I had real difficulties soldering the LQFP 64 FTDI IC. I managed one but buggered next 2 so I gave up and sent them as he has a stereo microscope "AMScope". I'll populate the other ICs....big of me ...I know!;)

You can guess what my next big buy!

Just consolidating parts atm...did another last big buy from element14. I keep changing suppliers as their parts appear to increase everytime I order them or they become popular.

For Luka...have you ordered from Xon (http://www.x-on.com.au/)? I have previously but they appear to have increased their stock list and some prices appear good.

[luka]

Gilles, while we have lots of TEC2-19003 here, unfortunately there is not much else to chose from. When I was looking at options for Cam86 there was only one other contender... and it was not even double-stacked.

And we don't need all those TEC to cool the beer, we need them to cool ourselves :P
The guys on the east coast had a killer summer, breaking all the records. And we in Perth had a semi-winter this summer with lots of rain. Crazy :shrug:


Brendan, never heard of XON before. Thanks for the tip, will investigate.
Soldered boards and 2 connector sets will be posted within next hour, I'll email you when done.

[pat30]

Hi Brendan, glad to hear from you.
A real dirt this FTDI !

Luka, as soon as possible I try the new driver, not possible now, last weekend I have edit the box I cut my finger with a saw, so the Cam is open on the table, I hope to be able to go up In the coming days.

[luka]

The latest driver 0.6.3L is broken, do not use. Will release the fix later tonight.

[gehelem]

I'm doing my first cooling tests with it at the moment !...
No problem...

[luka]

There is a bug with calculating the exposure duration. I think that only exposures over 900s are affected but I am not 100% sure that it won't cause problems for shorter exposures. Hence the warning. It is OK for testing but I would not trust it under stars.

I am just testing the fix... Debugging/testing exposures >1000s takes a long time :(

[gehelem]

Again, a good TEC can be accompanied by a good beer! Cheers !
http://www.webastro.net/upload/minimages/30193-1489247718.jpg (http://www.webastro.net/upload/images/30193-1489247718.jpg)
-10°C like a charm

[luka]

Gilles, enjoy your beer and the new driver, 0.6.4L. No change in the firmware.

I (hopefully) properly fixed the long exposures issue (>999s) and also fixed a small bug related to the dew warnings.

The driver is also being tested by Grim and Faddy who noticed the long exposure problem.

[gehelem]

Thx again

[gehelem]

Luka : did functions dialogs with firmware change ?? How do you manage "power %" and dht22 reading calls ?
I'm in Indi mood now that my cooling hardware seems to work ...
EDIT : Ok, cam86.dll contains a lot of new features... i need to be more patient...
EDIT2 : Sorry, i didn't noticed some parts of your source on GD, i will check that

[luka]

Gilles, see the folder source code/luka.
Cam86_fw is the firmware and that has all the commands. In particular the "set commands" are in the function interrupt at the beginning of the file while the "read commands" are at the end of the file in function resi.

Cam86ll is the low level driver while cam86 is the high level ascom driver.

[luka]

My fingers are itching to add more options to the driver so I have been thinking and thinking... Considering that everybody is using different cooling (different size of cold finger, different TEC and heatsink), the parameters used for the PID loop will definitely not be optimised for everybody's camera.

Is it worth making these parameters adjustable so people can determine the optimum values for themselves?

The danger is that lots of people will not know how to tune PID loops. Bad parameters can lead to oscillatory or unstable behaviour of the temperature. But tuning them properly can lead to faster cooldown and less or no over/undershooting of the temperature.

Also note that we are only using the proportional part of the PID loop with the constant Kp set to 0.04 - this is the only variable than can be tuned. Higher values will make the temperature control more aggressive but it may never settle.

I have a feeling that I am opening a can of worms here :shrug:

[pat30]

Luka you make me laugh, a few days ago when I talked about it you told me that it was a lot of work and today you want to do it :lol:

Personally I think it would be a very good thing, the PID settings are well documented for the settings so those who want can find it easily on the web.

A few months ago I had spoken to him at Vakula and he had said the same thing as you; I do not know the work that it represents but there is the autotune that would make the adjustments automatically, after it is easy for me to say it because I do not know how to do :(.

[rsevs3]

I just got home from work and this mountain of goodies has been delivered over the last week! :)

Just need to organise some boards from Luka and we will be under construction.

[luka]

Back in town.

Pat, I can make the Kp parameter adjustable but the PID autotuning in the firmware will be difficult. Also we are not using the full PID but only the P (proportional) part and the standard autotune code won't work.

I will investigate doing autotuning from the PC, it may be easier. Or perhaps also adding the integral part? Can't see much advantage in doing this though as proportional seems to do the job well.


Few clarifications about the firmware:
1. My firmware is backwards compatible with the old versions of the viewer or the ASCOM driver. I only added new options but did not modify any of the old code (apart from the cooling).
2. Original Grim's firmware will NOT work with the new ASCOM driver as it is missing all the additions.

When I get free time I will put the driver on the Github and post on the Ukrainian forums. Grim/Faddy did not comment about any more bugs so I think we are ready.

[luka]

New firmware (0.4L) and driver (0.6.5L) are out in the usual spot.

I have added the option to adjust the Kp, the proportional gain of the PID loop. As I don't have any cooling the driver is experimental and untested.

Pat and Gilles, if your cameras are working can you test the firmware/driver. You will need to:
1. Set the starting cooling power to zero and start the cooling. Record the time profile of the temperature going down. You don't need to go very low in temperature, 10-15 degrees lower than the ambient temperature is probably enough to test the driver.
2. Let the camera warm up.
3. Modify the Kp parameter and redo the test.
Default Kp is 0.04, try setting it to 0.1 or even larger. Note that if the temperature oscillates and goes crazy you have gone too high.
Please monitor the temperature at all times during the test, the driver is experimental.

With a larger Kp the temperature should go down quicker.

Regarding the tuning of Kp, the usual guide is to keep increasing it until you see oscillations. Then halve the value and that's it. There is lots of material on Google about tuning the PID loops. Again note that we only have the proportional term.

[gehelem]

Okay i will try tonight
I've made tests today....into my fridge...
I went down to -42 on ccd side, so I'm not afraid :)

2 other things :
-I went back to linux driver, a few new things start to work
-I will have a thermal camera during one week. I'm just beginning to play with it, but i'm sure it will give us interesting informations. I you have any suggestions to make test, plz tell me....

[pat30]

Luka, the driver does not work at home, see the error message in picture.
211500

[gehelem]

I have a problem, the same when i use Nebulosity (see attachment)
=> Rollback to previous firmware and driver...

EDIT : after rollback to driver 6.4, i have the same problem
Some kind of configuration/profile not properly removed, or something ?

[luka]

Few times I noticed that the uninstall of the old driver does not work properly and that the upgrade may fail.

Can you go to folder
C:\Program Files\Common Files\ASCOM\Camera\Cam86
and check the timestamps of ASCOM.cam86.Camera.dll and of cam86ll.dll
and let me know. I can compare and try to see what went wrong.

Can you then try deleting all files from
C:\Program Files\Common Files\ASCOM\Camera\Cam86
folder and then reinstalling the new driver.

[gehelem]

I've uninstalled every camxx driver (i had cam84 too) with windows program manager.
I've checked C:\Program Files (x86)\Common Files\ASCOM\Camera
It was empty.
Then I've installed again new cam86 driver.
(See attachment for timestamps)
Still KO

[gehelem]

I've noticed my ascom version is 6.1 : i'im trying to update

[luka]

Thanks Gilles, I was just testing it here (with ASCOM 6.3) and it works fine.

(I also found and fixed two little bugs in night colour mode)

[gehelem]

an idea :
Now i'm on ascom 6.3, and i get the same message than Pat.
Reading the message, it looks like a conversion problem...
One though : here in France we use decimal separator "," instead of "."...
This is often a problem when formating strings.
I think there's a windows parameter to play with it, will check.

[luka]

I think you are on the right track...
Can you run the ASCOM profile explorer and go to camera-cam86 section and post a screenshot that shows the settings

[gehelem]

TADAAA !
That's it : regional parameters, we need to change decimal separator
Will inform Pat

=> Starting tests

[luka]

Gilles, in the ASCOM profile explorer, in cam86view section, can you change the KP parameter from 0.04 to 0,04 and then try the driver.

[luka]

Ah, we posted at the same time. I will fix this later today. let's see first how you go with the tests.

The problem is that the default value gets initialised as a string, I.e. as "0.04" and later it fails to convert to double.

[gehelem]

See attachment below
Playing with windows regional parameters works, but if there's a way to tweak that only for ascom it would be great

[gehelem]

Yep, first things first.
Now cooling target 5°C Kp = 0.1

[gehelem]

i think i make things the wrong way :
I use "cooling aid" of APT, but i'm sure it interferes with pid regulation during first minutes.

[luka]

To be honest I don't know. I did not even know that APT has all those cooling options and graphs, thank you for the screenshot above. I am liking the software more and more.

Is it possible just to switch the cooling on and to manually record the values over few minutes. I don't think you need many points to see if there is a difference.

edit: I think I have already fixed the internationalisation bug. If you want I can send the update now or we can do it later, after your tests.

[pat30]

Luka, I had some bugs with the new firmware, sometimes the temperature displays 85 °, Gilles you have the same?

[luka]

Pat, on which sensor do you see 85 degrees C? The humidity sensor or the cold finger sensor?
How often do you see the reading?
Did you have issues with the old firmware/driver?

Can you disconnect from the camera, then hold shift while connecting in APT and when choosing the camera go to properties and tick "Trace on". That will enable logging. The logs will be saved in Documents/ASCOM folder. Seeing the log when the temperature is not correct may give me a clue...


edit: also does the temperature stay at 85C or does it only show 85C for a second and then go down again?

[gehelem]

i also get sometimes silly readings on CCD temps (eg +60C) but on next measurment it comes back...
Trace on activated, will keep you informed
Edit : btw : Kp = 0.04 seems to be good enough ! my first impression is that when I change it + it gives oscillations and - it 's very long to reach target...

[gehelem]

second impression :
even with 0.04 it overshoots.
But i think it needs really fine tunning, and this Kp seems to work quite well...

[gehelem]

See here, after 10 mn and kp=0.04 target =-5°C, but went down to -9
Cooling power still 84%

[luka]

Gilles, the 0.04 value was used in all previous drivers/firmwares. If you are getting a different result now then we have a problem.

I have uploaded a slightly modified version of cam86_view program to the usual place.
You can set the Kp parameter there (change the value in the box and click the button).
If you tick the box "auto temp" (after connecting to the camera) the driver will measure temperature every second and output the value in the info box.

This may help with the testing.

Also if you use this version of cam86_view, can you watch and see if you get temperature glitches.

[gehelem]

Thanks
Don't worry : i had overshoots before too, and i played with cooling power min/max.
Now this is much better, but it will be very long to find good values !
I will play with your new soft in a few hours, need to clean the house atm...
Have a look at this :
http://www.webastro.net/upload/minimages/30193-1489834743.jpg (http://www.webastro.net/upload/images/30193-1489834743.jpg)

[luka]

I have seen the image already, I am closely following the webastro forum. Lots of interesting stuff happening there :thumbsup:

My changes to the viewer software are really only useful for this test. It was a quick fix and there is no error checking at all for the parameters. But it can be useful to see if you get temperature glitches as well. If you could just run the "auto temp" option and leave it for a while and then copy/paste the temperature output, I could see if there are any glitches there as well.
The viewer is not using the ASCOM driver so it is different.

But I have a feeling that the temperature glitches are caused by the noise from TEC. Did you have the temperature glitches before this driver/firmware?

[gehelem]

Ok, test running
This version could be a good tool to tune parameters easier, if the log could mention everything on the same line :
timestamp

Timestamp
Target T°
T°CCD
Cooler On/Off
Cooler%
Coolermin/max
T°DHT
H%DHT
...

I think i can do it, can your share this code ?

Edit :
"Did you have the temperature glitches before this driver/firmware?" Yes i did

[pat30]

Luka, the 85 ° remained a few seconds, it is the 18bs20 probe, as Gilles the 0.04 works well but it is much longer than before.
It seems to me that I had activated the "trace on", or it finds the newspaper to be sure.

Another thing, since you look at Webastro, you can come and make a little hello there :thumbsup:

[luka]

Gilles, I finished parts of your request, see the new viewer in the GD (same revision number). Missing are cooler min and max which need to be added to the cam_view code. The data is currently dumped into the text box with comma separated columns so you can copy/paste into notepad and save as CSV, which can then be imported into a spreadsheet for plotting etc. I am thinking of making logging data go into a file but this will have to wait until tomorrow, too tired now, it was a BUSY day. All source code is in source code/luka folder.
I never developed in Delphi before Cam86 so making any changes is slow.

Also I have uploaded the new driver, v0.6.6L. This should (hopefully) fix the internationalisation issue with , or . for numbers. Can you please test.

Pat, the old cam used the same value of 0.04. If it is slower now then I have stuffed up something. Will need to investigate...

:zzz2:

[gehelem]

Great, thank you very much
New Ascom driver is ok with international stuff

Now playing with camview

[gehelem]

Hi Luka,
it's now late also here in France, but i want to share this with you :
Thanks to your code i've started to write a new tool to tune parameters of regulation.
This is early code, just to show how to use cam86ll.dll in delphi
(i've just put it on GD\incoming)
That prevents to rewrite low level functions, it's just fast Delphi coding.
With it I intend to log all parameters in a grid, easier to export in Excel
Maybe i'll try to add live graph, or job sequence, like "play with Kp=0.01 during 15mn then stop cooling until DHT temp = CCD temp, then restart cooling during 20mn with Kp=0.02", and so on

Just to say I think i can do that, don't spend time on it : on your side stay on difficult stuff, you've already made so much !

Gilles.

[luka]

Can't see any files in incoming.

Are you using my cam86ll.dll? That has functions to access all the firmware new options.

[gehelem]

Bizarre. Some kind of google magic....
I can send it by mail if you prefer...

Yes : it uses the dll provided in ascom driver
Just a copy/paste into folder, this is what i wanted to show you

[luka]

Gilles, I am interested to see why the uploads does not work. I put a test.txt file in the folder. Can you see it?

Using the DLL is a great idea. Do you want me to add other functions to it or to the firmware? For example, some parameters can be only set but not read.

[gehelem]

Yes i can see it (empty text file)
I think the problem comes from my google account wich is not "@gmail.com", its my own domain

[gehelem]

@Luka (again...) "Do you want me to add other functions to it or to the firmware? For example, some parameters can be only set but not read."
=> yes, Cooler min, cooler max, and Pk would be cool

[gehelem]

first real result, with Kp=0.04
Blue : CCD temp
Orange : cooler %
Target = 0°C

[pat30]

Luka, forget my tests yesterday, my temperature probe had a broken pin !

Great job Gilles

[gehelem]

Same test (target = 0°C) but with Kp=0.1
Obiously, looks like we expected...( bigger overshoot), oscillations, and so on...
Kp parameter works quite well so far !
Thanks again

[gehelem]

i like this one, target = -10°C Kp = 0.3

[gehelem]

And one last, target = -12°C Kp=1 just to have fun

[luka]

Done. See folder "source code/luka/Gilles" which has the new firmware (v0.5L), low level driver (0.9L) as DLL and the source code for it.
It has not been tested so let me know if there are issues.

Great work with testing the Kp gain. Seeing your graphs we could probably introduce the integral (and derivative?) terms as well, they may reduce the settling time.

[gehelem]

Thank you
What should i say ? the more we do the better it is ! But i think it's time to release ;-) Many other are waiting "official birth" of this new driver... Do with your time, thank again.

I'll try it tonight, but i realized that if Delphi is usefull to push button, Excel is much better to make nice graphs.
What is provided with Excel ?? what ? VBA !!!
it works !
Simple macro, with relevant code to import dll functions, and baaaaam, you drive your cam with Excel
I'm playing with it atm, will soon share my Woorbook with macro (just need to copy/paste cam86ll.dll under same folder)

[gehelem]

And here a real run, 4 tests of different Kp, 4x1800secs, target = 10°C starting from 13°C
Not very ambitious, it's just to play with my macro...
Will make bigger/longer ones tomorrow
First screenshot Cooler %, second is T° variation

Edit : tested new functions
I have problems with Kp : returned value is not equal to the one i set
I need to investigate, I will certainly have to tweak dll type declarations (double/single/...)

[luka]

I was kind of expecting KP to possibly be a problem since Pat mentioned slower cooling.
Can you send me the spreadsheet or list here few set-get values.

edit:
Forgot to say, great idea with the Excel, I would have never thought about it. I was actually about to suggest to use Visual Studio as it has inbuilt graphing functions but Excel and VBA is probably 100x quicker :thumbsup:

[wasyoungonce]

Hmm I'm a little behind everyone but here's 2PCBs.

1 has been sensor tested ok the other, just received the SIl sockets so it'll be soon.

[luka]

Excellent work Brendan :thumbsup:

Regarding testing of the camera with missing sensor, here is an interesting observation I made last night:
I pulled out my 2nd board to do TEC testing and noticed that the 5V regulator was hotter than the 3.3V regulator, unlike my 1st board. After a while I realised that it did not have a sensor and after inserting it the 5V regulator got cooler than the 3.3V regulator, as it should be.

Interestingly the total power consumption was 210mA with a sensor and 190mA without a sensor. However, although the total current was less, the heat production was higher without the sensor, especially on the 5V regulator, like the power "got redirected" to a "wrong" place heating components that are usually not that hot.

[wasyoungonce]

When I had some bad solder joins on PCB2 it was pulling more current than normal, around 220mA. Fixing the joints lowered the current draw. Go figure. Pretty sure this was the 5V line as well.

I also noted when doing tests, when the camera was running ok on camview the I draw was ~ 130~170mA. But when camview mucked up, you know thru the software "disconnect" and "re-connect" the I draw was higher. Also not consistent.

Sorry I have my values at home, I recorded them. Using constant voltage supply with current limit so monitoring current is easy.

[luka]

Another intersting fact, Ryan is finishing his electronics and only a few capacitors were missing. The board was pulling 600mA and was getting hot. The voltages were very unstable. After some of the capacitors were installed the board started working properly.
Clearly the switchmode component of the circuit does not work properly without the capacitors. A bad capacitor could probably have similar effect...

The moral of the story: get all parts in before starting troubleshooting ;)

[luka]

There is a bug in Kp parameter, there is a "magical" factor of 4 coming from somewhere :shrug:
Working on it...

[rsevs3]

Thats easy to say when you have all the parts already :rofl:

I also saw a significant decrease in temp of the 3.3 and 5v regs when I put an electrolytic in for C17. There are some very odd power quirks with this board :)

[gehelem]

I can't confirm at the moment, but i think it is what i saw yesterday

[luka]

:bashcomp:

Seriously annoyed by the ATmega compiler :mad2:

Wasted over 6h today chasing compiler bugs. It cannot convert floating point to integer properly. For example:
equals 40.0 while
equals 10.0
:bashcomp::bashcomp::bashcomp::bash comp::bashcomp:


Anyway, it should be working now, Gilles check the same spot on GD. There is also a skeleton c# program (cam86_PID_tuning) that I used for testing of the DLL and firmware for reading/setting of Kp.

Also is it possible to test if this firmware has the same cooling speed as the old one, 0.3L (default Kp = 0.04). Pat mentioned that it was slower. Even just timing one point after 1min should be enough if other parameters are the same.


Hold, on, I forgot:
:bashcomp::bashcomp::bashcomp::bash comp::bashcomp::bashcomp::bashcomp: :bashcomp:



edit: And there are even bugs in the IIS computer bashing person :lol:

[pat30]

Luka, do not get excited like that, it's not good for the heart :lol:

Beware of my last test, my temperature probe was HS, it was not working !

[gehelem]

:):)

Quick test, comparison of previous and actual dll/firmware
=> it's much better (see attachment), thank you.

Edit : btw, are you using codevisionAVR compiler as Rome suggested ? did you try with avrgcc ?

[luka]

By the way, setting of the KP worked before. Only the reading part had the "1/4x" bug.

[gehelem]

After playing a lot with my spreadsheet, i think the best compromise is to test a full range of target temperatures (0 / -5 / -10 / -15), and to find at wich power the cooler is stabilizing.
After, (this is what i'm trying now), you can set Cstart to -5% of this value, and Cmax at +5%
Example : i've found that to reach DT=-30, my cooler is stabilizing around 50%. So i set CStart to 40/45% and Cmax to 55/60%. Then i set Kp to 0.08
This way, the "cooldown phase" is faster, and i don't overshoot too much

What do you think ?

[flolic]

Hi guys, long time no see!
I can see much development is going on :thumbsup:

I haven't touched my camera for months, I can't find spare time...
I am still working on a housing and cooling, I hope that I'll finish it soon because spring with a warmer nights is here :)

[rsevs3]

I am making some progress.

I am still waiting on a few caps, I just have electrolytic one in there while I wait. Also still waiting on the sensor standoffs so the sensor is just pressed in there with no solder, but I am getting these results so far.

I still need to add the extra cap to DD8 to fix the bar on the left hand side.

I wasted a good many hours testing and probing my board trying to work out why I was getting black screens before realising that the test needs to be done with sensor installed. :bashcomp:

Still, progress is underway!

[pat30]

Folic, you still prepare us a beautiful achievement ;).
I languish to see the result with the tec 3 stages .

[pat30]

Luka, I found a small bug, if I set the min tec to 80%, the first start starts at 60% and not at 80%, it is necessary to stop the cooling and restart it so that it starts well 80%.

I take the opportunity to say that on Webastro I put a little comparison with the QHY8.

[gehelem]

@Luka, i need a small advice :

I'm still playing with our linux driver.
Now your new driver is out, i'm starting to think about its indi version.
Last year for cam84, i've tried to convert Delphi code into Lazarus (FreePascal) with no success.
But i gave it a new try yesterday, and tadaaa ! :
I can compile cam86 low level library, and link it against our indi driver.
And i must say it's a little success, with very few modifications of your original code.
I can open/close camera, read temperatures/humidity, set parameters and so on.
I "just" can not start an exposure because of cthread stuff. Sure there is a solution, i'll try to find it.

At this point (here comes the advice request), i'm asking myself wich way i should take.
Is this a good way to do things ?
Good points are :

easier for initial setup
easier to maintain
respect of original author's "Pascal philosophy"

Not so good points are :

Pascal is not really very popular under linux
More compilation steps
platform problems to come ? (x86 / x64 / armxxx /...)
Anyway, need to switch to libftdi instead of D2XX
Loose any chance to make all this included in Indilib official packages


What do you think ?
Do you see any other pros/cons ?

Gilles.

[luka]

Hi guys,

I was sick again but getting better now. You can probably expect my online presence to on/off for a while longer.

1. I will look into the bug that Patrice reported. Also on WebAstro it was mentioned that the "white line" in row 1 reappeared. Probably when the humidity code was introduced. The problem happens when the APT decides to talk to camera (check the camera temperature/humidity...) while the frame reading is in progress.

2. Gilles, I went through a similar thinking a while ago. I even almost decided to convert the Delphi code to c#. For example, the 1000s bug was there only because we are using old Delphi/windows timers which work only for 1000s. There was no bug in the code.

I am also battling with 3 compilers at the moment (firmware, Delphi and c#). Not much fun.

If you want my opinion the proper way would be to forget Pascal and to recode everything. Of course, this is lots of work and I decided not to do it on Windows. But you already have a working indi driver.

For the future compatibility/additions, I don't think there will be that many more changes.

[gehelem]

... sorry for you, take care.

About Delphi : this is also where i am now, i've checked additions/modifications against previous version, and now I also think I can keep C driver and report modifications easier, since there is no huge change (I'm not saying that nothing was done !!! sorry :lol:)

[gehelem]

Luka, again... Just to understand :
what is the purpose of loops introduced into ExposureTimerTick ?
Is it to be more precise ?

EDIT :
Got it : i think this is about what you said about timers over 1000s...