count-down issue

[Wolfgang Reissenberger]

I think I could explain it. Running with the Telescope Simulator, the old and the new value at least on RA is slightly different in a range of 10^-8 and therefore at least for the simulator the coordinates update happens all the time.

The question is: should we rework it in Ekos or in INDI? In INDI it’s a matter of one single line, in EKOS it’s quite an effort (and we need a new timer).

Cheers
Wolfgang
—
Wolfgang Reissenberger

www.sterne-jaeger.de
TSA-120 + FSQ-85 + epsilon-160 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro

> Am 16.02.2022 um 09:56 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
> 
> Sorry, I was referring to INDI: https://github.com/indilib/indi/blob/f479114a60cddb7c4209e83824702de4efd58245/libs/indibase/inditelescope.cpp#L711 <https://github.com/indilib/indi/blob/f479114a60cddb7c4209e83824702de4efd58245/libs/indibase/inditelescope.cpp#L711>
> 
> --
> Best Regards,
> Jasem Mutlaq
> 
> 
> 
> On Wed, Feb 16, 2022 at 11:28 AM Wolfgang Reissenberger <sterne-jaeger at openfuture.de <mailto:sterne-jaeger at openfuture.de>> wrote:
> I’m not sure whether I get it right. Inditelescope.cpp::248 has this entry:
> 
>         emit newCoords(currentCoords, pierSide(), hourAngle());
> 
> This is unconditional, there is no check whether currentCoords equal the previous one.
> 
> Or are you talking about another place?
> 
>> Am 16.02.2022 um 09:22 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>>:
>> 
>> I don't think Ekos should depend on this behavior. INDI::Telescope
>> doesn't send updates when the previous values are identical.
>> 
>> --
>> Best Regards,
>> Jasem Mutlaq
>> 
>> 
>> On Wed, Feb 16, 2022 at 11:09 AM Wolfgang Reissenberger
>> <sterne-jaeger at openfuture.de <mailto:sterne-jaeger at openfuture.de>> wrote:
>>> 
>>> Ekos relies upon the INDI driver that it regularly sends the  EQUATORIAL_EOD_COORD coordinates - no matter whether they change or not. The frequency is defined by the polling period defined in the INDI driver.
>>> 
>>> If for whatever reason the INDI driver does not send them, the MF counter won’t be updated.
>>> 
>>> We could indeed discuss whether it makes sense that Ekos relies upon a regular update even if values do not change. But currently, at least for the scope coordinates, it does.
>>> 
>>> HTH
>>> Wolfgang
>>> 
>>>> Am 16.02.2022 um 08:49 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>>:
>>>> 
>>>> Hello Hy,
>>>> 
>>>> I don't believe this is an INDI driver issue. The driver is behaving
>>>> as it should. Ekos should do this. Also, I've been using this with
>>>> EQMod for many years and it works just fine, so what gives?
>>>> 
>>>> --
>>>> Best Regards,
>>>> Jasem Mutlaq
>>>> 
>>>> 
>>>> On Wed, Feb 16, 2022 at 1:38 AM Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
>>>>> 
>>>>> I was noticing on the forum a thread you responded to where users were complaining that the meridian-flip count-down wasn't working for their Onstep mount.
>>>>> 
>>>>> I had/fixed/hacked the same problem on my A-P driver.
>>>>> 
>>>>> Here's what I believe is likely happening to them.
>>>>> 
>>>>> The MF count-down is updated in a callback method that's watching the RA/DEC from indi.
>>>>> That is, in mount.cpp, updateTelescopeCoords calls checkMeridianFlip()  which does the updating of the counter.  However, updateTelescopeCoords is only called when the slot newCoords is hit. That signal is likely only sent when the RA/DEC change, but when the scope is tracking, the RA and DEC don't change!
>>>>> 
>>>>> I saw that my driver wasn't updating its MF counter either (and presumably, therefore wouldn't flip), but I know my old Eqmod mount did work fine, so I assumed it was an issue in my A-P driver.  FWIW, I added this hack in my driver to get around the check for newness in newRaDec.
>>>>> 
>>>>> Hy
>>>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220216/ee4273c8/attachment.htm>