This is my old bug report for this code. Do we talking about the same issue ?
1. Reboot software and mount, let it go with fresh run.
2. Set physically mount to point 20deg Alt, 0 deg Az North
3. Using Kstars mount control sync it to that point (change to az -> enter values AZ:0 and AL:20 -> press sync)
4. Using Kstars mount control only left arrow move the mount 90 deg left to AZ 270 West
5. notice that mount physically is pointing AZ:270 ALT:20, Kstars report it as AZ:270 ALT:0
6. Using Kstars mount control sync to point where mount is physically pointing (enter values AZ:270 AL:20 -> press sync)
7. Using Kstars mount control goto back to AZ: 0 North ALT:20
8. this is looking all right
9. Using Kstars mount control goto AZ:90 East ALT:20
boooom!!!! My mount physically going to AZ:90 ALT:60 !!
Paweł, sorry for my mental shortcut, I understand that first sync point is somewhere up in the sky. But horizon level (Alt 0 Az 0) is some kind of hidden sync point because it determine alt 0 az 0 that way. Error in this point will affect accuracy of whole model.
Just try at your step no.1 point manually to Alt 10 Az 10 (error) and test model accuracy. You will notice how bad it becomes.
Thank you guys for moving things forward !
Paweł - here are my points against "manually point at the moon and sync":
- Celestron does that in their hand controller and in SkyPortal. Think about it!
- there is no single hint for a user saying that first sync should be at horizon level - thus when doing first sync above horizon level user risk exactly the same - mount may cross unsafe regions. There is no guarantee where user point. In my humble opinion, the risk is exactly the same or maybe your way is even more dangerous actually, because there is no information for user about horizon first sync and user experiences moved from SkyPortal, hand controller or other app encourage user to point to do moon and sync. Your method gives exactly same risk or even greater
- when doing first alignment sync using plate solver or just syncing to the star with proper leveled mount, you got 0 error agains „some" error from trying to find Alt 0 Az 0 using your compass and spirit level
In daytime like today I can point the moon using my muscles, and tell SkyPortal that I am pointing it or just use my NexStar hand controller to do the same. Just one calibrating point with proper leveled mount is enough to follow the moon for hours. No North Alt 0 requirements not any, just point to the moon and follow it. Not a chance with Indi_celestron_aux
I have a dream - to take out my gear, connect to it from my worm home (just like using astroberry with indi server) - press one button (auto align to sky using mount, camera artificial horizon and plate solve) and just enjoy the views....
Have a good day
@Paweł, @Jasem I can provide access to my indi server over internet for you
And I just run into something odd - after writing last message, pressed again "slew to target" error jumped from 60 to 400arcsec (ok some time passed by) but it goes into loop moving to the same place and plate solving same place, but on kstars map it was moving to right place, and after plate solve jumped into real bad place.
I've been trying today 4 sync sessions with my evolution mount (all started from alt:0;az:0 and based on plate solving) 3 first I was using "Nearest Alignment" and sorry to say, but was quite bad
first point error about ~20000 arcsec
While using "slew to target" It aborts after few tries at around 130 arcsec error.
Fourth session was using built-in plugging and It was:
first point error about ~20000 arcsec
second 3000 arcsec
third 600 arcsec
And while using "slew to target" It aborts after few tries at around 60 arcsec error.
My issue is still not resolved, You have to use this error prone method with first point directing alt0:az0. If you miss this point by a few degs, your whole calibration process is working bad
Is this already released ?
Wanted to test with Alt-Az
When I am in "Object detail" under Mac Kstars 3.5.2 there is no image there. When I click on it I got:
"Unable to create io-slave. Can not find 'kioslave5' executable at '/Applications/kstars.app/Contents/MacOS, /Applications/kstars.app/Contents/libexec, /Applications/kstars.app/Contents/libexec/kf5, /Users/rlancaste/AstroRoot/craft-root/lib/libexec/kf5'"
Where I can report it ? Is there any quick fix?
Kstars was installed via home-brew cask
Wow, you are right ..that is almost what I need.
It would be great to get this included in "observation planner" time/alt chart as nice red mask (same as on map) and with AZ axle next to time
I don't know if this is more Kstars future requests or indi but, It would be great to create something more that location with gps only coordinates, something like "My spots" With ability to draw available horizon for scope.
For example I have a wall from AZ 90-180deg that limits my ALT to 80-90deg, then I have a tree at AZ 200-230 that limits my ALT to 60-90deg, and got all round fence at AZ 180-200,230-90 limiting ALT 20-90 deg.
It can be used to draw that virtual horizon on map, but biggest benefit will be use in observation planner.
hy post=69080 wrote: SQM is an interesting number, but really I believe what thread is about is getting a good exposure values. My (gut feeling) belief on this is that if you're in the ballpark (e.g. if 240s was "optimal", 120s is probably in the ballpark, but not 10s), not saturating parts of the image you care about, stacking your subs for your final image, and have a modern camera with reasonably low read noise, then getting precise with exposure is overkill. Disclaimer--I've never won any image-of-the-day or top-pick awards
I like the idea. SharpCap have it, NINA also, it would be cool to get it on board. Is it possible to calculate SQM from ADU somehow ?
I found that:
with few ideas and formulas. Basically there are two roads to take.
1. Calculate SQM using know stars brightens
2. Calculate SQM from camera params and ADU