Can someone try the same maybe with their 1600mm cooled camera?
Easy test, right?
Here are the logs!
After a recent update & upgrade I can't set the exposure time lower than 2 seconds without trouble.
Below 2 seconds it will just try & retry again.
I recall that I could use 1 second and even less, integration times before.
My download time is about 1.75 s (could have anything to do with it?)
Asi 1600mm cooled, Stellarmate, RPi4 4gb.
Will try to fetch & post logs soon, but maybe it's a known property already, as I'm not the only one with this camera).
Cheers & thanks!
I don't need it. I use Python for data analysis so definately am comfortable with fft, but maybe as an idea for a future indeed. And if I can help you, I'll be happy to!
I like this idea.
It would also like to have the polar alignment to be more intuitive.
For example the iPolar interface I think is great: just move x toward y and you're set. It zooms automatically when you're closer by so it increases the feedback on what you're doing live.
Maybe a live calculation of the residual error would be nice as well, so you know when it's enough.
And have it do a check on the way (movement) back again and re-compute the PA error (while we're moving anyway).
Also, once the image is taken, we can start moving to the next angle already, right? I get that it now waits for a plate-solve, but that hasn't failed me ever, using reasonable setting.
I'd like to help program some things like these, but have a hard time figuring out the PA routine structure as it is. And need to set up some sort of VM on my W10 laptop.
Hello Hy, great ide for this module!
I was wondering if you could 'just' use text for the filters, instead of the close-to-each-other colours?
And maybe a toggle switch to switch between 'time / frequency' (using Fast Fourier Transform) so it's relatively easy to analize if there's an obvious periodic error in the mount.
You shouldn't thing in terms of '35 mm equivalent'. It only describes the field of view equivalent, not the viewing angle per pixel.
Do the calculation: What is the angle per pixel?
But it still could be an interesting cheap guide cam. Just need a old Thorlabs 160 mm 2" doublet for example. 3D print the housing and off you go.
I have designed a 50 mm guide scope with a Thorlabs 200 mm doublet using my 3D printer, some lathe-work and a piece of carbon fiber from e-bay. It works superb!
Super light weight at only 200 grams -including the Touptek IMX290 camera-, yet is as good as a-thermal and can be well focused.
This currently can't be done from the sequence.
What is a good solution is to generate a sequence (for example R, G, B or an U, B, V, R, I) and run this in the scheduler consecutively with an end-time, a number of runs or as I use it, the twilight as terminator.
An advantage (that I could come up with) of this would be that you can generate wacky sequences such as RRR, GGG, BBB or a weird combination of it like RRR, GG, BBBB.
I found it awkward to work with the sequencer at first, but now I almost exclusively with it.
It works very well at my computer, no other programs necessary.
Just download and install.
My apologies, i'm not trying to offend anyone here. I definately value the hard work that went into it and have proposed I can help development myself (but got no response).
But for me and two others at the astronomy club it has mainly been lessons in frustration management.
I have paid for the software (first second hand, and when it turned out that version couldn't be upgraded, I bought a new licence) also I got no response on an email and website chat on the first license.
I have lost many nights of imaging already because I was trying to get Ekos working properly. I have an older type of mount (iEQ45) the driver for it does unexplainable things...
And still I continue to use it and helping my friend at the astronomy club to get his stellarmate working properly. So take that as a compliment.
But I still think the internal guider isn't very good. Why does Phd2 work instantly and with no issues while I spend serious effort in getting the internal guider to work with bad result.
It's just very frustrating to me, ok?
It shouldn't matter.
I've heard many people complain about the internal guider now, including myself and a colleague of me, also a tech-savvy guy.
The internal guider is **** (I'm sorry, I'm not going to be polite about it), except for a few cases where it works as intended. Best is to use PHD2, the interaction between Ekos and Phd2 is good.
It is possible if you have a camera with non-destructive readout.
We don't have that.
Think of it like this: If you have short enough exposure times that you - can- guide with your imaging camera, you -don't have to-, because the tracking error would be negligible in that case.
Best is to simply get a guide scope or off-axis guiding. Personally, I prefer a separate, light weight guide scope, because it's more light sensitive and it prevents issues with vignetting on the imaging camera. Also I already have a lot of weight on the focuser.
I have used ToupTek camera's (GPCMOS2000 and GCMOS1200) succesfully on Stellarmate with EKOS, no problems. They also work great with PHD2.
So if your camera is ToupTek driver compatible, I don't expect issues. I haven't used the 1600 specifically though.
So, is the position of the guide star redefined after a dither is completed? That would be weird... I'd say a guide star is acquired when a sequence is started and dithering lets the guide star 'around' this position, but the average stays at this initial position.
I'm going to understand (at least) this part of the code. First thing in the morning, with coffee.