It should. It is a similar device to the one inside evolution mounts. I do not know if it was tested, but I think that Fabricio's mount is connected by this adapter (SkyFi). It is just a serial<->WiFi bridge.
We have finally tested the driver with Maciek, by remote connection - worked surprisingly well. I was controlling his setup from kstars - all drivers on his side (astroberry).
- Internal plugin works OK. There is still room for improvement, but it was fairly functional.
- The Nearest plugin did not work good enough. The errors were much larger and the tracking was much worse. It was essentially unusable.
- The weather stopped our session, so no tests for the SVD plugin
The kstars crashed with segfault if connected by ekos. If connected by device manager an later by ekos the device control dialog had duplicated tabs but it worked.
let me start by saying thank you for developing the plugin. It brings me one more step towards my goal of simply putting up the telescope outside and do all my aligning and observation from inside the house.
I have been testing the Celestron AUX driver in the last couple of days using my real mount and the CCD simulator to be weather independent while it is cloudy outside. I can reproduce the tracking problems using the Nearest Plugin simply by doing continuous exposures using the simulator. You can clearly see the start wandering out of the frame. Once I switched to the Internal plugin those problems went away.
Jasem. The alignemnt model is *crucial* for correct tracking in AltAz model. The axis velocity is calculated at each step using the model. Without the correct model, we do not know where we are pointing, and thus we do not know how fast we should be moving.It is quite different in Eq mode where you can blindly set sideral rate and just worry if the target is smack-middle of the FOV.
Thanks, by I was standing on the shoulders of giants and I had help And I just made the driver (implemented the AUX protocol deciphered much earlier by Andre Paquette) - it would not work at all without alignment module.
Thanks for the encouragement. There is still missing functionality, but I am glad it is starting to feel useful. And thanks for testing - this is another data point suggesting that internal alignment routines work much better than the new plugin. SVD seems to be somewhere in between. I have never tried the real mount + simulated ccd combination. Good idea.
I run a series of test with real scope+simulated ccd against current astroberry packaged verisons.
Internal plugin still works fairly well - this is the only plugin which is useful with the CAUX driver. Do not use others at the moment (except for testing). You will only get confused.
SVD plugin actually seems to work but is very confusing when you have less then 3 sync points - jumps all over the place (after sync points to different place than synced ... this is confusing).
Nearest plugin works for pointing with similar accuracy to internal plugin but does not work for tracking. So it is useless for the AUX driver. Jasem: it seems it does not update the time of the solution, the pointing is correct and then the sky drifts. This is true for simulated and true ccd (i.e. real sky).
The "manually point at the moon and sync" strategy actually can be made to work, but the steps are fairly complicated and easy to get wrong (you need to sync first, then goto the same object to engage tracking, then goto next target and sync without manually moving the scope and so on). Furthermore, you risk that the movements of the mount may cross unsafe regions. This is generally a bad idea. I would never use it in this mode with my hardware, and you should not as well.
I would rather suggest pointing at the horizon (level, approx) and point it to the approx north. I will implement selectable initial direction in the next version, to avoid long slews to get to southern directions. Then, just do a goto "to the moon" (or other bright object) use motion control in the driver (you can use telescope app - indi client on your phone for this) to correct the position and sync (also from the app). Alternatively, just capture, plate solve and sync from ekos. Go to next target and repeat. The third target should be quite close if your initial position was not far off and the mount is fairly level. This is the procedure I use.
Note that "slew to target" function in ekos does not add sync points. You need to make your mount model first (this is actually better that way, since it avoids multiple clustered sync points). If you need to correct your pointing model do the goto, solve&sync and then slew to target.
Park position, as is implemented now, slews the mount to the initial position it was turned on. If you did not move the scope manually (which you must not) this will be level and pointing north. If you moved manually this may point below horizon or even go to some unsafe position - that is why you should not move the scope manually, and this goes not only for parking - the normal operation may be unsafe as well in such case. Moving manually may be dangerous to your hardware.
Paweł - here are my points against your "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 the 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
Maciek: The first sync should not be on the horizon. There is no hint about the first sync at horizon because you should not sync at the horizon. Regarding the safety. The: "point at the moon and do the first sync" can be executed safely if you never move the mount manually again. Then the park position will be at the initial position of the moon (in AltAz) which is presumably safe. However, it is much more difficult to reason about the other movements of the mount. Furthermore, at the preset stage, the execution of this procedure is confusing and non-intuitive. I will try to make it better in next versions. For now, I really advise doing it the way described below.
I was obviously not clear enough previously, thus the steps:
level the telescope and point it to the norh (both approximately, the acuracy is not that important)
tighten the clutches and do not touch them again
switch on the scope
execute the goto to some bright object (without nay syncing)
center the object using movement control buttons in the driver
sync the position (or capture, plate solve and sync)
repeat from the step 4 for next calibration object (you need 2, better 3)