I don't remember things turning that bad for me. I bet your scope was tracking when that happened? If so, it may be a consecquence of communication failure between the mount and the driver. Tracking means the driver periodically reprogrammes the mount to slew at a specific speed at each axes. Having some of this command getting a communication error, the mount may have programmed to slew at a crazy speed. The same communication failure may prevent the driver from instructing the mount to stop... I know, not a really reliable system desing...
After having to turn off the mount, it seems to be a good idea to have a clean start. Maybe you don't need to turn off the RPI, but definitelly disconnect the driver, restart the inidserver, and start from park position, to have a clean sync state.
The Wifi in the mount in HotSpot mode pretty much a normal hotspot. I don't know what do you mean by 'act as a router', route between what? It has only a single network, the wifi itself. Still you can connect to the wifi with multiple devices, as any wifi, but it is still a single network.
I used my wifi dongle on the mount (i don't have it built in, but I bet that is the same) as a hotspot and connect to it by one android phone running the synscan app, an other running SkySafari, the RPi, and my laptop running VNC too.
But be carfeful witth the wifi, it is easy to overload the wifi capacity. Once I have used my setup as the RPIi was connecting to the mount through the wifi dongle instead of trhe direct USB cable, and my laptop was connected to the RPi using VNC through ethernet cable. When I disconnected the ethernet and swithced the VNC connection to the wifi the mount started to act strangly. I bet it was due to some of the mount commands has been lost on wifi.
I have the feeling that even in the case of direct USB-TTL serial connection between the RPI and the mount some strange behavior and lost tracking is due to packet loss os bit error on the serial cabel (I had made myself the serial cable too long, TTL voltage is prone to noise).
Plate solving is working for me pretty stable either when the camera is on the main scope or when I put it on the finder scope. Just be careful and set the scope focal length correctly, and choose the correct scope on the plate solving tab.
I use my setup as both the Indi server and KStars runs on the RPI and I connect to it using VNC from my laptop or a tablet. This way I can do a setup where the wifi does not play an important role: the mount is connected to the RPI through USB cable, the camera also connected through USB3, so all the tracking and imaging is self contained in devices strapped to the mount. Only I myself monitoring the process is connected through wifi. If the wifi disconnects nothing is lost, I just need to reconnnect, INDI, Kstars, EKOS both running unaffected.
I like to use the telescope with a game controller. This way I can manually stear the scope, and have a feeling of manual search for objects on the sky, while INDI partnered with SkySafari gives me the knowledge of what I'm looking at and where am I going.
As far as I remember I was able to get the synscan indi driver totally fooled by some not-so-successful sync operation. The sync operation works somewhat different in the case of synscan than the other cases, because the sync makes nothing else but adds an offset to the coordinates at the pathc of the sky at where it is used. And it is done by the synscan app, the INDI driver has no knowlade about it. So it can drive the INDI driver's knowladge about the coordinates and the synscan app coordinates totally out of sync. I know that synscan keeps track of these 'sync offsets' for every pretty small parts of the sky, althogh I'm not sure how small those pathces are. Jupiter and Saturn are pretty damn close...
I have tried guiding with the AltAzMount driver driver with not much luck. Although I've tried internal guiding, not PHD. Maybe I should give a try to PHD too...
In the indi_skywatcherAltAzMount driver the guiding code is disabled, the comment says: " TODO: Hide the auto-guide support now because it is not production-ready" which I don't understand since the whole driver is "not production-ready".
Yopu can enable it for yourself, by removing the comment sign from this two lines:
// Guiding support // TODO: Hide the auto-guide support now because it is not production-ready // initGuiderProperties(getDeviceName(), GUIDE_TAB); // setDriverInterface(getDriverInterface() | GUIDER_INTERFACE);
What you need is plate solving, I think!
That makes the difference to using just Synscan.
One more good news: one more improvement have been made to the drivers: joystick support has been fixed. So now you can use a joystick (or rather an USB gamepad) instead of the "hand controller simulator" on screen.
I even use it for eyepeace observing, it is nice just panning around the sky. In order to know what I see, i put the camera on the finder scope, and use plate solving with that!
Then connect SkySafary on my phone to INDI and pan with gamepad and I can see on SkySafary what I am looking at.
This image of Jupiter is much better than I have ever got!
But I don't understand, do you really expo Jupiter for 4 secs? I use 15 ms expoes for Jupiter.
Plate solving is not difficult, Jasem has great tutorials about that: www.youtube.com/watch?v=lyRGsi2BG7g
Just be sure to set your telescope focal length of your scope.
The basic principle is that it tells the driver where the scope is pointing at, updating it's coordinates in the driver. Of course that mean that the crosshair also updated in Kstars. But it actuially updates the driver. Essentially the same operation you yuse for SYNC. After that what happens in the AltAzMount driver is that as it is tracking and now knows it is not pointing to the target, it will slew to the target (center Vega). As the AltAzSimple driver stores the Alt/Az coordinates of the target, it will not slew automatically after solving, but you will see in Kstars that it is not exactly targeted, and you can issue an other GOTO to your target, which will now be much more accurate.
That is pretty much the same, as mine. Just mine does not have a built in WiFi on the electronics. Too bad, because mine is pretty much new
Can you tell me what is Mount Code of yours? It is on the 'Detailed Mount Information' tab in the INDI control panel. Mine is 152.
I think what you are doing is correct. I bet you mean by Synscan->Sync (right menu) Skywatcher AltAz -> Sync. Since there is no synscan involved in this process (that was your goal, right?)
As far as I understand the Alignment subsystem, you can repeat the Sync operation with more stars, and this will improve the tracking accuracy. This is not the same as with the Synscan handcontroller, no "two star alignment" or "3 star alignment", this is "many star alignment".
I don't know the limit, but definitelly can be done more than twice.
Also it is a big advantage of using INDI that you don't need to do it "by hand", plate solving is a great thing!. Just put your camera on the scope from the beginning, and use the alignment tab from EKOS! You don't need to find any known star. Just point your scope pretty much anywhere with a Goto operation (I normally start with polaris). It will not point to polaris of course, but now do a 'Solve and Sync' operation and you have a starting sync. Now goto to an other star, and repeat. The great thing is that you never have to 'center a star' by hand. Plate solving works even when there is no bright star in the field of view.
About tracking accuracy: 4 sec exposures is just what I got, most of the time. You will not like what I say, but these drivers are not production ready, IMHO. I try to make it better, but I just understand too little of how it works yet. I get better results with the Synscan handcontroller, and the synscan INDI driver. That works quite smoothly.
Also the tracking accuracy is greatly depends on what part of the sky is the target. It is the worth just on the zenit, since the mount has to turn azimuth quite quickly. There is an effect with AltAz mount that the field of view is rotating during tracking, and it is an uneliminatable effect without eqatorial setup. It is the worst on the zenit, and much better on the lower southern part of the sky (the stars are just moving right, azimuth only). Sometimes I can go up until 16 secs, but pretty much that is the upper limit. No multi minutes exposures possible with an AltAz mount.
A few night ago I tried to image M57 and M27. I got much much better results with M27, I bet because it was at lower altitude. M57 was just above my head. I did it one after the other, with the same alignment.
Also keep in mind, that the backlash of the mount should always be considered. Always end your centering operation with 'Up' and 'Right' motion. Otherwise the mount will not start following immediately, just after the backlash amount has been rotated. Just the same with the Synscan handcontroller. This is the property of the mechanic, cannot be eliminated.
My scope is a 10" dobsonian. The main difference between the two driver is that the simple uses small goto operations for tracking every timing cycle (which causes the mount noticeable shaking), while the other tries to program the motor driver to continuously mowing while tracking.
I don't think that one has better pointing accuracy than the other, since they are basically the same code base, and utilize the same alignment subsytem.
You should not hit the STOP button, sync the only way to re-initiate tracking is an other GOTO. I think this is the case with all drivers. Normally the EKOS hand controller pad should be able to move the mount while tracking, without stopping tracking. There is an issue with these two driver because it was permanently tracking, and taking back the scope to the original target time to time.
I have made a patch for both driver, and it has been merged into the master branch (about a week ago, I think), which tries to solve this, and modifies the tracking target while moving.
So recompile the drivers from github, and give a try to that. You should be able to move the mount while tracking, effectively modifying the tracking target. It is not dead precise, but better than none.
An other way could be if you have a camera on the mount, is plate solving and syncing the mount (driver) via EKOS alignment tab. That is working more or less.
I have came to the same conclusion. There is no such thing as "lon 275", after 179 E comes 179 W which is -179 E, so 275E is actually 85 W or simpe -85.
I'm sorry there is no sunshine for you today
I have an idea: maybe your mount wants wnts Longitude to be 275:00:00 degrees, because it is not raining there...
The only reason I can imagine for slewing up the mount upon unpark is that after that one can immediately take a plate solve to sync the mount. It can be made a configurable option though. At least to know about that. For now, it is hard coded into the code.
// Altitude 3360 points the telescope upwards DeltaAlt = CurrentAltAz.alt - 3360;
Most probably the AltAzMount identifies your mount as Virtuoso mount (as it does with my 10" Dob), and the driver expect Virtuoso mounts to be turned on pointing to the Polaris instead of horizontal/north. The AltAzSimple expects the mount to be horizontal/north at the time of connecting the driver.
So if you have connected the AltAzMount driver in a horizontal position (as one would do normally), that cause a big initial error in the mount model in the driver, which explains your inability to correct it with sync operations.
I see reason for both starting from pointing to the Polaris, and pointing horizontal. IMHO there should be an option for that somewhere for that, let the user choose. It does not sound too difficult to implement, maybe I will do that soon.
The AltAzMount driver has a built in procedure for unparking, only the original author of the driver knows why. There is an option on a "motion control" or "mount cotnrol" (I cant check now, as my mount is not with me now), where you can choose the unpark position (North, Shouth, etc...). The default is South, I have no idea, why. If you set that to North, the mount will not turn in azimuth after unpark. It will still raise in Alt, as far as I can tell, this is hard coded in the driver. What I do is I hit "abort motion" immediatelly after unpark, to stop this built in thing. Also there is an option, on the same panel for "silent"/"normal" slew mode. You can choose as you wish, silent mode is slow, normal mode is as fast as the mount can do.
The motor microstep per rew values are read from from the mount, it should be correct. It seems to be correct both for my little Virtuoso mount and the big Dobsonian one too. It is on the "Version" tab, i think.