Opening a new thread about mount modeling as Im hijacking this thread which needs to continue!

Toni,

any chance of this:

"Your current beta works fine when set to differential which is my default mode anyway (and I suspect anyone with a paramount and probably 10 micron). Certainly far better than 3.6.8. Any way to get that published so others can work with it?"

If the Sync did nothing, then the scope won't move as it's pointing there already. And indeed it looks like it did not do anything.
Indeed, that is an explanation with much higher probability! The assumption of inoperable syncs would explain also that Bryan could do syncs which didn't corrupt the TSX model! @Bryan: Can you check the operativeness of the syncs?

I have a feeling that TSX is rejecting external syncs altogether. Ive looked for a setting that governs this but I can't find one. I think everyone with a paramount (maybe 10micron) needs to be using differential slew only and ever

For posterity and clarity, I will post on the TSX forums and ask (as well as some additional searching on this topic over there)
If anything comes of it, I will report back. It seems like paramounts should be able to operate without a model and act like any other equatorial mount in handling syncs, or even using an external modeling program.

Side note what would happen to the thread if I changed the title? It is inaccurate, and others may benefit in the future from it being correct? Ive never changed the Subject before, but I didn't want others following this thread to lose it.

Bryan

"Your current beta works fine when set to differential which is my default mode anyway (and I suspect anyone with a paramount and probably 10 micron). Certainly far better than 3.6.8. Any way to get that published so others can work with it?"
I want to do one more test in the coming days with my equipment (the weather forecast looks good for weekend). Then I will talk with Jasem, if the changes can be merged into the current master of 3.6.9beta. This way they would be available in the following nightly builds.

For posterity and clarity, I will post on the TSX forums and ask (as well as some additional searching on this topic over there)
If anything comes of it, I will report back.
I'm very interested in the outcomes and looking forward to hear more from you.

Never mind moved to new thread ...

The changes for the option "Differential Slewing" are incorporated into current master of 3.6.9beta. If I understood Jasem correctly, this master goes stable in less than two weeks.
Thanks to all (and especially to Bryan) who helped track down the issue. I hope imploringly the issues are overcome now. But don't you be hesitant to report further problems. Without a real device like Paramount or 10Micron it is not easy to debug. Thus every feedback is welcome!

@Bryan: It should be possible to change the subject of the topic without any side effects.

Thanks Toni and Bryan, I’ll see if I can figure out the nightly build and have it ready for my 10u.

I think I made this thread. If you tell me what you’d like the thread name to be I’ll change it.

Toni, I had issues with my NVME SSD at the observatory installation. Ive had a friend image stellarmateX to my X86_64 mini pc. Do you know if your changes are in stable yet? Having not used Stellarmate before Im assuming i can back up kstars binary and install your test one in the mean time if not? There is a Stellarmate Beta channel, but Im not itching to introduce other problems with a platform Im not entirely familiar with.

Thanks for any info on this.

Bryan.

Do you know if your changes are in stable yet?
Yes, the changes are in 3.6.9 stable. EDIT: The changes are not part of 3.6.9 stable anymore!
Unfortunately they are not in the current master anymore. The chief developers didn't like the fact, that you have to perform a "Goto" prior to a [Capture & Solve] with "Solver action" option "Nothing". I made some minor adjustments, so that with said option a "Goto" is not necessary anymore. I hope they will put the adjusted MR into master again.

I don't recall having to do that in the test version. So you are saying it's only an issue if the solver is set to nothing? Or that before i do anything in a session I have to do a goto, then solve with it set to nothing before it works properly?

1. So you are saying it's only an issue if the solver is set to nothing?
I'd say it not an issue, it's more a habit. There are users who want to unpark and activate directly a [Capture & Solve] with option "Nothing". (Frankly speaking I never understood the purpose of this. Perhaps to calibrate the encoders? I don't know.)

2. Or that before i do anything in a session I have to do a goto,...
No not for anything, but yes if you want to do a [Capture &Solve] with option "Sync" or "Slew to Target". With these options you have to set an object in order to fill in valid coordinates. (In place of a "Goto" it could be an equivalent command which sets the target coordinates.)

3. ... then solve with it set to nothing before it works properly?
No, not at all!

Another controversial point is polar alignment adjustment (PAA): Lots of users are used to do an PAA after unparking the mount without selecting a target. (Which of course is possible, since there is no target.) Because of point 1. and since PAA is using an internal [Capture & Solve] with option "Nothing" I adjusted the new MR to work without selecting a target.