james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 7 days ago

Yes, that's related to the dew heater, and the new detection of features.
The gxy1 call should return the feature name and type.

It appears to be looping, but I'm not in front of the computer to look at the code. (Quickly looking at azwing's repo, I don't see anything that I would think could cause it, except repeated calls to update properties?) For a temporary solution, you might try removing that feature?


The only reason it shouldn't update that are common. Either it should get a location in UpdateScopePosition, or it should fail in both cases, as that code is at the very front, do you have any: Error reading RA/DEC. messages?

I'd very much like to get a debug log if you don't mind, because I can't seem to reproduce what you have.

I do discover some odd behaviour with parking on a (fake) alt-az mount, namely that it seems sometimes to goto after an unpark?! (To where it was before the park.) Never have seen that on an EQ. I'm looking at it, but a log would be great to try to figure it out. I do seem to recall that as being something a while back though that I'd very occasionally encounter on startup?


Given your changes, I'd like you to look at the own-goto branch as it now has the changes so there should be NO status set from base classes. So it should be only update by our update, and should be consistently reported, and avoid the TrackState IDLE after a park.

I apologize for being quiet, and stepping on your toes about it, but I think it's actually a better solution. Unfortunately a lot of that delay was me upgrading and various changes. (Mostly related to me compiling things outside the package manager, and forgetting, plus resolving what turned out to be insofar as I can tell, a bit error on my SSD. (I don't think I've knowingly encountered that ever on a HDD, but might have if it's in data that's not processed by computer.)

The one change that I don't have in that branch is the Focuser hiding, but that seems to be pretty simple to add back in.

Unfortunately, KStars/Ekos does not pull directly from TrackState, so that didn't resolve the mount model issue. However, digging into it, it relies on EqNP's status as part of the Update using the TrackState. I've added updating that to the section after TrackState, so that should always be good as well. So finally solved? (Maybe.)

So far in my testing, That has eliminated all IDLE states when it's not actually idle except the very initial connect, and so far all instances of the Mount Model taking an instant photo. (Using an OnStep board, and CCD simulator, so that's limited testing and of course things are supposed to be not conducive to testing in the real world for a bit. ) So I think all of that is fixed, but not 100%. I do know in one case with TrackStateSP, there's something lower down that wants to modify it if slewing, so I had that only update if SCOPE_TRACKING to be on.

Anyway, Sorry for going quiet, now trying to catch up on some more things. (So I may be quiet again for a few days.)


From a glance it seems like it's going to cause extra state changes on certain codes with regard to parking (calling setParked(x) results in a change to either PARKED or IDLE, and a variable IsParked being set (accessible through isParked()) and I think that's changed in the past.

Issues with what you've got:
F shouldn't change TrackState. (Park failed, but the state should be processed via n/N )
p and nN only, if it's pn, it'll produce TRACKING when it should be IDLE (here again state should be processed via n/N)
Not sure why the myTrackState?

That own-goto branch of mine, I didn't handle it right, either, when I looked at your code: (F, I and p should be moved in my code before the n/N/P processing, because of the potential call to setParked(false) in them, which could result in an idle state.) Basically moving up the ==parkdata== / ==end...== section should have fixed that issue. (I have pushed the branch, but not tested it, as I need to get away from the computer for a bit, as I keep looking and running through the same logic and questioning it, so I'm going to stop and come back in a while so I don't break anything too badly.)

Please have a look though: github.com/james-lan/indi/blob/own-goto/...ope/lx200_OnStep.cpp (Note it doesn't include IsNewSwitch() settings which can change it.)

Note the multi unparked in ( indilib.org/forum/development/1406-drive...html?start=660#73262 ) should be resolved in the current version, as each call will set status, but will only correct the internal parked variable when needed. (That I have tested some, and so far I haven't had issues with it.)

Issues/TrackState manipulation remaining with mine:
Scope may get set for a split second to TrackState=SCOPE_IDLE when unparking, but that will be correct shortly thereafter within the function. due to the call to set IsParked
Same with parking (but to the correct TrackState=SCOPE_PARKED) so non issue

One thing that could be done is skip the OSStat == OldOSStat check. That would resolve the sync issue and why when you start/stop tracking it gets corrected. (With the isParked() guards around it shouldn't cause any issues for the correct things to be set with regards to TrackState, not sure about the rest of it.) So we'd need to make sure things don't cause issues like messing with TrackState can, but that I think is probably the best case. But it could mask TrackState and other issues as well.

Alright, I'm off, let me know what you all think. (Apologies, I left this up last night, but aside from me being less tired everything else should be the same.)


Here's what I've got, with everything together to handle the TrackState (unparking handled down below) There aren't any other TrackStates assigned.

if (strstr(OSStat, "P"))
SetParked(true); //defaults to TrackState=SCOPE_PARKED
TrackState = SCOPE_PARKED;
IUSaveText(&OnstepStat[3], "Parked");
} else {
if (strstr(OSStat, "n") && strstr(OSStat, "N"))
IUSaveText(&OnstepStat[1], "Idle");
TrackState = SCOPE_IDLE;
if (strstr(OSStat, "n") && !strstr(OSStat, "N"))
if (strstr(OSStat, "I")) {
IUSaveText(&OnstepStat[1], "Parking/Slewing");
} else {
IUSaveText(&OnstepStat[1], "Slewing");
if (strstr(OSStat, "N") && !strstr(OSStat, "n"))
IUSaveText(&OnstepStat[1], "Tracking");
if (!strstr(OSStat, "N") && !strstr(OSStat, "n"))
IUSaveText(&OnstepStat[1], "Slewing");

That then becomes the only handling the lx200_OnStep driver does, but there are some lower levels:

Going through lx200telescope/lx200generic, and trying to cross reference things, the only place it looks like it sets state that isn't overridden is in the init with a SCOPE_IDLE (which seems fine). (Goto and Park (overriden both set it)).

There are some in inditelescope, but I'm not certain I've found them all.

TrackStateSP, will change it.
ParkStateSP will change it as well.

As will the call to SetParked/SyncParkStatus (Changes to IDLE or PARK)

TODO: copy/modify to intercept TrackStateSP & ParkStateSP.
TODO: copy/override SetParked/SyncParkStatus

That will move us to a model of purely from-telescope instead of an assumed command state + from-telescope.

Once those are done, That should mean 100% the OnStep driver has control of the Trackstate, with the above from :GU#, and should eliminate the kstars camera issue.


Note that is only fixed for the issue reported by Serge CLAUS of the state not being right during a goto from indilib.org/forum/development/1406-drive...html?start=648#73196

It may or may not fix the kstars instant camera issue. (Hopefully?)


OK, I think I found it, and it's my bad.

For ref:
// [n]ot tracking
// [N]o goto

Trying to simplify things, I'd removed some parking code which also handled the :GU return in one case (not n or N). The own goto should be updated with that (and unrelated PEC, since the command (:QZ#) used no longer works on newer versions, but that should be good now.)

General cases:
!n !N = SLEWING (tracking, goto) < Case I neglected, since it seems like you wouldn't be tracking while on a goto
n !N = SLEWING (not tracking, goto)
     (If also I (Parking n progress) = PARKING)
!n N = TRACKING (tracking, no goto)
n N = IDLE (not tracking, no goto)

Overriden by
P (Parked, also set parked true) PARKED

Related which only give Messages/not change trackstate:
p (sets parked false) (unparked)
F (sets parked false) (parking failed)
I (sets parked false, case handled above) (parking in progress)
H (messages only, combined with p/P)

Someone want to check my logic to make sure I didn't miss anything?


Argh! Unfortunately that's not new. Sounds like this isn't fixed (I haven't had the chance to test much and it hadn't happened when I did, so the bug got auto-closed):


Can you try the branch own-goto from here: github.com/james-lan/indi/tree/own-goto ? Amusingly, I was working on that for checksum based stuff, and remembered that. That particular branch is the current version with that one change (plus version bump) so it doesn't have the checksum stuff yet.

For a mitigation, increase the polling time. That won't prevent it, and it's annoying, but will reduce the chance of it occurring.

Basically, When I looked at (Kstars has had some changes) It boiled down to a lack of a timer in Kstars, plus the driver relying on the lx200 functions, which set the switch to Slewing, even if the mount isn't yet, and when the status update comes which also sets the TrackState. Under bad combinations of timing: Move Issued and sent - Status update before OnStep changes state, OnStep reports Tracking, driver updates TrackState to Tracking - Kstars goes: Done! Start picture - next update, OnStep reports Slewing, driver updates to slewing, but the image is in progress.

On the other hand we could announce it as a new driver feature: Fastest way to do star trails. ;)


INDI 1.9.1/OnStep v 1.10 should have all of the things up to this point. (Should show driver version under the Connection tab) 1.9.0 / 1.9 will not

It's possible it isn't being detected (and won't show up if it's not), If it's 1.10, can you enable debuging, and search the log file for :rG#, then paste to see if it's detected (example where it isn't):
[2021-07-03T01:19:31.251 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:rG#> "
[2021-07-03T01:19:31.251 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-07-03T01:19:31.252 CDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] No Rotator found. "

If you can figure out, the log on where it's crashing I can take a look at it. (PHD2 seems to just crash randomly sometimes on me, but I'm pretty sure 99% of the time, it's related to my temperamental camera, and when I've dug into logs it's seemed to be that.)


As regards the PEC I/E, I will work on it when I can, but unfortunately, my mount messed up so I don't have one with PEC (Not that it's going to be required for it, but I can't test it.)

As far as the tiny slews, I think I recall that being due to acceleration/deceleration, and a note about that in old config files? I can't seem to find it right now, but you might go browse old git versions. This seems like something that's going to be more an OnStep issue, than the INDI interface. Though if you've got logs those would be good to know. The INDI interface should reflect the state of the driver.

I have had little time lately, (which unfortunately may drop to near 0 again) but did manage to work on two things (incomplete! I haven't even merged them into my master branch yet):
1) Reducing timeouts even more, and general code cleanup.
2) Checksummed commands (which has been working with one of the OnStep Specific things, but trying to convert to a better layout caused a crash that I haven't gotten to look at. Whee!)


Still in the process of getting the outputs done.

I went hunting a little, and found a few things that could be improved. They are now in main repository. (There was a timeout after tracking On/Off, Parking?, The OnStepX focuser type checks had an issue on V3, so I fixed that as well, it'll timeout once there.)

There may be more, I need to look at some of the replies, the main issue is the use of some of the lx200 functions which expect a # string, and OnStep returns either a single character vs a # terminated string, or in some cases times out. I think I've gotten most of them, with V3 to V5.

I also changed the high precision to be off, and implemented the most basic version checking. It will turn on High precision on connect if it sees OnStep, or On-Step and V4 or V5 or in the case of OnStepX. Otherwise it's off with no timeout caused. If you are using an old version of V4/V5 it might not support that in which case it will cause a timeout (once, effectively the same behavior before the changes).

Timeouts that I don't see a way around:
TMC_SPI detection currently is 2 seconds to check for it's presence and a timeout if not present. (This actually will likely go up, as it appears that TMC_SPI which used to be RA+DEC Both or None is per axis now) 

Copying my old todo:
1. Changing the MaxRate replacement (degrees per sec)
2. Intervolometer support
3. Focuser Changes
4. Dew heater
5. Weather support. (Read BME280/etc)
6. Tangent arm support (Plate solve then adjust?)
7. Check backlash values (Changed to allowed to 3600)
8. DC Focuser support (Not sure if that works already or not?) Might need someone who has one to help with this.
9. TMC_SPI reporting support. (I got one for testing, and finally went to put it in on this cloudy night. I unfortunately missed the: You have to have both axis be SPI if one is, so this will be working at some point, but when is a big question. Oops.)
10. Equivalent of MoveAxis support to allow for following satellites. (Kstars issue more likely than OnStep directly, as the custom rates are added in, but Kstars doesn't have a way to send the rates/information, AFAIK)
11. PEC Import/Export
12. Check uses of getCommandString and replace any which might not return with the replacements (getCommandSingleCharResponse/getCommandSingleCharErrorOrLongResponse)
13. Implement checksum for packets See: onstep.groups.io/g/main/topic/27153325

Also, @Jack I just was able to duplicate and found the cause of the Unparking issue, and submitted another pull request a minute ago. It had been set to only read it from a clean state only from when it first connected. After that it would read only specific things depending on the state. (I suspect an artifact from a long time ago, maybe before :GU# had everything including Park status?) I got rid of the conditionals (there is no extra scope communication) so it updates it every update. (Which also isn't perfect (there was/is? a timing bug with KStars on alignment, if it sees a move start, but the status updates), but eh.)

In that case, dome lock was on, so the unlock would fail, but the state would get set to not parked (don't recall what it was, and doesn't matter) but that was/is tracked in the telescope class so it'd go: Hey, you are already unparked. I'll look into it a bit more, in case it's a problem for someone else.


Might be helpful: www.indilib.org/api/classINDI_1_1FocuserInterface.html

This has a much better explanation than the FilterInterface does on how to add it to another driver.

For the most part you just add the FI:: stuff and then override the functions you need to, on that page, you can see which functions get overridden/implemented by which drivers, example of something not needing to be overridden: CanAbort() (since it just reads flags), whereas AbortFocuser() is overridden just about everywhere.