Go Back   IceInSpace > Equipment > Astrophotography and Imaging Equipment and Discussions
Register FAQ Calendar Today's Posts Search

Reply
 
Thread Tools Rate Thread
  #741  
Old 22-03-2017, 05:31 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
By the way, setting of the KP worked before. Only the reading part had the "1/4x" bug.
Reply With Quote
  #742  
Old 24-03-2017, 05:50 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
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 ?
Attached Thumbnails
Click for full-size image (Screen Shot 03-23-17 at 08.42 PM.PNG)
55.9 KB91 views
Reply With Quote
  #743  
Old 25-03-2017, 11:37 PM
flolic (Filip)
Registered User

flolic is offline
 
Join Date: Jul 2016
Location: Split, Croatia
Posts: 48
Hi guys, long time no see!
I can see much development is going on

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
Attached Thumbnails
Click for full-size image (cooler1.jpg)
133.3 KB151 views
Click for full-size image (cooler2.jpg)
196.6 KB152 views
Click for full-size image (cooler3_pelt.jpg)
187.7 KB149 views
Reply With Quote
  #744  
Old 26-03-2017, 09:41 PM
rsevs3 (Ryan)
Registered User

rsevs3 is offline
 
Join Date: Feb 2017
Location: Perth
Posts: 10
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.

Still, progress is underway!
Attached Thumbnails
Click for full-size image (image.jpg)
198.8 KB103 views
Reply With Quote
  #745  
Old 27-03-2017, 03:58 AM
pat30 (Patrice)
Registered User

pat30 is offline
 
Join Date: Oct 2016
Location: France
Posts: 120
Folic, you still prepare us a beautiful achievement .
I languish to see the result with the tec 3 stages .
Reply With Quote
  #746  
Old 29-03-2017, 05:50 AM
pat30 (Patrice)
Registered User

pat30 is offline
 
Join Date: Oct 2016
Location: France
Posts: 120
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.
Reply With Quote
  #747  
Old 30-03-2017, 07:24 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
@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.
Reply With Quote
  #748  
Old 01-04-2017, 10:34 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
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.
Reply With Quote
  #749  
Old 02-04-2017, 12:35 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Quote:
Originally Posted by luka View Post
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.
... 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 )
Reply With Quote
  #750  
Old 02-04-2017, 01:45 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
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...

Last edited by gehelem; 02-04-2017 at 01:55 AM.
Reply With Quote
  #751  
Old 02-04-2017, 06:39 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
The loops are there as the Delphi/Windows timer does not work for durations over about 1000s. The loops are there to restart the timer every 900s so we never go over 1000s.

edit: Just saw your edit :-)
Reply With Quote
  #752  
Old 02-04-2017, 06:49 PM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Yep thx
I must check if this affects firmware's behaviour ("expoz" value to spi_comm)
Reply With Quote
  #753  
Old 02-04-2017, 09:29 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
I don't think that got affected. Previously at 1000s the low level driver would read the frame and the camera would stop exposing. Right now the driver will actually wait the real exposure time before sending the read command.

But the loops are messy way to work around the issue. You should not have those problems.
Reply With Quote
  #754  
Old 05-04-2017, 01:54 PM
pat30 (Patrice)
Registered User

pat30 is offline
 
Join Date: Oct 2016
Location: France
Posts: 120
Luka, a few times there is still the condensation warning message while I do not have the DHT 22 on the cam.

Here are my last tests!
Reply With Quote
  #755  
Old 05-04-2017, 02:20 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
Pat:
1. Without DHT22 sensor the ATMega pins are floating and every now and then the camera will get weird reading instead of a "zero" reading. The software verifies that the values are reasonable (humidity between 0 and 100% for example) but with random inputs every now and then there will be a reading that seems valid and will cause the warning.

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

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

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


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



edit: Pat, where are your last tests?
Reply With Quote
  #756  
Old 06-04-2017, 11:38 PM
luka's Avatar
luka
Unregistered User

luka is offline
 
Join Date: Apr 2007
Location: Perth, Australia
Posts: 1,164
New Cam86 ASCOM driver, 0.7L is out. The firmware stays the same.

Changes:
- Added a checkbox to enable/disable the DHT22 humidity sensor. This should stop the condensation warnings when the sensor is not present.
- Small bug fixes
Reply With Quote
  #757  
Old 07-04-2017, 03:58 AM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
@Luka : holiday trip to Barcelona at the moment
Stomac on tapas
Feet on Sagrada Familia
Hands on children
Head on Cam86, as often....
But i can't answer your questions at the moment...
Gilles
Edit : thank you for new driver
Reply With Quote
  #758  
Old 07-04-2017, 01:43 PM
pat30 (Patrice)
Registered User

pat30 is offline
 
Join Date: Oct 2016
Location: France
Posts: 120
Luka, for the last tests I meant last bug found.

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

Last edited by pat30; 09-04-2017 at 01:16 AM.
Reply With Quote
  #759  
Old 09-04-2017, 08:58 PM
luka's Avatar
luka
Unregistered User

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

Patrice and Gilles, do you use the DS18B20 in parasitic mode?
Reply With Quote
  #760  
Old 09-04-2017, 09:56 PM
gehelem (Gilles)
Registered User

gehelem is offline
 
Join Date: Sep 2016
Location: Rambouillet - France
Posts: 112
Quote:
Originally Posted by luka View Post
Brendan, on our PCB did we leave a way for connecting +3.3V to DHT22 and also possibly for the temperature sensor DS18B20? I am trying to use DS18B20 in the parasitic mode (without voltage In) but it is not very reliable.
I cannot see any obvious 3.3V connections, apart for going straight for the legs of the regulator or the big capacitor.

Patrice and Gilles, do you use the DS18B20 in parasitic mode?
I use mine in a "classic" way vin vout data and pull up on on pcb
What is parasitic mode ?
Reply With Quote
Reply

Bookmarks


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +10. The time is now 09:12 AM.

Powered by vBulletin Version 3.8.7 | Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Advertisement
Bintel
Advertisement