2.6.0.0 meridian flip problem

Sure, we’ll get it done… beta life.

Thanks Ken (& Jared) - have a good Christams break.

Recovery now activated in the faint hope that I’ll have some clear skies!

Ken/Jared,

After setting the meridian flip point through the API in v2.6.0.5, is there someplace that value should be reflected in the SGPro user interface? I am not sure where to look.

Thanks in advance,

-Ray

@rgralak

Sure…

Then, it will be here:

Is that Equipment Profile Manager?

If so, I found that place earlier, but it always shows “0”, even after opening and closing it. (And that’s why I posted the question).

BTW, I can send the flip time (in integer minutes) in APCC and read it back from SGPro, so SGPro seems to retain the values I set. I just can’t find the value I set in the user interface. I am not running a sequence, so maybe that’s the problem?

-Ray

@Ken. Nevermind, I found it. It’s the Control Panel, not the Equipment Profile Manager, which looks similar. The delay value is being updated correctly, so I just need to do a little more testing before I release a build of APCC with that feature.

And, thanks again for adding the flip delay API call.

-Ray

What exactly does the APCC “Send Limit to SGPro” do, and how is SGPro supposed to react to it?

My OTA is on the east side pointing east, counterweights down slightly. I have East and West Limits checked in APCC as well as “Send Limit to SGPro”. APCC says there are 11 hours and 53 minutes till the mount hits the meridian limit. It has a Current Meridian Delay of 1.61 hours on the right side of APCC. Looking in the APCC log file, it sent SendMountMeridianDelay of 1.6 hours which matches the Meridian Delay time.
This is sending the Meridian Delay (1.61 hours) rather than the meridian limit (11h 53m) as the name “Send Limit to SGPro” and associated help message suggests. Is this correct?

SGPro’s Control Panel has a “Time to Meridian” of -00:51:53 11:43 PM. I do NOT have the “Use Auto Meridian Flip” set.
It is12:36 AM right now. Adding the negative 51:53 gives 11:43 pm so the math makes sense but why is there a negative 51:53 to the meridian? The scope looks like it has about 5 hours before it reaches the meridian.

I thought the “Send Limit to SGPro” checkbox in APCC was supposed to tell SGPro not to do a meridian flip until the meridian tracking limit was reached, in my case, in 11h 53m.

i have not been able to test this, but i believe all it’s supposed to do is keep APCC and SGP in sync with respect to where the meridian flip point should be (when the ota is on the west side of the pier). so if you have a meridian limit set in APCC for 2 hours past the real meridian, APCC is automatically telling SGP that the mount can track 2 hours past the meridian.

you’re on the east side which i don’t think is relevant to SGP. it’s when the OTA is on the west, that a meridian flip would be necessary.

btw if you’re on the east with the counterweights down, aren’t you pointed west?

at any rate, what SGP is looking for is a number of minutes past the meridian to track, so setting SGP to 11h53m would pretty much be a disaster for most mounts. the meridian delay in shown APCC must reflect the fact that your meridian limit for OTA on the west side is 1.6 hours past the true meridian. does that seem right?

pfile,

The name of the new APPC checkbox (“Send Limit to SGPro”), the help message that appears when hovering over the box, and the fact that the box is on the “Meridian” limits tab in APCC imply to me exactly what you said - APCC should tell SGPro where the meridian limit is and hence when to perform a flip.
I spent several hours last night playing with APCC and SGPro, moving the mount in RA and DEC, turning east and west meridian limits on and off in APCC, checking and unchecking “Send Limit to SGPro”, and looking in the log file to see what caused APCC to send messages to SGPro. When I wrote my post the OTA was on the east side, but I had the same result on the west side - SGPro was not displaying the time the meridian limit would be reached, but instead was almost always displaying some negative time which I believe is where the EAST limit was, not the west limit.

Regarding your last paragraph, I don’t know if SGP is looking for a number of minutes past the meridian to track (for example, 120 minutes past the meridian), or if SGPro is looking for the time when it needs to do a flip, i.e., when the mount reaches the west limit as defined in APCC (for example, flip at 2:30 am). If it’s the former, then telling SGP 11h53m or anything above 6 hours would be a disaster, but if it’s the later then 11h53m (or more precisely, 11:53 pm) could be fine. In my testing above when the OTA was all the way on the east side pointing north, it could move for 11h 53m before it reached the west meridian limit, without hitting the pier.
If I understand correctly, when using the meridian limits in APCC, you do not manually set the meridian delay - it’s determined automatically. Instead, you define the meridian limits beforehand, and APCC then determines for the current DEC when the mount needs to flip. It displays it as “Time before limit reached: 02h 44m 02s”, not as an actual time.

This new feature is part of the reason I just bought SGPro, so I thank Ray and the SGPro team for making the changes.

SGP expects minutes past the meridian, since the wall clock time would change every night and you’d have to update it. the API for external programs to set the limit is very new - although a program could easily calculate flip times and set it via the API, for a human a time-based setting would be a nuisance.

you are right, APCC displays this stuff as a “time until”… however SGP does too: down in the lower status bar there is a clock counting down hours/minutes until the flip point is reached. but that displayed time is calculated; the setting in SGP is always a number of minutes past the meridian.

pre-APCC things were pretty simple; you’d (optionally) specify a meridian delay in the driver and tell SGP what the delay was and everything would just work… but of course the deal with APCC is that you can set limits which vary with declination and so the need arises for APCC to tell SGP where the flip point should be, as the delay is now variable depending on where the scope is pointed in declination.

rob

Hi Eric/Rob,

Sorry for the delayed reply. I was out of town last week. I usually try to minimize information in a user interface so it won’t be confusing, but are there any enhancements you would like to see to APCC to make this feature easier to use or to provide more status information?

-Ray

Hi ray, i am ashamed to say i have not been able to try it - my camera died a couple of weeks ago and i’m dead in the water.

i did want to ask though, i thought i read reports sometime back that one of the newer versions of APCC did not work well on low-end stick PCs. IIRC that was resolved but i wanted to check with you before upgrading as i am using an atom-based intel stick these days.

rob

Hi Rob,

I don’t recall A-P reporting to me any issues from low powered devices that couldn’t be solved, but maybe, if there have been issues, that A-P might be suggesting that customers use a faster CPU.

APCC is highly multi-threaded so maybe Windows threading doesn’t work efficiently on those low powered devices. The biggest computational overhead would probably be opening the 3D telescope view since that would require software emulation instead of using a hardware graphics processor.

-Ray

OK - IIRC there was some fix you had made that improved things but it was a while ago and i can’t remember where i read it. the 3D view works OK on my machine. i am using RDP and my understanding is that the rendering is done on the client side which might help things a little.

anyway if i ever get my camera back i’ll be able to test but for now it seems that i could be offline for weeks.

rob

Ray,
Other than not displaying the automation software warning message when the “Send Limit to SGPro” box is checked (which you know about), the only software enhancement I can think of is described my 3rd bullet.
In addition, a detailed explanation of the feature in APCC’s manual would be extremely helpful. For example:

  • What’s the benefit of using it?
  • Does SGPro need to be running before APCC is started in order for the feature to work? If so, what happens if APCC is started first? Does the user need to exit APCC, or can the user simply uncheck then recheck the box?
  • What should a user expect to see in SGPro after checking the “Send Limit to SGPro” box? Something other than “0” in the “Minutes Past Meridian to Flip” box in SGPro’s Meridian Flip Options (See ken’s screenshots above from Jan 8)? And/or a “Time to Meridian” in SGPro’s Control Panel that matches APCC’s “Time before limit reached”? Etc. If the “Minutes Past Meridian to Flip” is updated by APCC, would it make sense to display that value in APCC as a sanity check? Possibly next to the “Send Limit to SGPro” checkbox, or in the help message that appears when hovering over it?
  • When are the limits resent to SGPro?
  • Does a user need to do anything in SGPro in order for APCC’s “Send Limit to SGPro” to work? Such as checking the “Use Auto Meridian Flip” checkbox in SGPro’s Control Panel? Or something else?
  • What is sent to SGPro - the “Time before limit reached” number in the left side of APCC or the “Meridian Delay” on the right side? Since the checkbox has the word “limit” in its name, I would expect the “Time before limit reached” to be sent, not the Delay, but looking at the log file I see the Delay and not the limit being sent.

I realize SGPro isn’t your application and hence documenting it isn’t your responsibility, but describing the touch points in APCC’s documentation is, IMHO, appropriate.

Eric

Hi Eric,

APCC will send it’s west meridian limit value (when pier side=west). APCC will try to send the west meridian limit every time the meridian limit value changes (on the west side only) which might happen if declination is changed, or always when you enable the option. If SGPro is not running you will not see an error. If you start running SGPro after APCC is started then SGPro will not get a new meridian limit value from APCC until either the limit value in APCC changes, or you disable/enable the “Send Limit to SGPro” option. What is sent to SGPro is described in their protocol document and you need not worry about that unless the limits are not showing up as expected in SGPro’s user interface.

That said, If you see any problems with the way it is working please post them on the ap-gto forum so that A-P is aware of the issue. If something needs to be done A-P should be in the loop as APCC is their product and it might be helpful when their support personal work with customers over the phone.

Thanks,

-Ray

It may be worth consulting Bob Denney @SkySlicer about the meridian limit. He was proposing an addition to the ASCOM standard to provide this sort of information. I don’t recall the exact details but it was something like the driver providing the time it could continue to track in the current pointing state and the time to when a pointing state change (aka meridian flip) was possible. These could be implemented in ASCOM as SupportedActions until any specification change was agreed.

Implementing these like this, using the usual ASCOM paradigm that the driver is passive and only responds to commands from the application, would avoid needing to have application specific code in APCC. It would also avoid the issue of the start order mattering because SGP would ask the driver when it needed the information. It it wasn’t available it would use it’s current process.


1 Like

Thanks @Chris.

That would be ideal to have the limit available via the driver. It would certainly simplify the logic in APCC (no logic required! :-)).

In the meantime, I will make a slight change to APCC to keep sending the limit every X number of seconds when SGPro does not respond. If SGPro is started afterwards it would then get the limit. Of course that would only happen if the user has the “Send Limit to SGPro” option selected.

-Ray