When issuing slew commands, the INDI driver sets a hard-coded speed for both high speed (far away) and low speed (close) moves. There is code like this:

Both minperiods and lowperiod are hard-coded values. minperiods is set during initialization. If you want to hack on the driver, you can try changing that value and seeing what happens. Note that bigger numbers means slower movement.

I'd try it myself, but my mount is outside under a cover during a rain storm right now, so I can't test it.

Hi Kevin,

this would be great and means the Indi driver controls all the slews, including gotos, directly, right?
I will look at the code and try to change.
I think relevant is the uint32_t minperiods[2] used for high speed - it is currently set to 6, which I assume corresponds to the max. speed of the mount (this what it's using when executing.a goto).
I'll try to compile and use with value 7-9.
ok, any other side effects I should be aware of?

Regards,
Mariusz

Hello Kevin,

so, I have updated the skywatcher.cpp as advised by you:

Line 415: minperiods[Axis1] = 12; //6;
Line 416: minperiods[Axis2] = 12; //6;

Recompiled and installed the driver. The change is being used as evidenced by the log file entry:
DEBUG 0.287078 sec : InquireBoardVersion(): MountCode = 35, MCVersion = 30e23, setting minperiods Axis1=12 Axis2=12

Unfortunately, there is no noticeable change in the goto slew speed, i.e. still at its maximum (800x as shown by Ekos).
Attached the log files with the debug level active.


Let me know your thoughts - do I need to be more aggressive with the value? Like 50?.

Regards,
Mariusz

Hmm, sounds like that's confirmation that the speed that is set is ignored. Bummer. I was hoping that would work.

yeah, pity it didn't work -looks like back to square one, i.e the EQASCOM way (use manual slew) is the only solution due to the black-box firmware, unless you can think of a different way?

The firmware has "fast goto" and "slow goto". Maybe try forcing it to always use slow goto. Maybe then it will honor the speed setting. Even if it doesn't honor the speed setting, it should move nice and slow

Thanks Kevin for your insight - how to activate the slow goto? Where can I read more about it and the firmware?
I really would like to stay on ekos and save the pain of setting a NUC with Window$, but this may be the only way to have my mount out in the backyard. It is also frustrating the vendor does not move a finger on what is presumably a simple change - Celestron apparently does allow to set it and it's the same Co.

In the SlewTo and AbsSlewTo methods, you can see it checks to see how far away the target is from the current position. If it's beyond a certain threshold, it uses fast mode, otherwise slow mode. You can try skipping the test and just always using slow mode.

Something like changing this:
to this:
There are similar checks for RA and Dec. And the change would need to be made in AbsSlewTo and SlewTo methods.

I'd do it myself, but it's still raining here, so I don't dare take the cover off of my mount to test it out.

Thanks Kevin, will check tomorrow (have my mount indoors, it's raining here too), although do not have high hopes for the driver level control of the goto slew rate.
Btw. I've checked the Celestron CPWI User Manual and there the user can change the goto slew rate:

Custom Rate 9
Your telescope slews to objects selected for GoTo at motor speed Rate 9. Lower the Rate to conserve battery life if you are using an external power source. Raise the Rate to slew to objects as quickly as possible.

The comms syntax for GOTO commands looks identical to the one of SkyWatcher but I cannot find the goto slew rate set function like the above-one in CPWI (

Mariusz

Hi Kevin,

I've recompiled skywatcher.cpp with the suggested changes but see/hear no change in the speed of the goto/park movement - any other ideas?

COMM 232.060154 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.060251 sec : StartMotor() : Axis = 1
COMM 232.060453 sec : dispatch_command: ":J1", 4 bytes written
COMM 232.061585 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.061681 sec : SetMotion() : Axis = 2 -- dir=backward mode=goto speedmode=lowspeed
SCOPE 232.061834 sec : CheckMotorStatus() : Axis = 2
COMM 232.061971 sec : dispatch_command: ":f2", 4 bytes written
COMM 232.063120 sec : read_eqmod: "=101", 5 bytes read
MOUNT 232.063220 sec : StopWaitMotor() : Axis = 2
COMM 232.063373 sec : dispatch_command: ":K2", 4 bytes written
COMM 232.064089 sec : read_eqmod: "=", 2 bytes read
COMM 232.064278 sec : dispatch_command: ":f2", 4 bytes written
COMM 232.065249 sec : read_eqmod: "=101", 5 bytes read
COMM 232.065442 sec : dispatch_command: ":G221", 6 bytes written
COMM 232.066237 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.066332 sec : SetSpeed() : Axis = 2 -- period=18
COMM 232.066531 sec : dispatch_command: ":f2", 4 bytes written
COMM 232.067748 sec : read_eqmod: "=201", 5 bytes read
COMM 232.067916 sec : dispatch_command: ":I2120000", 10 bytes written
COMM 232.069119 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.069275 sec : SetTarget() : Axis = 2 -- increment=470729
COMM 232.069487 sec : dispatch_command: ":H2C92E07", 10 bytes written
COMM 232.070794 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.070890 sec : SetTargetBreaks() : Axis = 2 -- increment=200
COMM 232.071095 sec : dispatch_command: ":M2C80000", 10 bytes written
COMM 232.072358 sec : read_eqmod: "=", 2 bytes read
MOUNT 232.072455 sec : StartMotor() : Axis = 2
COMM 232.072657 sec : dispatch_command: ":J2", 4 bytes written
COMM 232.073717 sec : read_eqmod: "=", 2 bytes read

Hi Kevin,
my mount has firmware 3.14.23 - there has been few updates since then, and one of them says:

Version 3.23
1. Fixed a bug with the SET_SPEED extended command.

Can this be the cause for my mount ignoring the speed setting?
Do you recommend an upgrade?

Thanks,
Mariusz

Hello,

so, to answer my own question: I've upgraded to 3.23 but it changed nothing concerning the use case.
Hope, Kevin will get some clear weather to try the code change suggestions - the weather is getting better here

Cheers,
Mariusz