james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 20 hours 46 minutes ago

kbahey wrote: Did anyone diagnose what the source for the precision slew never ending problem is? Or at least what conditions trigger it?

For example: Could it be when the backlash compensation setting is more than the required precision?

I have seen it several times, but can't seem to get a pattern of when it would happen.

So far I haven't found it. Though I give my mount a bit to settle (I have a bit of backlash which I haven't taken the time to properly setup. So that could be a possibility...)

Also, can you check if it's got Pulse Guiding set to ON (Main tab, I think)

I just pushed some changes to enable the outputs, and hopefully satellite tracking (Not 100% sure that it will work yet.) to azwing.

I've only been able to get outside one time when it wasn't cloudy, so I haven't been able to test, unfortunately.

There's also this checksumming which I think is good. Might resolve some problems, but does mean that we'll have to re-implement some of the LX200 stuff (or we could restrict that to just things like guiding/moving and see if that resolves the issues?

After more testing that setting seems better but still less than perfect. I also don't like the idea of having to worry about what lwIP the Wifi is using...

Since the main problem is with IP commands that don't have a reply I could have added new (guide) commands that reply with 0/1 (fail/success) to overcome this. But that's sloppy and there is another way... change, or rather add to, the command protocol. In-fact checksum code has been latent in OnStep since the early days when it was used briefly....

Traditional LX200 command framing ":#" c=command, p=parameter...

Some commands have no response.
Some responses are one numeric char, mostly 0/1.
Some responses end in #.

The new OnStep checksum LX200 command framing ";#" c=command, p=parameter, CC=checksum, S=sequence check...

So I've added checksum protocol to OnStep.
All command have a response and end in CCS#. rrrrrrrrrrrCCS#

For the ASCOM driver/Android App:
If the checksum on cmd data arriving at OnStep fails it replies with a re-transmit request.
If the checksum on reply data arriving at ASCOM/AA fails (or we get a re-transmit request) it sends the command again.

For other LX200 protocol Apps they function as usual but obviously no semicolon ";" except as a command frame can be in the data if this is enabled! I'm not aware of it being used in any LX200 command but user site names, user catalogs, etc. can't have it.

To use this basically the whole OnStep software stack needs to be updated to the latest (Alpha branch) and installed (including Wifi if you want checksum over IP and the ASCOM driver.) This isn't going to work with INDI unless the powers that be decide to implement it.

In ASCOM the standard methods etc. generate checksum commands but also the passthrough (commandBool, commandString, commandBlind) re-encode to checksum so special features, like the guide commands move :Md# and stop :Qd#, are handled.


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

azwing wrote: @ James

Alignment limits:
Checking the Alignment model capability via the ":A?#" command since first digit returns MAX_NUM_ALIGN_STARS should be the way to do.
But in OnStep this is either 4 or 6, I don't see it set to 9 somewhere.
Reading this value during driver init could help to set the range between 1 and MAX_NUM_ALIGN_STARS in the control panel.
But when working with Ekos I still don't see how to use this except leaving it up to the user.

Ah, the stupid things overlooked on late cloudy nights. >_< I really need to review the alignment again.

We can alter the numbers in the switch based on that (an example of that is the focuser1 values) so detection of that should be easy.

Write to EEprom Button:
Even if the Write EEprom button is not necessary for the alignment process, it should be present to allow user to trigger the EEprom write.

Detection of boards:
The ":GXnn# Get OnStep value" could cover board detection.
It returns a lot of information but not the board type as far I could see in the code. May be we can ask Howard to include that?

The above would take care of that. As someone mentioned it's better to do the general case than a board by board.

Ekos related:
Part of your answer exceeds my English.
So far what I undertood:
"I mainly wrote that quickly to test, and avoid the whole popups on goto. Frankly, I want the whole "Push this button to auto align it, and have it perfect." in Ekos."
You would like to have one button that starts an auto align with Ekos without user intervention?

Ideally, yes. Though I'd want to watch it. That's essentially what the mount model is going towards.

"I think there's a bit more we can do with Ekos/INDI mount models possibly calculating the alignment and feeding the numbers OnStep needs to it, which eliminates the issue of speed as well. "
Use Ekos Mount Model to Download values to Onstep instead of doing calculation in the Firmware?

"I've found Ekos/INDI amazing.. if you know what's already been done, and doing it the way the other things do the 'right' way for interfacing with other things."
Sorry, I am lost here, don't understand.
If you mean we should use as much as possible what is already existing in Indi/Ekos, I fully agree.

What I mean, is that there exists www.indilib.org/api/md_libs_indibase_ali...ent_white_paper.html However, I'm not sure if it's the same (It should be extendable to replicate what is in OnStep, or to use others and have OnStep be sort of a dumb interface (which are the options that Eqmod seems to use from looking at it.)) If you look at that page, you'll understand why I haven't done it yet. ;) (Especially, with my apparent reading skills lately :lol: .)

As far as temp sensors, unfortunately, there's not a good interface to tie into. I was looking at that for images and recording it, because my CCD doesn't have a temp sensor (or at least none of them expose that functionality that I'm aware of.) Unfortunately, Ekos as just reading the CCD's temperature. Which is something that would require a fair bit of work to deal with, to add throughout several things. Displaying it would be great though.


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

Sorry I haven't been that responsive.

pretty much kbahey is correct, with one exception:

Mega should be fine, if you note, that things are restricted. (HAL_SLOW_PROCESSOR) so it shouldn't take too long, even if using more than 3. (I don't think it ignores them, but there are a few values that are calculated differently.)

> James, can you please confirm that this is the case?

Correct, if we don't need it scripted, and the dialogs, and can just use the mount model, then we should be good.
AW will save it, so if parked, it will be able to restore it. I just went back through and it seems to be fine, if it's not used. It should be added, but it's not critical.

So as far as I see the TODO:
- leave the current stable code as is just adding user choice for number of alignment stars
Align number of stars should be: 1-9 based on the code. (I don't think we can detect if it's a HAL_FAST/SLOW_PROCESSOR, but I'll look at the get onstep values, which could restrict that, for the most part it's compensation for more error.)

- add a "write to EEprom" button

Personal TODO:
Look about detection of board, and what aligns are supported. (HAL_FAST uses 4 or more, I think SLOW is limited to 3
I do have some pulls to do, adding accessory output support, but I screwed up the git branch, which is always fun.

I mainly wrote that quickly to test, and avoid the whole popups on goto. Frankly, I want the whole "Push this button to auto align it, and have it perfect." in Ekos. ;) I think there's a bit more we can do with Ekos/INDI mount models possibly calculating the alignment and feeding the numbers OnStep needs to it, which eliminates the issue of speed as well. (That's a really quick look a few weeks ago, and I need to do more reading on that before saying it's possible or not. I've found Ekos/INDI amazing.. if you know what's already been done, and doing it the way the other things do the 'right' way for interfacing with other things.)


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

PEC data will be fine. The commands return it one byte at a time.


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

I can't say I've seen that for Onstep, but I have for other things usually because I do a make && make install, instead of the full build process. (Cmake etc or make clean.)

I don't think I touched anything that hasn't been committed, or that would deal with connection.

Unfortunately, it'll probably be a bit before I can look at it. Feel free to back things out if it's crashing and I can look at it later. (Vacation, and my laptop picked now to have the battery fail. Stupid failure mode of degraded = permanantly won't do anything.) I have another tablet, but it is a tablet, so I'm not doing much coding on it. It is up to date, I think (I synced it when I left and didn't notice failure,) with my master though.

Thinking about it this morning while driving: If it's in your branch it's gotta be PEC. I don't think the align got pulled. Maybe the PEC status check?


james_lan replied to the topic 'PECInterface' in the forum. 3 months ago

I'd certainly patch EQmod if I did this. (Mind you I can't test it on Eqmod, or any of the others. Excluding software (I don't have a new enough autostar, or advanced enough nexstar)

I'm looking for anything I missed as well.

So far on breakdown of what can/should support these things:
PEC_PLAYBACK: Many/OnStep/Eqmod/Autostar II/LX200 GPS/NexStar
PEC_RECORD: OnStep/Eqmod/NexStar
PEC_MANIPULATION: OnStep/Eqmod/Autostar II/NexStar

(NexStar based on finding it in libnexstar, haven't checked INDI.)

There's also the software PEC, which seems like a good ideas as mentioned in that thread. Should that be done as an Ekos module? (I'm not necessarily volunteering to write it, but wanted to make sure that it could be handled by the same interface, so I probably need to add a playback from file.)


Jim thanked james_lan in topic PECInterface 3 months ago
Jasem Mutlaq thanked james_lan in topic PECInterface 3 months ago
james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 months ago

Blueshawk wrote: I see! I'm more sure than ever we have parallel operations going on. I'm going to hold off a bit but weather permitting I'll try that in my mega when I get the chance.

That's correct.

kbahey's solution is to have sync call the align function, and is a better solution, because it enables the mount model without issues.

Mine does that manually, with the current Alpha. Unlike azwing's original align code, It doesn't care about only going to the stars that OnStep would accept, which was required, before the change to the geometric align. Thus why I said use the Align tab (Which should still work, but requires it to be done the old way.) or the original.


james_lan created a new topic ' PECInterface' in the forum. 3 months ago

Right now, INDI has support for PEC playback in a number of drivers, but recording is limited to only EQmod and soon OnStep. Rather than have a whole batch of this that and the other,

Similar to a FocuserInterface or GuiderInterface, I'd propose something like this:

//axis 0=RA, 1=DEC, others?
IPState StopPECPlayback (int axis);
IPState StartPECPlayback (int axis);
IPState ClearPECBuffer (int axis);
IPState StartPECRecord (int axis);
IPState SavePECBuffer (int axis);
IPState PECStatus (int axis);
IPState ReadPECBuffer (int axis);
IPState WritePECBuffer (int axis);
bool ISPECRecorded (int axis);
//End PECInterface

Variables: (OS is for OnStep, that'd be removed) for each axis.
ISwitchVectorProperty OSPECStatusSP;
ISwitch OSPECStatusS[5];
ISwitchVectorProperty OSPECIndexSP;
ISwitch OSPECIndexS[2];
ISwitchVectorProperty OSPECRecordSP;
ISwitch OSPECRecordS[3];
ISwitchVectorProperty OSPECReadSP;
ISwitch OSPECReadS[2];

As well as change enum TelescopePECState
PEC_OFF = 0,
PEC_ON = 1


enum TelescopePECState
PEC_OFF = 0,
PEC_ON = 1,

To allow for recording, and notifying when waiting for an index point, which is how several telescopes do it, rather than encoders. (Depending on the worm ratio, that can be a state something is in for a while.)

I wanted to get feedback on this before presenting it as a code proposal, in case there are methods or things forgotten.

The two main methods of PEC seem to be:
1) Hall switch/visual interruptor/microswitch - Single index used, which is the case for OnStep, Meade LX200s (Smart Drive), NexStar(Can't confirm, but seems to be the case)
2) Encoders - Not sure what uses this (OnStep can use them if there is an index pulse.) Some Meade LX200s?
OK, 3
3) Virtual - It keeps a record of where it is, then records it, but has no index to base it on. Surprisingly Eqmod apparently handles it this way ( eq-mod.sourceforge.net/docs/eqmod_vs-pec.pdf ) though I thought it interacted with indexes as in #1, and OnStep can, if there is no index.

Note that as far as recording, some telescopes do not provide methods to record in their protocols, for example the LX200, where you can read and write PEC data, but not trigger a recording. So as far as flags:


Overall, it's a fairly simple thing, but the Eqmod people have implemented recording one way, I'd like as person #2 to make it implemented in a better way for #3+, etc.

So thoughts, or should I not bother, and just implement it for #2, similar to #1? (I have had more detailed suggestions written up, but I'm about to not be able to work on it for about 2 weeks, so I wanted to let people comment on it.)


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

kbahey wrote: I have code inside OnStep itself that allows the use of the Ekos Mount Model tool, without any changes in OnStep INDI.

Basically, alignment is started from INDI with, say, 3 stars. Then Mount Model is configured to align on the same number of stars. As Mount Model slews to the stars selected, it takes images, does a plate solve, and sync on the coordinates of the solution. With my change, OnStep detects that an alignment is in effect, but not yet completed (i.e. :A3# started, but not enough iterations of :A+# done yet), and the :CM# internally calls a new function that mimics a :A+#, and this repeats until all stars are plate solved and aligned to.

This requires my branch (see link below), which is a fork from Alpha, since the latter has the new alignment code that allows alignment anywhere in the sky.

The workflow would be: in INDI, click Align 3, then go to Mount Model, add 3 stars, and let the mount process them (slew, take image, do plate solve, and sync to solution coordinates). By the time it finishes, the Alignment line in INDI should show 633, meaning 3 stars requested, and 3 stars completed.

Here is an overview with links to the pull request.


If someone can test it that would be great.

I probably can't test that for a while, but it should be good. I did test two nights ago, and it worked ok. Better than I've had before, though I noticed a bit of slack places, which has been corrected, so it's probably not as good as it could be.

I did it fairly simply. Locate, Solve/Sync, move to next. It was off by a bit, then wrote it. Only had 6 targets, and the goto was off on the last one, but I think it was after the 4th one. (Should have started again.)

Here's the results:
Note this was on a Mega, I don't think that played with it. (Started with NCP in shot, not quite sure how good my polar align was (no polar scope.)) It was cloudy last night, and I'm going to be doing things next week and the week after that, so I likely won't be able to work much on it.

kbahey's solution is a lot more elegant. I could see adding a sync command to enable that mode, because someone might want to not use that method, or as a define.
(:AI# or something)

Blueshawk: Note that the Align tab is intended for the setup added in the Alpha branch only, this month! So if you haven't updated OnStep since the new align code has been added, I'm not sure what to expect. If you do a goto, and that object isn't centered, then I think it would record the wrong target. (ie, whatever you hit goto on, rather than the sync. I'd have to look at the now-Beta code, to see.)


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

So I've implemented it to test that (took longer than expected to write), It's in my master, and a pull request with it has been submitted to azwing.

It adds a new tab. Use either the existing alignment (Main), OR the new one. (I don't think anything terrible will happen, but since they mess with the same things in different ways...)

Follow either the Manual setting or the Semi-Automatic one:
Hit Start

Per star (up to 6):
Manual: Goto and then center.
Automatic: Goto then plate solve
Both: hit 'Issue Align' (I should probably change the name)

After what you are comfortable with is done hit Finished Align.

It does NOT currently: Give message if align points are accepted, It will however, give an Alert (red) if it fails. I will add that.
It does NOT currently: Count the starts, or provide feedback via :A?#
It does check if the finished works. If not, it will give you a "Align WRITE FAILED" in the status portion

Let me know if that works for people, I'm going got out to test it. (On a Mega, so it might still have some issues.)


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

As far as the alignment, there's also another option which is to use INDI's model, to then update OnStep's. I think this is possible, but it'd be a lot more work. Given the power, I think it might ultimately be a better option, for things like Megas (which are restricted in the new code.) However, that's a batch of research to double check that it will work and to set it up. (If it does, then any change in the alignment setup will mean changes needed to do.) I think your solution is a lot better for getting it working.

Alright: So opinion time:
Here's a proposal for the UI on PEC. Top two are informational. I'd reuse the standard PEC control on the motion tab. (Which currently does nothing.) Or should I dispense with the PEC that inditelescope has, which can do exactly 2 things: Turn it on and off, and have it show there? (Actually I could probably as well.)

Should it also display more information?

Of note: I think that some of this should be incorporated into inditelescope, or a PEC Interface. But, as far as I can see only EQmod has anything like OnStep's capacities. Including triggering recording. For comparison I included a screenshot of EQMod's PEC training/enable tab. (To note, you have to modify code minorly it to get that to show up on Simulation.)

I'll probably get the PEC training fairly soon. I also wanted opinions on the file format: Should it just be a raw dump without anything, or should it have data fields, like the information (buffer size, worm size, steps a second, etc) and verification on restoration? (Which will make it more complicated, but possibly made in a format compatible with tools like pecprec ( eq-mod.sourceforge.net/pecprep/ )) Which is noted as a tool that works with OnStep/ASCOM


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

I think you are right with the PEC. That's on my list next. Including training.

When I looked at it, it never clears it, so if the storage has been used before, it will have whatever is on it. So agreed on it should default to off.

The other thing is the alignment in the Alpha branch which is changing. I think the plate solver can be used to make it easy.


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

BlueShawk: I fixed the focuser in my master. (Implementing sanity checks is only good if you implement good sanity checks. Checking if it's below the min isn't great. Oops!)

Azwing: Made a pull request, so you can merge it in.

One thing to note: When looking through the onstep code itself, there's no way to verify it that I can tell, as the variable it alters is used for the calculation of the sidreal rate, which everything is reported relative to.



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!