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.
In principle it shouldn't drift away if you are using guiding, right??
Currently my mount is disassembled in order to replace some bearings after I have lapped the worm and upgraded the belt and some springs.
I could try connecting all electronics, attach it to Stellarmate, and hope it doesn't require the index pulse from the RA worm, because that's not going to be synchronized now.
So, logs maybe this weekend.
It's also a bit weird that the zero position in the mount is overwritten by Stellarmate at the same position as the park position. That also gets overwritten.
I start the night with the counterweight pointing down and the telescope toward NCP. After a night of imaging, the telescope is parked. Dec is pointing to NCP pretty well, but the RA axis is a bit off from where I started it before imaging. I guess this has to do with time in the controller and time in Stellarmate. Something I found peculiar, but wasn't too bad.
According to INDI drivers there is only one driver that fits (exactly) my mount & hand controller, so I recon this should work properly.
I have a older type iEQ45 not the pro version. This one has DC servo motors instead of the newer/ PRO that uses steppers. And attached to it is the 8406 hand controller. Sooo... There's my reasoning.
I remember actually that when I started with Stellarmate, I used the 'iOptron iEQ45' driver (third from below in your list) and having trouble with it that I couldn't explain. Turns out there is this HC8406 driver.
I've changed the GPS module of the mount as well, that is working fine for the hand controller, not for the 'Mount updates Kstars' setting.
Thanks for your help!
Selecting the option 'Mount updates Kstars' doesn't work for me.
I have a iOptron iEQ45 (non pro) and i've replaced the GPS for a new one. On the mount, the GPS works flawless. But it doesn't get updated to Kstars or EKOS.
What is going on?
Of course I could buy a separate USB GPS thing, but that's another USB port occupied and another piece of 'I technically don't need that' on the telescope. I bought Stellarmate (also) to prevent many cables. I even upgraded my mount to have serial communication over Bluetooth, which I must say, I'm surprised by how well and stable that works!
I have other issues with my setup as well, for example the Mount doesn't slew with Polar Alignmount and things like the zero position gets over-written (also the Park position.
So, is the mount just to old to 'normally' communicate with it? Is the HC8406 driver incomplete? Should I buy a 8407 hand controller? Should I buy another mount? I hope not, they are not priced like sandwiches...
Thanks for your thoughts!
I'm sorry if I sound bitter, it don't mean to be offensive in any way, it's just that the system keeps being troublesome.
I will try to reproduce while having logging switched on!
Then you might be amazed by what you can get from, for example, a IMX290 chip (the GPCMOS2000). It's QE is pretty high, pixels small and noise negligible.
Yes, they stay at 16 bit when I set them at that at the beginning of the night,
But why would it lose this setting the next time I start my telescope for a night of imaging? It's busy enough setting up everything. I should be able to trust that once I've set a setting, it's -set-.
Or at least if "Then it automatically switches to 8-bit and stays that one." happens, it should display a popup or something.
I don't know if it's displayed in the message box below (with the date/ time/ [type of message]). With me I can't make the text box larger (say, 5 or 6 lines) without either fully covering the screen or going back to zero lines. So it can pass by really fast and I'm not going to scroll through it all.
is it possible to copy-paste a configuration from an existing Stellarmate to the new one?
- Home Wifi settings
- Astro setup (filters in the filter wheel, telescope information, Kstars FOV symbols, Artificial Horizon etc.)
I have a similar issue. I just didn't want to start a new topic for it, but now you brought it up it's good to contribute:
I've had two occasions in which I had my nice and shiny data the next morning and found out that the ASI1600mm recorded everything in 8 bit, while the day before it was data as expected at 16 bit depth. In the mean time I did not change this.
It's happened later again -suddenly- and I happened to catch it after a quick check of one of the FITS.
-Really- tiring that Stellarmate is so unpredictable/ unstable!
My suggestion is to set up your telescope, have the mount coordinates accurate (maybe do a few plate solves during the night on a few targets spread out over the sky) and then leave the telescope parked until daylight.
Then use the hand-controller to trace the outline of your horizon, using the view through the telescope. Write down the Alt & Az coordinates that you then can input as Artificial Horizon.
The advantage is that you get the exact horizon that your telescope sees.