Beautiful night here, but I missed it. I found that using the SynScan WiFi HOTSPOT for anything other than sending and receiving motion controls is well beyond the design capabilities of the HOTSPOT. It can connect multiple hosts and will route traffic on its local net, but the data travel at the "speed of smell." A fairly unpleasant smell at that.

I decided instead to add a WiFi router to my telescope kit. A small one, but with some ethernet ports with which to interconnect the Pi3 and Pi4 and a 5G connection to my laptop. My home network is also 5G, but it drops rather dramatically as you move away from the router. Meanwhile, the changes made a staggering difference in image transfer speed. I had considered using VNC to avoid sending all that data over the network, but I don't think I need worry about that now. I typically setup less than 20 feet from the scope, so the bandwidth is...well...as I should have done it in the first place.

I have separated the cameras on the two Pi's. Besides USB collisions, I was having network throughput problems. Now that the bandwidth is solved, I may as well just leave the two Pi computers in the kit....in case you wondered.

Gubi,

I am beginning to believe there is something amiss with the basic logic in both the indi_synscan_telescope driver and the indi_skywatcher_AltAzMount with respect to position vs. crosshair reporting. Another long night of testing (and not imaging).

I started with KStars/Ekos with the tablet running synscan and interfacing KStars with indi_synscan_telescope. I aligned with the tablet only to Jupiter. KStars showed Jupiter with the crosshair. I then did a tiny move to a close-by star. It moved in that area, crosshair and all, but the plate solving failed. It failed via max retries (4) and oddly. The first solve showed it about 1 minute 50 seconds off target. The second, 33 seconds (so far, so good), then the next was 41 seconds and the final was 58 seconds. This odd behavior did not occur when I plate solved with skywatcher_AltAzMount.


Then, I tried to move to M15, and the scope moved in that general area, but the crosshair moved "out of the universe." I don't like the synscan_telescope driver, so I blamed it and restarted indiserver with skywatcher_AltAzMount. I restarted KStars/Ekos. The crosshair was in the same place. So, I brought up Carte du Ciel. Same thing. Crosshair out of the known universe. Exactly the same postion as was displayed by KStars. It may be that the screen positioning routine for the AltAz mount drivers is just a bit broken. The scope clearly did not leave earth during the tests.

Different test tonight. I am going to try SkySafari on my Android with the SynScan Pro app to control the scope. If that works happily, I'll add in PHD2 with an indiserver running the dreaded synscan_telescope driver. I have, in past tests, had reliable guiding at least with that driver and PHD2. This assumes, of course, that it doesn't fight with SkySafari. That will just leave be back at needing to accommodate plate solving data.

So finally, a question: Do you know if there is a manual way to modify where the scope believe's itself to be with actual data from a plate solve? I'm guessing that setting new RA/DEC coordinates in the indi control panel triggers a GOTO....which would be bad, since it is already there.

Gubi,

I finally had a good night. Alas, the reason was that I was able to eliminate the problem by using strictly the Android Synscan app along with the Android SkySafari app (no indi drivers). Apparently, there are significant issues with both the indi_synscan_telescope and indi_skywatcherAltAzMount. I can no longer blame the SynScan Android app, though I still dislike having it in the mix. When fed data from SkySafari, it passes along a flawless set of commands that both seeks and tracks at a level I have not seen before. The tracking was so good for my "usual suspects" (M2, M15, Jupiter, Saturn, Mars) that I didn't even bother with PHD2 (which would have involved an indi driver at some point).

I did to plate solving (manually) and made manual adjustments and sync'd the mount. Minor adjustments only. The GOTO was pretty close every time.

I still believe that the indi_skywatcherAltAzMount is the better of the two drivers for the Skywatcher 250P, despite its "not production ready" status. The two biggest bugs I see are the wayward crosshair display, which gives the user the impression the scope has gone mad, when in fact it may not have, and the guiding bit. To be fair, I didn't test the guiding issue enough to know if it was related to a network issue. When I get back to testing, I'll look into that. There is also the potential issue of occasional mount madness that could be related to network issues...or something else.

If we put aside the plate solving and guiding, the mount behaves normally with the drivers? I have EQ8 (which is use with EQMod mount driver) and AZ-GTi (with AZ-GTi driver based on EQMod as well), though never used AZ-GTi with guiding or plate-solving before, just GOTOs.

SkyWatcherAltAzMount uses a different mount model than EQMod, so it may not work well with plate solving and someone needs to take a closer look at that.

Knro,

As far as I know, the AZ-GTi driver is just the EQMod driver with different defaults for connection (upd instead of serial), right? Does the AZ-GTi driver works with AltAz configuration? As far as I know it only works when the AZ-GTi mount is on an eqatorial wedge, and effectively working as an EQ mount. If you want to use your AZ-GTi mount in the default configuration, you must use SkyWatcherAltAzMount os SkyWatcherAltAzSimple, right?

To answer your original question, the drivers (SkyWatcherAltAzMount and SkyWatcherAltAzSimple) basicly works with the mount, with some strange behaviours, which we are discussing here. The plate solving does not make it any better or worse (guiding is an other peace of cake...).
Some of the strange behaviourt is related to some communication issues between the mount and the INDI driver. I blame my too long serial cable, and I definitelly found the mount "going crazy" while connecting through WiFi and UDP, and I have overloaded the wifi by transfering live images.
But some strange behaviour is not related to communication issues, but somehow connected to the translation between AltAz and RaDec coordinates. These issues are mostly due to unsuccesful sync operations, which may be caused by plate solving, but equally can be caused by manual syncing.
As far as I concerned plate solving is essentially needed to use SkyWatcherAltAzMount driver since the main advantage over using synscan is the much easier initial setup of the mount. In the case of synscan you need to do two star training before you can use any intelligent functions, while the SkyWatcherAltAzMount works right after startup, and the mount model is refined as you make more syncs, which is a great feature, at least in theory. In case of synscan any further sync operation makes just a "local ofset" while in the INDI mount model all of them refines the mount model somehow (I don't realy understand the details here) which can be a huge advantage, but if it fails or does not work in an optimal way it may drive the mount model into a totally bad state, and I see no recovery from it (other than restart everithing from scratch).

There is here a funny difference between the behavior of SkyWatcherAltAzMount and the SkyWatcherAltAzSimple driver. the former stores the actual goto coordinates in RaDec form while the later stores it in AltAz form. That means that when you make a plate solve with "sync mount model" option, the mount model is updated and so the conversion between RaDec and AltAz is updated. In the case of SkyWatcherAltAzMount that meas that the mount (hawing its AltAz coordinates not changed) no longer points to the target (by the calculation of the driver) so it slews automatically to the target (although the user does not asked for it). While the SkyWatcherAltAzSimple driver does not slew anywhere since the AltAz coordinates of the scope still points to the requested (stored) AltAz coordinates, but in KStars the croshair is updated to show the actual coordinates the mount is pointing to. The user can then ask to slew to the desired target (or use the proper option on the plate solve tab for that). I think this later one is the correct behavior, the former one may cause user confusion.

Jon,

Please bear in mind that the indi_synscan_telescope and the indi_skywatcher_AltAzMount are quite different animals!

In the case of indi_synscan_telescope driver all the work is done by the synscan app (or hand controller, but you use the app). The driver does not store any information or model abount the mount's state. It gets the mount coordinates from the app, both in AltAz and RaDec coordinates. It issues goto commands to the synscan app to a given coordinates, and all the slewing and tracking is managed by synscan app. The app simple reports the actual coordinates of the mount time to time to the indi driver.
There are places here where things may go wrong.
- The app reports both the AltAz and the RaDec coordinates, as far as I know KStars only use the RaDec coordinates.
- When you issue a goto command in KStars, Kstars gives the RaDec coordinates to the INDI driver to goto to. By default the indi_synscan_telescope worked in a way the it converted the RaDec coordinates to AltAz coordinates knowing the actual location and time of day, and issued a goto to the given AltAz coordinates. But it may not be accurate as the mount is never perfectly aligned, that is why we use training at the begining of the session. But the indi_synscan_telescope driver has no knowladge of the training data at all.
- Also any snyc or plate solve operation tells the synscan app to use a small ofset at the given part of the sky when converting RaDec to AltAz or vica versa. The indi_synscan_telescope dirver also does not keeps track of that.
- That is why I have contributed an option to the indi_synscan_telescope driver that it can issue goto commands to the app in RaDec coordinates. This basically eliminates these issues, lets the synscan app to move to the asked coordinates by it's best knowledge. If you are using my updated version of the indi_synscan_telescope driver (it is in the github main repo since a while, I don't know wheiter it has found it's way to the distroes yet), you can find an option on one of the driver tabs in EKOS for GOTO AltAz or RaDec.
- an other problem can be (i have run into it), that when you connect to the synscan app with the indi_synscan_telescope driver (after correctly setting up the mount and do the alignment) the driver sets the clock and location data to the knowledge of time and location of the RPI. If the RPI's real time clock is not set correctly it may cause serious issues. Your case of "pointing to nowhere" may be caused by this issue. Always make sure the RPI's real time clock is correctly set! I use an RTC module with my RPI.

The indi_skywatcher_AltAzMount does a much greater job with maintaining a mount model, that certanly may still contain bugs, but at least we have the code for it and can fix it. The synscan app is given as is, you may like and use it or hate and don't use it but there is no way to fix it.

Finally: the synscan app and the indi_synscan_telescope driver works quite well for me. I perefer to use it with INDI connected because I have so much more option that using synscan alone.
- first there is plate solving. It helps a lot and can be used with synscan, works well for me.
- I can connect a gamepad to the RPI and control a mount with that during visual sessions, much greater than using the app or SkySafary to move the mount
- SkySafary can either connected directly to the synscan app or to INDI. In case of a hand controller, the only option is to connect SkySafari to INDI (which is a great improvement over using the hand controller alone)
- I have not tried guiding with synscan yet, but it may work too.

Gubi,

Thank you for your reply. I much appreciate all your efforts.

To your points:
I do have a very clear understanding now, I believe, of the specific differences between the functional operations of indi_synscan_telescope and indi_skywatcherAltAz mount. Though I am not a C/C++ programmer, I have written commercial complex networking, motor control and remote operations software in assembler and Java for over 40 years. I have now read through the code for the two drivers, along with the motor control spec for the Skywatcher 250P, along with the INDI protocol programming specifications. I have also spent some time looking at INDI for Java, because I believe I can solve -my- problem there, though that entire platform seems dead. If I can contribute testing time to solve the greater problem, I'd feel better about it than just fixing my setup.

I agree that there is a strong possibility of translation issues between RA/DEC and Alt/Az. It -feels- like that from my testing....which is not, by the way, random. I set out with each test to prove or disprove particular steps. I admit to having a warped sense of humor, so sometimes my explanations of tests and results are more literary than specifically factual. You must forgive me for that.

There are a few places I would look for the potential inaccuracy in coordinates. Time, location, and (my favorite) JNow vs. J2000. The latter could be different in different areas of the driver, or calling program and cause some odd results.

Like you, I have been concerned about WiFi issues and RPi time/date. To that end, I moved the Pi to the scope used the Pi WiFi to talk to my local network for NTP and image transfer, then hardwired the Pi (ethernet) to a fairly powerful Cisco WiFI N router, also mounted on the scope, for an on-scope WiFi network, to connect to the Skywatcher WiFi motor client. I would go to a serial connection for the mount motor, but my model requires the hand unit for the serial USB cable connection. I have not had good luck with connectivity from a FTDI/USB cable yet, though finalizing that is a TODO for me. Meanwhile, my high-density WiFi signal should be fairly reliable for the half-meter it has to cover. Image traffic is on a different WiFi channel on the local network.

I have had good results guiding with PHD2 using the indi_synscan_telescope driver. I don't trust it at all for general operations, but once pointed, it will keep you on a star with a little help from PHP2. So, whether that is on or off the current project table is of no consequence to me presently. And, since it involves pulse and not sync, I don't believe it is part of the larger problem.

The big problems are GOTO and SYNC reliability. And by reliability, I don't mean it must go with extreme precision to the target, but at least somewhere close. And the cross-hair must be accurate with where the scope thinks it is. SYNC must work properly and not break things.

I also agree that plate solving is not optional. Both blind solving and relative...but at LEAST blind solving. But that is reliant on a reliable SYNC as well.

The version I am using is a recent (this week) GitHub get from github.com/indilib/indi. I haven't noticed if it has the RA-DEC/AltAz switch. If it has the option, I'll switch it to RA-DEC. Otherwise, I'll look for an update.

If there is anything I can do to test further, please let me know.

Jon,

What I wanted to point out, that the indi_synscan_telescope driver is so much simpler than the ohter two that there is nothing in it that can be "fundamentally bad". I have also seen the crosshair pointing to "nowhere", but as far as I can recall it was with one of the native driver (not the synscan one).
Having said that I have already found a thing to fix (or better to say: improve) in the synscan driver, so certenly here is more space to improve!

Some places to test and find out:
- I don't really know why the solve/sync/slew to target/ repeat process is aproaching the target so slowly sometimes. In theory (especially with the synscan driver) once successfully plate solved, the offset at that particular target is known, so the next slew to target should be particulary fine.
- Also there is a problem you also have noticed: plate solve sometimes just does not succeed. I don't think this has anything to do with the driver since the driver does not do anything for the plate solver. I really don't know. It could be a problem if the driver thinks the scope is pointing somewhere far away from the reality, then the plate solver does not search in a bug enbough region (there is an option in the plate solver not to get hint from the scope/driver and just search the whole sky. At the begining when one of the driver has given me some coordinates inverted, that was the solution for me. But now normally the driver provides quite right coordinates, so plate solving should just work like charm).
- Giuding. I had no real success here, with any of the drivers.

Unfortunatelly we have cloudy sky here since weeks, so my scope has a quite sick dust layer on it by now.

ps: When I got time near my scope and RPI I will create a screenshot for you with my option addition, just for reference...

Gubi,

Yes, I understand that indi_synscan_telescope is just passing orders from the client, with a bit of minor translation/formatting to the SynScan app (Android, in my case) and that all the "work" and heavy calculations are done in the app and passed to the mount. This compared with the indi_skywatcherAltAzMount, that does both the client communications and calculations as well as communications to the mount. A much easier job for the indi_synscan_telescope driver.

Let me mention, while I am thinking of it, there is a small bug in indi_synscan_telescope regarding the Site properties. It can't impact much, but as a matter of "neatness," location elevation will not set and reverts to 0. One may even alter the .xml and place an elevation number there, but it will still revert to 0. Not a big issue, but worth fixing.

Plate solving failure, in general, has only a little to do with the driver. I have grab some of the temp images from failed solve attempts and usually find the failure due to bad image quality, causing a time-out. This, usually, is due to poor tracking. If the scope isn't still when it tries to image, you'll get a fail. The problem is that there is sometimes a bit of a delay after a GOTO while the scope settles. There probably needs to be a configurable delay after GOTO and between solves to prevent a moving scope from being the reason for the failure. The other major causes of solve failure seem to be time-outs. These probably aren't driver related and have more to do with the image specification and the parameters for astrometry.net (local). This incluldes selection of indexes. Too many or wrong indexes will cause timeouts that shouldn't happen. Also, as you noted, a blind solve must not have a radius limit. Frankly, the radius limit for close range goto solves should probably be very visible as a configurable option.

I've been recently getting as up-t--speed as I can on general plate-solving. My current mode of operation is to startup the scope level and North. Use the Synscan app (without alignment) and slew to "some target." It doesn't matter which, but I typically pick some bright star. Then I manually take an image and manually blind plate solve with local astrometry.net conver the RA/DEC solved results to Alt/Az and compare it to where the scope thinks it is. Manually move the scope (with Synscan App or SkySafari->Synscan App arrow keys in the general direction of my calculated Alt/Az, then sync. And then repeat the solve and move, though I add a 30 degree radius to the astrometry.net solve-field parameters instead of blind solve. A very few hops and I'm at the target. I have to be careful to keep the hops small, or I get a sync not possible error from SkySafari. This seems to setup the alignment, as subsequent GOTO commands are more accurate.

I know that this is basically what Ekos is doing automatically. But by doing it manually, I have a greater understanding of the pieces and have taken all indi drivers out of the mix. Now, if I add a driver, I'll know the driver was responsible for any misdeeds. I did, however, get my crayons out and put together a Java app that grabs the image, calls solve-field (astrometry.net) with my parameters and does the RA/DEC to Alt/Az conversion for me, but I did do it manually first to prove the concept. So far, tracking with SkySafari running the SynScan app is the smoothest I have ever seen...much better than with the SynScan app on its own. I would love to run a capture and see what SkySafari is sending to the SynScan app, but it only works if they are both on the same tablet, so there is no network traffic to grab easily.

I am not sure about the slowness, but I note the difference in my manual process. If it doesn't do a proper sync, or the sync fails, I can see delay problems. If it doesn't reset to blind solve and keeps trying that 15 degree radius (that I believe is too small for many scopes), the it will end in a solve fail, because it is trying to solve on a radius from a place it is no longer pointing.

Try PHD2 for guiding with the indi_synscan_telescope driver. The trick is towait for calibration fo finish, then run the guiding assistant for a few minutes, stop it, then follow its recommendations. After the settings changes, it settles down nicely. Not as crisp as an polar RA/DEC mount, but certainly smooth enough for fast-imaging scopes like those you and I have.

I do have the new driver version with your additions. I'll make a screen shot, as I have a few questions. I did change the setting to Alt/Az.

Gubi,

Interesting test/accident the other evening. I gave indi_skywatcherAltAzSimple another try, since I liked the way it worked except for tracking (multpile-goto, yielding a bumpy ride). My thought was that I could use it to point and plate solve, then let PHD2 do the guiding. That didn't exactly work . For some reason, indi_skywatcherAltAzSimple would hold a target long enough for PHD2 to calibrate. I then opened up the SynScan app on my tablet (mostly by accident and out of habit) while the scope was still connected to indi_skywatcherAltAzSimple and tracking. Since I had already done it, I went ahead and used the arrow keys on the SynScan app to correct the pointing.

I was watching the stars go by on PHD2, when suddenly, they stopped. I initially thought the camera stopped looping. It had not, so I started a calibration. I have never seen a graph so flat on my equipment. I bet I could have done a several minute exposure. I didn't though...and wanted instead to see of this was repeatable. Turns out it is. If you use just the indi_skywatcherAltAzMount driver, it may or may not track well enough to add in PHD2 for guiding. But if you then add Synscan app, move the scope just once and enable tracking, it is amazing. Settles right down to nearly acceptable without guiding. Add PHP2 to that and it is more stable than I have ever seen it. Next time (if ever I get a clear night again), I'll make a screen shot of the graph.

I realize this is the textbook definition of what we call a "kluge." All I need do from here is find a way to add in duct tape and I'll have a master rig. However, it does give me hope that there is a software solution that makes the mount stable.

Well...another night of testing and I am not as thrilled as I was. Apparently, there is something key to the sequence of devices or functions turned on that I didn't manage to remember properly or write down. I couldn't manage a repeat performance as I did the other night and started second-guessing the order of connections. I never got the same, or even acceptable results. But, at least I know it is possible with the equipment I have. I just need to find the right driver setup.

Today, I am testing the AzGTi driver (EqMod/AzGTi), and specifically indi_azgti_telescope. Since there isn't a hope for clear sky for a while, I am going to set it up in a room and try multpile GOTO operations, then measure that Alt/Az with an angle level on the scope and a compass against the coordinates listed in a planetarium program. I also will let it run for a while on a target and recheck the coordinates to get an idea of tracking accuracy.

The "AUTO" setting for the pier is a bit of a concern. My suspicion is that it may decide to try and flip the scope rather than turn 180 degrees if that is the short route to a destination. That won't do at all for the Skywatcher 250P (Dobsonian). There is a pier setting for West (pointing East) and East (pointing West), but I can't think of a less intuitive description for what those settings do. If it tries to flip the scope, I will use one or the other, but I don't see that it matters which on my mount.

Testing guiding, of course, is off the table for lack of stars. Unfortunate, in that guiding is the ultimate result I am trying to achieve. There are multiple work-arounds for GOTO, Plate Solving and Sync for indi_synscan_telescope, indi_skywatcherAltAzMount and indi_skywatcherAltAzSimple, but none of these can seem to manage a stable platform once it gets where it should be. I suppose it would also be a bit of a success if indi_azgti_telescope does not exhibit the random odd pointing and reticle display displacement I have found in the other drivers.

It was good to see that indi_azgti_telescope is setup for UDP port 11880 WiFi by default. I did a "happy dance" when Gubi enabled UDP in indi_skywatcherAltAzMount and I could get rid of the evil SynScan app. Indi_azgti_telescope also has more options for guiding adjustment than the other drivers...though more doesn't always mean better.