Hi,

I want to make my mount controller skywatcher-compatible. I am currently rewriting the controller firmware and have some questions regarding some details of the skywatcher protocol ; variable names are those of indi-eqmod/skywatcher.[h|cpp].

InquireGridPerRevolution requests number of microsteps required for a full 360° revolution (correct me if wrong) ;
Following 2 are less clear to me :
What does InquireTimerInterruptFreq expect in return and what is the unit ?
What does InquireHighSpeedRatio expect in return and what is the unit ?

Do periods (in minperiod, maxperiod, setspeed...) refer to the delay between successive microsteps sent to the motor ? What is the unit ?

Thank you in advance,
best
--
fm

Hi,
I wanted to reply to your other thread as I had a look last week to your very interesting project, but have been busy.
InquireGridPerRevolution requests number of microsteps required for a full 360° revolution (correct me if wrong) ; yes
What does InquireTimerInterruptFreq expect in return and what is the unit ?
It is the frequency of the timer interrupt used to drive the stepper, so the unit is hertz. If I remember on the EQ6 it gives 64935Hz, which gives a timer period of 15.4 µsec. That is related to the way the motor controller works: it uses a fixed timer period and some counters to determine when to generate step pulses regarding the desired speed.
What does InquireHighSpeedRatio expect in return and what is the unit ?
This is the ratio of speed between low speed mode and high speed mode: in low speed mode the motor controller uses microstepping, in high speed mode it will use half or full stepping. So this is almost the number of microsteps and is used to compute speeds in high speed mode.
Do periods (in minperiod, maxperiod, setspeed...) refer to the delay between successive microsteps sent to the motor ? What is the unit ?
These periods simply refer to the above timer period. For instance the sidereal period on the eq6 is 0x26C=620, the microstep count (GridperRevolution) is 9024000, and if you make the product 9024000x620x1/64935 = 86161.2381sec which is near the sidereal day (86164.1sec). Now to go at 800x, supposing highspeed ratio=16, (86164/800)x64935x16 / 9024000=12.40, this gives 12 timer interrupt periods (0x0C) between each step pulse. So the "speed unit" is this timer interrupt period.
Hope this is clear enough.

Jean-Luc.

Great, thanks.
I have here the pdf output of a spreadsheet I used to compute my configuration ;

perso.utinam.cnrs.fr/~fmeyer/pas_moteur.pdf
or its gnumeric source :
perso.utinam.cnrs.fr/~fmeyer/pas_moteur.gnumeric

it might help making sure we are talking of the same things (I just realized it's half french/half english, but
neither should be a problem
The controller timer frequency is 80 MHz (these are microchip uno32, one per axis), period 0.0125 us.
This gives me 0x0000db206 cycles/ustep at sidereal speed, and 0x00703 cycles/ustep at 500x.
One difference is that (at least in its current config) the mcmt32 setup cannot alternate between ustep and full step (this limits the maximum speed, but its not a problem) ; so I think I have to set that HighSpeedRatio ratio to 1.
Unless mistaken, that seems all clear.
at least for now... I'll probably be back with additional questions, if you dont mind hanging around this thread for a few days...
thanks again.
Oh, while I am here, it seems you have followed that very same path, ending in creating a GEEHALEL mount type in eqmod.
Could/should there be (once I am done with fixing the firmware) an MCMT32 type in eqmod ?

Edit (a bit later) :
I am lost again : in skywatcher.cpp:502, we ask for interrupt frequency and fill RAStepsWorm with the returned value. I must be missing something...
--
F. Meyer

The skywatcher motor controller uses a hardware timer to generate interrupts, and the interrupt service routine simply decrements a running period counter. When this counter reaches zero, the isr generates the next step (i.e. sets PWMA, PWMB, phase A and Phase B pins which have been computed in the main loop outside the isr) and resets the running counter to the desired period (and also sets a flag for the main loop computes the next PWMs/Phases). The controller itself runs at 20Mhz but this only impacts how the timer period registers are configured.
Well, I've quickly looked at your firmware and the PIC32 datasheet, your approach is to program the 4-5 timer with the microstep period for the current desired speed. I've made the same thing with my so called geehalel mount. Now if you use 0.0125µsec for the Interrupt Timer Freq this will be 80000000=0x4C4B400 and that does not fit into a 24 bit number (a limit in the skywatcher protocol). So simply use a constant which at least corresponds to the max sustainable speed (1000x gives 0x4C4B400/0x381=0x15C62=89186), knowing that higher it is, finer will be the resolution in speed (you may also use 0xFFFFFF). You would only have to multiply the received periods by that constant to retrieve your 4-5 timer period.
If you don't use full step, I think setting highspeed ratio to 1 should be ok. The indi driver sets high speed mode if the desired speed is over 128x and thus multiplies the desired period by this ratio before sending it to the mount. It does not care if it is 1.
For sure there could be a MCMT32 type in indi-eqmod, I hope there will be.
Bon courage.

Concerning RAStepWorm, the name is simply erroneous, that should be what I have understood at the very beginning from different sources (I never had a real skywatcher mount), I think it is just used as shown above in period computations. Will have to change that one of this day.

Ok, all this makes sense.

In the skywatcher code, what are Breaks, TargetBreaks BreaksIncrement and so on meant to achieve ? Are they somehow here to manage acceleration on motion start and deceleration on motion stop ? The current mcmt32 firmware has builtin acceleration/deceleration ramps, so my feelling is I could just ignore breaks. Am I right ?

(mcmt32 is not my design, its a collaborative project, but key people in the project are windows inclined. All I did was making some housework in the firmware and
trying to write an indi driver for it ; but finally I think it makes more sense to take advantage of the larger community of eqmod and try to convert the firmware to an eqmod-compatible one).

Grazie mille

Yes, this is used to specify the start of the deceleration, the deceleration itself is managed in the firmware. I use a constant value (these are microsteps, relative or absolute) so you may just ignore them.

Great idea, this will allow you to remote control your mount with a raspberry afterward.