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.

OK, that was a wash. I could find no way to make indi_azgti_telescope point the Skywatcher 250P (Synscan GOTO Mount) anywhere that made sense. It controlled the scope, but not where I wanted it to go.

HOWEVER...given that was an almost instantaneous fail, I had some time to look into the problems I have had with indi_skywatcherAltAzMount. I believe I see the issue. It does NOT want to cross the 180 degree line. If something you are tracking happens to pass over 180 degrees, it wants to spin the scope around 359 degrees to pick up on the other side of the "boundary." There is probably some old code relating to meridian flip in there mucking things up. And if guiding happens to be in play, the guider program fights with the spin attempt, yielding all the unpleasant results I have found.

It happens that I have been doing most of my testing with Jupiter. Everything seems well for a bit, then it goes wonky. Now that I think of it, the wonky bit happens right around the moment Jupiter puts a toe over the 180 degree line. I think, knowing this, I'm going to give that driver another try. It has been my most hopeful candidate so far....excepting the previously unexplained madness it exhibited before I noticed this behavior.

Hello Jon,

I keep reading your post about the driver issue and feel helpless to do anything about it. IIRC, you have great software development experience already. Do you think you can perhaps bite the bullet and set up QtCreator and check the source code directly? It's not greatly different from Java and after you get the hang of it, the workflow make sense. Also, we're here to help you with any development questions as well.

Jon,

I'm still in the process of digesting your posts, so please allow me some more time to react to them.
But a quick reaction here: indi_azgti_telescope is not supposed to work with Skywatcher 250P, because indi_azgti_telescope despite it's name this is a driver to an eqatorial mount, namely the azgti mount on an eqatorial wedge. If you can tilt your dobson mount that it's "vertical" axis points to polaris then (and only then) will indi_azgti_telescope work (it is basically the eqmod driver!). It worked for me with my heritage mount put on a photo legs tilted 48 degrees.

@ Gubi,

I came to the same conclusion about the indi_azgti_mount after about 2 minutes into the testing. Not a good fit for the Skywatcher 250P.

@ knro,

I have been peeking at the code in NetBeans. And yes, it isn't so different from Java that I can't read what it is doing. I have done minor maintenance on C++ code, a few decades ago, but I've slept since then. I may start poking around with small adjustments to the indi_skywatcherAltAzMount code. It seems the closest candidate to a working model. What I end up with will probably be less generic and tilted more toward GOTO Dobsonians. I have been trying hard not to get into coding again, as my "retirement job" is being a gyroplane CFI and gettng back into music performance. Both of those take a lot of time. But it looks like all this stuff is written in C++ and if I am to be of any use to anyone (myself included), I need to get on the boat and grab an oar.

Oh...and with regard to today's testing: The =really= frustrating thing is that SOMETIMES the mount (indi_skywatcherAltAzMount driver ) WILL cross the 180 degree boundary without issue. It may depend upon which direction you are slewing. I don't know....but I'm going to find out <mumble>.

I've been looking at the code and testing a lot and believe the least amount of changes are required in adjusting indi_skywatcher_AltAzSimple for the Skywatcher 250P Dobsonian. This, because it has the fewest "barks" in general operation. Parking doesn't cause issues, pointing works well, sync works well and precision pointing with goto/sync is spot on. The two issues are that tracking is "bouncy" and trying to activate any kind of guiding requires an exorcist to undo. Both of these may be due, in part, to over-control and possibly rectified by teaking settings....or not.

The initial plan is to compare code from the very smooth tracking indi_synscanAltAzMount driver and play "which of these things does not look like the other." I am beginning to wonder if the issue with getting lost might not be in the Julian date calculation from EQ to AltAz. The initialization is not clear about where the initial grab of the system date is done and time-date is not a required field in the driver setup XML.

Wish me luck.

The status so far:

I started plugging bits from indi_skywatcherAltAzMount into indi_skywatcherAltAzSimple. After a while, I realized that what I had was AltAzMount minus the parking. So, I am trying a different approach. Starting now with indi_skywatcherAltAzMount after ripping out all the parking code and enabling the guiding code. Better results. I intend leaving the Park/Unpark code out, as it was more trouble than benefit when it worked. Not really as beneficial for a portable Dobsonian as it might be on a more stationary mount. Tracking is good and it hasn't gotten itself lost so far, despite some testing on both sides of the meridian and the dreaded 180 degree Azimuth. I have more testing to do to be 100% certain that there are no more gremlins hiding, but am generally ready to focus on guiding code next.

Any ideas on guiding testing that can be done when it is daytime or overcast? I tried pointing the mount with a webcam at a big monitor with a Stellarium image tracking and got into calibration (with PHD2 and Ekos), but got a fail on Calibration for lack of ability to move RA back to its origin (the 35 try error). The same error for PHD2 and Ekos). Both programs did move the star in the box a bit through the North/South/East/West calibrations but I am not willing to hang my hat on the validity of this kind of test. It looks like the problem could be data-related, as some settings, such as the settings for RA and DEC rate vary from driver to client. I note that the driver lists them at 1.20, and both PHD2 and Ekos default setting is 0.5 The setting of 1.20 is not a valid setting in PHD2. I have a lot to learn before I can diagnose the issue with guiding.

The code, so far, is very straight-forward...for C++ code .

Guiding issues:

I'm reasonably sure now my simulated star movement during calibration was only the result of simple tracking. This would explain why calibration failed to bring the star back. Based upon testing by sending pulses via PHD2's manual guiding tool, guiding isn't working with my uncommented/deparked version of indi_skywatchaerAltAzMount. I'm turning on all the debug logging I can find to try and find out why and where the pulse command goes...or fails to go.

I have noticed that Time/Date is not set for the driver when connected by PHD2, while it is set when using Ekos internal guider. I doubt this is related, but could cause some Julian calculation issues relating to previous pointing issues with this driver I have experienced.