1. Stefan B Avatar Stefan B
  2. nina
  3. NINA
  4. Issues

Force guider recalibration after meridian flip

Issue #1058 resolved
Davide Quattrociocchi created an issue

I am forced to use ST-4 for guiding so PHD2 won’t know when the side of pier changes to start a recalibration. It would be nice if recalibration could be triggered via NINA after meridian flip; otherwise I cannot use meridian flip with PHD2 (blocking issue for me). A switch in the meridian flip option panel would suffice.

Comments (20)

  1. Stefan B repo owner

    A plugin is available “DIY Meridian Flip” where you can customize what the actions before and after the flip should be. There you can also drop in a start guiding instruction with forced calibration enabled.

    On a side note: Why do you need ST-4 Guiding, when the telescope is connected to the pc, as it is controlled by nina too?

  2. Armando Beneduce

    Hi Davide,

    if you’re using ST-4 for guiding you can set your current ASCOM telescope as aux mount to make PHD knowing telescope side of pier.

    I hope it helps.

    CS

    Armando Beneduce

  3. Davide Quattrociocchi reporter

    Thank you for your quick reply!

    Tonight I will test both solutions to close this issue.

    For curiosity sake: I’m using ST-4 for guiding because I added an home made inexpensive RA encoder system (via Arduino; I’m an engineer 😉) to my N-EQ6 mount RA axis to correct the stepper motor cogging and fast periodic error (< few seconds) that PHD2 cannot correct quickly. The system works by reading the RA encoder and sending ST-4 fast pulses to the mount acting as a master so I need to control it (not the mount) as a slave with PHD2 via its own ST-4. ASCOM driver is still used for slewing and everything else apart guiding pulses. This way RA guiding is greatly improved and stars are perfectly round, see attached image (in yellow the original mount RA error, in green the corrected one, both unguided). PHD2 then is used to correct only the remaining slow star drifting (the trend line of the green serie) and corrects (overrides) the encoder system guiding via ST-4.

    ‌

  4. Davide Quattrociocchi reporter

    Update after testing (hopefully useful for other N-EQ6 users):

    1. Aux mount in PHD2 did the trick reverting the guiding axes, thank you Armando. However it doesn’t restart calibration so guiding is poor (according to me) after meridian flip/change of pier side.
    2. DIY Meridian Flip Plugin is very powerfull (thank you Stefan) but my N-EQ6 is buggy, even with the latest ASCOM driver and SynScan firmware (looking in the logs it seems that the mount doesn’t return correctly its timezone so its time is off by 1 hour - no workaround found); the meridian cannot be flipped correctly but I really think this is not a N.I.N.A. related issue. I will move to EQMOD in the next few days and check N.I.N.A. with it.

    However I noticed two things about the DIY meridian flip plugin:

    1. this error in version 034BETA (meridian flip put into a nested set of a newly created sequence - it should be possible according to the plugin documentation):

    2. when I put the meridian flip at the deep sky object level (before the previous nested set) it triggers instantly on sequence run, even if object position is away from the meridian, and blocks the photo session (is this the correct behaviour?)

    If this is not the correct behaviour I think it may still be related to time inconsistency of my N-EQ6 so I will investigate it with EQMOD in the next days.

    Thank you for your support and patience.

    ‌

  5. Davide Quattrociocchi reporter

    Update, now using:

    Result:

    • “DIY Meridian Flip Trigger” still triggers shortly after the sequence launch even far from the meridian, even on simple sequences (please see attached json and pictures).

    Procedure:

    • Start a clean N.I.N.A. 034BETA application session
    • Switch on the mount at the North Pole direction as required
    • Connect the mount in N.I.N.A.
    • Load and launch simple attached sequence (NOTE: same behaviour with other sequences!)
    • Sequence starts and correctly slews to the object
    • Shortly after the slew, “DIY Meridian Flip” triggers way before meridian is reached

    Side note:

    • After waiting to pass the meridian, the “Flip Scope” instruction doesn’t move the telescope at all (next instruction gets executed)

    Figures (each figure is relative to a different sequence run so timestamps are different):

    ‌

  7. Marc Blank

    Hi. So the simple thing first; yes, there’s a bug that requires it to be at “top level” in the DSO Sequence. That will be fixed in the next iteration (couple days, probably). For the more important issue, could you possibly attach a NINA log at the time of at least one of the failures? The DIYMF logs exactly the same as the built-in MF trigger, so there should be good information there.

    ‌

    Thanks!

  8. Davide Quattrociocchi reporter

    Thank you!

    Important update: it seems to me that in the latest 036BETA the “DIY Meridian Flip Trigger” UI has a longer label; it tells explicitly that the trigger was anticipately launched because of a time optimization - indeed, I used a very long “Wait for Time Span” which gets “optimized” (sounds right). So I’ve just deleted and substituted it with “Take Many Exposures” and now the optimization has gone: the trigger correctly waits for the meridian, flips and restarts exposures.

    Sorry for this false alarm!

    I’ll check more complex sequences tomorrow (I need AF triggers and sequence nesting); then, if you agree, we can close the original proposal.

    P.S. The DIYMF is great! 🙂

    ‌

  9. Davide Quattrociocchi reporter

    So, the DIYMF plugin correclty flips and restarts guiding calibration but if you use the “Run Autofocus” instruction in its very same instruction block then it triggers even far from the meridian (just before executing that autofocus instruction). If I learned something from the previous false alarm, I guess it’s not a bug but an optimization issue. However I understand it’s conceptually difficult to solve: how long will the autofocus take to run (too many variables - some not known a priori) to decide if it is better to stop and wait for the meridian to pass before AF?

    NOTE: AF triggers work fine and “Run Autofocus” inside DIYMF trigger works fine too.

    I’m using a temporary workaround: delete all “Run Autofocus” instructions when using DIYMF, run autofocus manually on the target before sequence start.

    I guess that when we could use the DIYMF in a nested block I could just run the autofocus instruction before executing that block, so I’ll wait for that bug fix.

    If you confirm that this is a problem (it is for me but I can survive), I kindly suggest you (if possible) to put a warning sign (red exclamation circle) inside the “Run autofocus” instruction when used in a DIYMF block to inform the user about this issue, until a workaround/solution will be found.

    Please tell me if you need other info (logs, json, etc).

    Thank you!

  10. Marc Blank

    Hi, Davide.

    I’m not sure I’m following you here. What is it that triggers even far from the meridian? The whole DIYMF sequence? Sorry to be confused! I think maybe the NINA log would be helpful. And the json of the sequence you were running. Thanks.

  12. Davide Quattrociocchi reporter

    The relevant issue is in log at 2022-01-29T19:12:49.9906

    Picture of working sequence:

    Picture of non working sequence:

    ‌

  13. Davide Quattrociocchi reporter

    Side notes:

    • Focuser works despite lot of DriverExceptions
    • RaDec Sync effectively fails. It failed even with Nina version 1.11 but this is another (non blocking) problem, I will not investigate it now (however not in this issue).

    ‌

  14. Davide Quattrociocchi reporter

    Sorry, relevant problem at 2022-01-29T19:19:49.6815:

    2022-01-29T19:19:49.6815|INFO|DIYMeridianFlipTrigger.cs|ShouldTrigger|361|Meridian Flip - No more remaining time available before flip. Max remaining time 00:20:32.4770000, next instruction time 8800, next instruction Category: Focuser, Item: RunAutofocus. Flip should happen now

    ‌

  15. Davide Quattrociocchi reporter

    Info: maybe I used too much retries on the “Run Autofocus” instruction (25 at the time of the suggested log line) so maybe the instruction time was 25 times higher than normal (I set so much retries because tonight there are little passing clouds in the sky…). Indeed, 8800 s/25 = 352 s which is about the time 1 full autofocus takes with my setup… So maybe “instruction time” 8800 is the worst case time, right?

    ‌

  16. Marc Blank

    So… in Options → Autofocus, how many attempts do you allow? NINA will multiply some amount of time by this setting to determine (worst case) how long it will take. That could cause the DIYMF to trigger VERY early. Any number of attempts > 5 is probably pointless.

  17. Davide Quattrociocchi reporter

    Yes, we hit the point, too much retries. I will lower them to 5 as suggested. I will also increase the DIYMF max flip time after meridian to 45 minutes (EQMOD meridian limits set to about 1 hour).

    That’s enough for me.

    In the end: the DIYMF works just fine and solves my original guiding recalibration problem (if you like, you can print on the DIYMF UI the blocking operation and its extimated instruction time, like in the logs, just for ease). If you agree, I can close this issue.

    Thank you so much!

  21. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
resolved
Component
Business Logic
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!