Have you tried indi_simulated_ccd? It gives a picture of the stars where the mount is pointig according to the mount driver, I think.

Gubi,

Thanks, I was not aware of that feature, I will try it today. However, I'm pretty sure that guiding is still broken or at least more disconnected than I have yet found connections for in indi_skywatcherAltAzMount. I have enabled some debug commenting and find that it isn't getting to some of the sections of the code. I can understand most of the independent functions and subroutines, but I am having trouble finding what calls each one. C++ still smells funny to me.

I do believe that not having the datetime and UTS offset properties set on connection is a problem, but only for non-Ekos platforms, as Ekos seems to set the value.

I see the function of the guide simulation, but I am getting the "[ERROR] Got no stars, is gsc installed with...." message. This has been a problem in the past and apparently has resurfaced. Since I have a working solution to checking that guiding is working (or not working, as is the current status), I'll continue to use it. The simulation would have been convenient, but isn't required and would just be a distraction and loss of focus for now.

There are some routines like "IPState SkywatcherAPIMount::GuideNorth(uint32_t ms)" that don't seem to be getting called (or perhaps the data going to them is defective). Neither can I find (yet) what should call them. Since they seem the primary means of guiding, I'm thinking figuring out what is going on here is a bit of a priority. I'm guessing there are some tools for C++ that make looking for such connections less tedious. The first time I had to mess with C code, though, I was working exclusively in "vi," so there is that.

Use QtCreator IDE. Check the videos here: indilib.org/developers/developer-manual/...ent-environment.html

You can then put breakpoints and just check the overall workflow. GuideXXXX are called from INDI::GuiderInterface. In the INDI control panel, you'll see the Guide tab, and if you go there and just put a value (in ms) in any direction, the corresponding guide function should be called. Let me know if you have issues with getting QtCreator up and running.

Thanks,

I've been using NetBeans, as it does C/C++, though it is more of an after-thought as it was my primary Java platform. If you are all using QtCreator and there is indi documentation based on that IDE, then I'll go there. NetBeans has breakpoints, but I've more or less jumped in the middle without taking a look at a roadmap, so I don't have a feel for where to place the breaks. I've been doing a work-around by inserting log comment points that identify where the program went or didn't go.

QtCreator is a simple apt install, as I live in UNIX or Linux. I'll see how that goes.

I should also mention that the approach I was taking with PHD2 was basically the same as entering the values in the INDI Control Panel. It should have moved the scope and did not. The commands did make it through indiserver and into the logs, but somewhere between there and scope operations there is a hole in the bucket.

The guiding section of indi_skywatcherAltAzMount had been commented out with a notation that it was not production ready. There may yet be a piece that remains commented out that I have not yet found. I should know more by tomorrow.

I found today where the routines I was concerned about were being called. After a re-compile and a bit of messing about adding comments, they suddenly have started throwing log entries. I have seen this before when Windows and UNIX coders were both working on the source files. Sometimes the difference in newline and other characters that get saved with the files causes gcc and other compilers to do odd things. Alternatively, it might be aliens. I'm not sure of the root cause, but I haven't changed any "real code" yet, other than ripping the Park/Unpark code out. This could be good news, and perhaps means that what is left is value tweaking between the driver and mount...though I am seldom that lucky.

QtCreator is very similar in operation to NetBeans for C/C++ projects. I think I'll stay with NetBeans for this project, as QtCreator puts things where I am not looking for them and other things I am looking for are not where I expect. I am able to compile the code with QtCreator, but I am fumbling around the feature set.

I spent a few hours on the SkyWatcher Alt-Az driver today. Had to partially setup my 16" Orion SkyQuest Dob to test this. Many fixes were made to make me finally use the Dob the way it's suppose to be. Two things are important:

1. Start in home position. That means telescope pointing NORTH. For some my dob, the OTA would be HORIZONTAL and LEVEL with ground. In essence, the scope should be at Az = 0 and Alt = 0
2. Make sure it gets the correct location and position. This is done automatically by KStars, but I noted I had to set to GPS for testing before and I was trying to understand why it's not working since there was no GPS.

The new driver is now 1.2 and should be available in the nightly repo tomorrow. Please also git pull and this. The changes are listed in commit aeba92ac67f0f8afec53b96cd00d41f17c2f1359

Things I didn't test:
1. Alignment Subsytem. I'm going to need to set a camera on it and see if it works with astrometry like EQMod.
2. Guiding. The guiding & tracking code in the driver is quite complex and I decided to leave it for now.

Knro,

I stripped out a lot of stuff and have a very good working version of indi_skywatcherAltAzMount. I did some serious testing last evening (no clouds) and it performed flawlessly for GOTO, SYNC, TRACK and with Astrometry for Plate Solving. The Guiding is broken, and I am about halfway down the chain in tracking down why. By broken, I mean that now it does not move the scope at all, nor does it error or cause any issue. Parts of the guiding code are running, but the scope remains unaware.

I found a lot of issues with the Park/Unpark functionality. Several chunks of exception handling code and work-arounds. I ripped it all out by the roots and along with it went the unreliability in GOTO. I see no reason to put it back in for a Dobsonian. My startup workflow goes like this now:

- Point the scope somewhere (anywhere)
- Turn the scope on and connect the drivers/computers/cameras
- Take an image
- Plate Solve the image
- SYNC the mount to the solved image
- Go happily on with life...no additional setup needed...GOTO any target

When finished, I just turn stuff off. No need or value in parking portable scope.

Thank you for all your efforts in this matter. I look forward to viewing your code to see your changes. Did you find the root cause of the GOTO instability?

I am going to continue on with Guiding. It's really important for an Alt/Az mount as even very good tracking is not...well...not very good from a photography standpoint.

I understand the value of starting pointing at a "HOME" position of North and Horizon Level. This is the only reasonable option if you do not plate solve, and is a good starting point in the beginning. The SYNC and GOTO work reasonably well, however and it pains me to think how much time I wasted before I got around to plate solving. The only issue I found (testing with KStars and Carte du Ciel) was that care must be taken in the Astrometry setup to keep the resolution time low. Tracking is not enabled during the solving and if it takes a long time, one ends up with more near miss solving iterations than convenient. This due to the drift over the time waiting for each solving solution.

It seems many programs that are "indi compatible." PHD2 as a perfect example, do not properly initialize indi drivers. In the case of PHD2 when not used in conjunction with Kstars, neither the camera nor mount load the configuration. Also, time is not set. This can cause some of the instability in operations and is not the fault of indi code.

@knro:

Looking at the code now. Interesting!

The Virtuoso code was my next target for root canal.

The TTY error is tedious, but harmless. It basically just clogs the log files. I am using the WiFi UDP connection, so I just try to ignore the error. Probably, that check and warning should be disabled by the ETHERNET switch.

I missed that SetEncoder issue. Interesting that it didn't bite me.

The startup thing was not an issue after I deleted the Park code. I am going to try your version tomorrow evening (weather permitting) and add Park/Unpark to my startup (if I must) as long as it doesn't require me to do an initialization with the star align. I much prefer to just point the scope and start with a semi-blind solve. My two cents: Park/Unpark is vital for some and just an added step for others (such as myself). Perhaps that functionality deserves an Enable/Disable switch.

The alignment code worked very well with my version, excepting that with tracking off and a long solve (1 minute or more), the fine adjustments couldn't keep make much headway against the drift. Once it got a localized solve (8-10 seconds) it did better but frequently took too small a bite in the adjustment, taking many more iterations than necessary. I assume, based upon what I see, your changes should not have changed that performance. My guess is that "sneaking up on the target via multiple iterations" is more of a parameter issue than a code issue.

I am looking at the guiding today and will post my results later.

Thank for the feedback Jon. I wanted the driver to be similar in EQMod. i.e. on startup, it assumes to be in HOME POSITION. For equatorial mounts, that looking at celestial pole with counterweights down. For Alt-Az, that's looking north/south with telescope at horizon level (zero altitude and azimuth). From there you can slew anywhere and then capture & solve and it should be the same as EQMod. But I never tried it yet in this manner as it's been raining here for a week, and setting up a 16" Dob is a chore.