×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

EKOS Orchestration - a very weird mystery!!!

  • Posts: 148
  • Thank you received: 19
Full run via scheduler last night from park to park and all parts executed but not as expected - THIS IS WIERD
1) Normal start - unpark...slew...focus....align...capture HA no issues
2) change filter to OIII no issues
3) Guide (@Hy) is all good at this point

4) at  correct time flip is pending - flip executes and takes the normal time based on my slew speeds
5) align happens and says complete - see first attached image - THIS IS NOT THE SAME TARGET
6) at this point there is no guiding - 00:31:44 Autoguiding aborted - which is right at the flip (good) - but no reason for it to STAY aborted - it should have resumed
7) at this point I have a few hours of unguided images in SII on an unknown patch of sky.....and THEN
(yes this is the weird part)
8) at 04:57 am the system decides to focus again on SII and THEN perform an align (3 iterations) - it is GOOD and back on target AND guiding kicks back in AND I am suddenly focusing on OIII
9 ) the system manages 1 final image in OIII with a flipped target properly centered and the image is in focus and well guided!

The 3 images here show the analysis window  and logs are attached - but WOW and WHY - the strange operation - funny thing is each function can operate but to suddenly align after 4 hours? 
Full run via scheduler last night from park to park and all parts executed but not as expected - THIS IS WIERD
1) Normal start - unpark...slew...focus....align...capture HA no issues
2) change filter to OIII no issues
3) Guide (@Hy) is all good at this point

4) at  correct time flip is pending - flip executes and takes the normal time based on my slew speeds
5) align happens and says complete - see first attached image - THIS IS NOT THE SAME TARGET
6) at this point there is no guiding - 00:31:44 Autoguiding aborted - which is right at the flip (good) - but no reason for it to STAY aborted - it should have resumed
7) at this point I have a few hours of unguided images in SII on an unknown patch of sky.....and THEN
(yes this is the weird part)
8) at 04:57 am the system decides to focus again on SII and THEN perform an align (3 iterations) - it is GOOD and back on target AND guiding kicks back in AND I am suddenly focusing on OIII
9 ) the system manages 1 final image in OIII with a flipped target properly centered and the image is in focus and well guided!

The 3 images here show the analysis window  and logs are attached - but WOW and WHY - the strange operation - funny thing is each function can operate but to suddenly align after 4 hours? 
I guess the main issues are 
1) why did align successfully align on nothing and then suddenly after 4 hours do another align and actually get the target
2) way did guide never resume after the flip/align at 12:30 am but suddenly start again at 5:00 am

Any insight would be helpful 
This is master branch build as of last Friday (sept 10) - beta 3.5.5 

File Attachment:

File Name: log_20-23-41.zip
File Size:2,861 KB



  
2 years 6 months ago #75623
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
Well here is part of it - keep in mind that the target was RA 22:48:14 and DEC 58:14:50

The FIRST pass of align did a solve after the flip of 22:54:42

2021-09-17T00:34:26.130 EDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 54m 42s) DEC ( 58° 14' 16\") Telescope Coordinates: RA (22h 48m 14s) DEC ( 58° 14' 51\")"
[2021-09-17T00:34:26.134 EDT INFO ][ org.kde.kstars.ekos.align] - "Target is within 01° 36' 56\" degrees of solution coordinates."
[2021-09-17T00:34:26.146 EDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2021-09-17T00:34:26.161 EDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 54m 42s" ( 22.9116 ) DE: " 58° 14' 16\"" ( 58.2379 )
[2021-09-17T00:34:26.162 EDT DEBG ][ org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Syncing"
[2021-09-17T00:34:26.232 EDT INFO ][ org.kde.kstars.ekos.align] - "Syncing to RA (22h 54m 42s) DEC ( 58° 14' 16\")"

It knows that the location is wrong so issues slew to target coordinates

[2021-09-17T00:34:26.495 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Slewing"
[2021-09-17T00:34:26.542 EDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 22:48:14 - DEC: 58:14:51 "

It knows it needs to solve and slew again - BUT CHECK OUT THE SLEW COMMAND - it has just issued a slew to the initial SOLVED coordinates after the flip - not that target coords - This is the bug - either a wrong variable is used or a logic bug that replaces original target with current solved position

[2021-09-17T00:34:36.272 EDT INFO ][ org.kde.kstars.ekos.align] - "Solver completed after 3.00 seconds."
[2021-09-17T00:34:36.274 EDT INFO ][ org.kde.kstars.ekos.align] - "Solver RA (343.44551) DEC (58.12159) Orientation (93.28024) Pixel Scale (0.85682) Parity (neg)"
[2021-09-17T00:34:36.277 EDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 54m 42s) DEC ( 58° 14' 15\") Telescope Coordinates: RA (22h 48m 21s) DEC ( 58° 14' 51\")"
[2021-09-17T00:34:36.280 EDT DEBG ][ org.kde.kstars.ekos.capture] - Align State changed from "Suspended" to "Slewing"
[2021-09-17T00:34:36.345 EDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 54m 42s" ( 22.9115 ) DE: " 58° 14' 15\"" ( 58.2376 )
[2021-09-17T00:34:36.347 EDT INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (22h 54m 42s) DEC ( 58° 14' 15\")."
[2021-09-17T00:34:36.449 EDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Idle"
[2021-09-17T00:34:36.514 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Slewing"
[2021-09-17T00:34:36.517 EDT INFO ][ org.kde.kstars.indi] - QHY CCD QHY183M-ec51fb4 : "[INFO] CCD FOV rotation updated to 93.2802 degrees. "
[2021-09-17T00:34:36.517 EDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "Slew aborted. "
[2021-09-17T00:34:36.518 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 0
[2021-09-17T00:34:36.527 EDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 22:54:42 - DEC: 58:14:15 "
[2021-09-17T00:34:36.553 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Scheduler iteration never set up.
[2021-09-17T00:34:37.375 EDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Idle" to "Slewing"
[2021-09-17T00:34:37.425 EDT DEBG ][ org.kde.kstars.ekos.guide] - "GPG::reset()"
[2021-09-17T00:34:37.425 EDT DEBG ][ org.kde.kstars.ekos.guide] - Resetting GPG
2 years 6 months ago #75624

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
The mystery of the last OIII image is actually and AWESOME success of other parts of the system - after SII 30 images were captured, scheduler looked back and realized it has ONLY captured 29 of 30 OIII...so it started the schedule again to follow ALL the steps and get the last image which is did:
1)slew to target
2) focus on OIII
3) align on the target - THIS TIME the coordinates are correct

org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 22:48:14 - DEC: 58:14:51 "
[2021-09-17T04:57:18.399 EDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Mount is unparked. "

So this tells me that in the align module after a flip something is not reset properly but on the start of a schedule it is - otherwise I would have still had the incorrect coords as seen above -

So the problem that needs to be found:
1) why align uses incorrect coordinates after a flip but ONLY after the first try
2) why guiding never resumed and never reported an error as to why after the flip - NOTE I WAS using saved calibration rather than forcing calibration after a a slew - that is a known problem area (@HY)

This is SOOOO close to being all good
2 years 6 months ago #75625

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Jamie,
I took a first look into your log. The really weird thing is that two MFs are happening more or less in a row without slewing to a different target in between.

There is one weakness in the MF: we do not check afterwards if the position reached matches the intended target position. In your case, it seems to be far off - no idea, why! Instead of RA=22:48:14, after the MF slew, it has RA=02:48:14, so exactly 4h apart.

As a consequence, a second meridian flip is started while alignment is still running - another weakness, currently alignment is not aborted in this case, it simply is suspended until the mount is tracking again.

Do you have an explanation for this significant difference in RA?

Maybe you could turn on the INDI log for your mount, so that we could take a deeper look inside.

Btw.: I see you have a OnStep mount. There was a discussion here recently leading to a fix in the OnStep driver. Are you on the latest version?

HTH
Wolfgang
2 years 6 months ago #75651

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
Hi Wolfgang....Yeah ,I am on latest OnStep driver (part of the gang that fixed it) - can you let me know what timestamp you see that 02:48:14? - I can't locate it

My big worry is the mid correction at 00:34:36 as it look like that solved coordinates (22:54:42) then replace the target coordinates (22:48:14) - when this happens the mount stay on that first 'landing spot" - it is close by but since the alignment module now think this 22:54:14 is the target it (obviously) is successful

[2021-09-17T00:34:36.274 EDT INFO ][ org.kde.kstars.ekos.align] - "Solver RA (343.44551) DEC (58.12159) Orientation (93.28024) Pixel Scale (0.85682) Parity (neg)"
[2021-09-17T00:34:36.277 EDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 54m 42s) DEC ( 58° 14' 15\") Telescope Coordinates: RA (22h 48m 21s) DEC ( 58° 14' 51\")"
[2021-09-17T00:34:36.280 EDT DEBG ][ org.kde.kstars.ekos.capture] - Align State changed from "Suspended" to "Slewing"
[2021-09-17T00:34:36.345 EDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 54m 42s" ( 22.9115 ) DE: " 58° 14' 15\"" ( 58.2376 )
[2021-09-17T00:34:36.347 EDT INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (22h 54m 42s) DEC ( 58° 14' 15\")." <<<<<<right here!
[2021-09-17T00:34:36.449 EDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Idle"
[2021-09-17T00:34:36.514 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Slewing"
[2021-09-17T00:34:36.517 EDT INFO ][ org.kde.kstars.indi] - QHY CCD QHY183M-ec51fb4 : "[INFO] CCD FOV rotation updated to 93.2802 degrees. "
[2021-09-17T00:34:36.517 EDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "Slew aborted. "
[2021-09-17T00:34:36.518 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 0
[2021-09-17T00:34:36.527 EDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 22:54:42 - DEC: 58:14:15 "
[2021-09-17T00:34:36.553 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Scheduler iteration never set up.


Unfortunately I have the mount logs turned off (always the case when you need something :-) ).....I'll try and recreate again and see what I get - what I do need is which module is actually sending that slew command and setting the coordinates in the function - is that done in align directly or is it simply updating a variable and letting another layer issue the slew - I am surfing the code this morning...thanks in advance if you know
2 years 6 months ago #75652

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Voilà:
[2021-09-17T00:33:51.921 EDT DEBG ][     org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "22h 59m 56s"  scope RA= "02h 48m 14s"  ha= 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 , flipDelayHrs= 0 ,  "Pier Side: East (pointing West)"
This shows the current scope position at the second meridian flip.
2 years 6 months ago #75654

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
Had a PERFECT night last night and the same double flip occurred but did not affect operations - actually it appeared to make life better for the scheduled operation
 

File Attachment:

File Name: log_17-29-...9-19.zip
File Size:4,168 KB

 

First flip lands much as yesterdays run at RA (22h 54m 44s)

[2021-09-19T00:29:26.849 EDT INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 54m 44s) DEC ( 58° 13' 35\") Telescope Coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")"
[2021-09-19T00:29:26.851 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within  01° 37' 18\" degrees of solution coordinates."
[2021-09-19T00:29:26.862 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2021-09-19T00:29:26.873 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 54m 44s" ( 22.9123 ) DE: " 58° 13' 35\"" ( 58.2265 )
[2021-09-19T00:29:26.874 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Syncing"
[2021-09-19T00:29:26.984 EDT INFO ][     org.kde.kstars.ekos.align] - "Syncing to RA (22h 54m 44s) DEC ( 58° 13' 35\")"
[2021-09-19T00:29:27.074 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Scheduler iteration never set up.
[2021-09-19T00:29:27.111 EDT INFO ][           org.kde.kstars.indi] - QHY CCD QHY183M-ec51fb4 :  "[INFO] CCD FOV rotation updated to 93.2831 degrees. "
[2021-09-19T00:29:27.112 EDT DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Syncing"
[2021-09-19T00:29:27.113 EDT INFO ][           org.kde.kstars.indi] - LX200 OnStep :  "[INFO] OnStep: Synchronization successful. "
[2021-09-19T00:29:27.114 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "Syncing" to "Slewing"
[2021-09-19T00:29:27.178 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope:  TRACK
[2021-09-19T00:29:27.193 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 48m 15s" ( 22.8042 ) DE: " 58° 14' 52\"" ( 58.2478 )

This time however it issues the CORRECT target coordinates

[2021-09-19T00:29:27.194 EDT INFO ][     org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")."
[2021-09-19T00:29:27.236 EDT DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Tracking"  to  "Slewing"

capture and solve/sync

[2021-09-19T00:30:00.958 EDT INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 48m 19s) DEC ( 58° 14' 42\") Telescope Coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")"
[2021-09-19T00:30:00.960 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 01' 01\" degrees of solution coordinates."
[2021-09-19T00:30:00.970 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2021-09-19T00:30:00.980 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 48m 19s" ( 22.8053 ) DE: " 58° 14' 42\"" ( 58.2449 )
[2021-09-19T00:30:00.980 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Syncing"
[2021-09-19T00:30:01.012 EDT INFO ][     org.kde.kstars.ekos.align] - "Syncing to RA (22h 48m 19s) DEC ( 58° 14' 42\")"

3rd try = good

[2021-09-19T00:30:28.863 EDT INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 48m 15s) DEC ( 58° 14' 51\") Telescope Coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")"
[2021-09-19T00:30:28.865 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 00' 04\" degrees of solution coordinates."
[2021-09-19T00:30:28.873 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within acceptable range. Astrometric solver is successful."
[2021-09-19T00:30:28.875 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Complete"
[2021-09-19T00:30:28.875 EDT INFO ][   org.kde.kstars.ekos.capture] - "Post flip re-alignment completed successfully."
[2021-09-19T00:30:28.877 EDT INFO ][   org.kde.kstars.ekos.capture] - "Performing post flip re-calibration and guiding..."

Flip state change
[2021-09-19T00:30:32.470 EDT DEBG ][   org.kde.kstars.ekos.capture] - setMeridianFlipStage:  "MF_NONE"
[2021-09-19T00:30:32.471 EDT DEBG ][     org.kde.kstars.ekos.mount] - Received capture meridianFlipStatusChange  "FLIP_NONE"


THEN we get this - again with the strange RA and hours to flip -> -8 ..........so the question becomes WHAT TRIGGERS THIS - Is is possible that the mount itself has internal flip and can request this? - it ends up working which is OK but completely un needed

[2021-09-19T00:33:46.164 EDT DEBG ][     org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "23h 07m 44s"  scope RA= "02h 48m 15s"  ha= 8.32463 , meridian diff= 0.13 , hrstoFlip= -8.19463 , flipDelayHrs= 0 ,  "Pier Side: East (pointing West)"
[2021-09-19T00:33:46.164 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_PLANNED"
[2021-09-19T00:33:46.165 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_PLANNED"
[2021-09-19T00:33:46.165 EDT DEBG ][   org.kde.kstars.ekos.capture] - meridianFlipStatusChanged:  "FLIP_PLANNED"
[2021-09-19T00:33:46.165 EDT DEBG ][   org.kde.kstars.ekos.capture] - setMeridianFlipStage:  "MF_REQUESTED"



the second flip goes off with a hitch
Second Flip
[2021-09-19T00:39:12.317 EDT INFO ][     org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "22h 48m 15s" DEC= " 58° 14' 52\""  Hour Angle  "00h 01m 40s"
[2021-09-19T00:39:12.317 EDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  "FLIP_RUNNING"
[2021-09-19T00:39:12.317 EDT DEBG ][     org.kde.kstars.ekos.mount] - meridianFlipStatusChanged  "FLIP_RUNNING"

...
2021-09-19T00:39:12.561 EDT INFO ][           org.kde.kstars.indi] - LX200 OnStep :  "[INFO] Slewing to RA: 22:48:15 - DEC: 58:14:52 "
 
Second Align - looks like the slew on flip was very close - since we are already there that is reasonable

[2021-09-19T00:39:45.530 EDT INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 48m 16s) DEC ( 58° 14' 52\") Telescope Coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")"
[2021-09-19T00:39:45.532 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 00' 21\" degrees of solution coordinates."
[2021-09-19T00:39:45.544 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2021-09-19T00:39:45.553 EDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "22h 48m 16s" ( 22.8046 ) DE: " 58° 14' 52\"" ( 58.2479 )
[2021-09-19T00:39:45.554 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Syncing"
[2021-09-19T00:39:45.587 EDT INFO ][     org.kde.kstars.ekos.align] - "Syncing to RA (22h 48m 16s) DEC ( 58° 14' 52\")"
...
2021-09-19T00:40:13.495 EDT INFO ][     org.kde.kstars.ekos.align] - "Solver RA (341.84288) DEC (58.13266) Orientation (93.27043) Pixel Scale (0.85783) Parity (neg)"
[2021-09-19T00:40:13.499 EDT INFO ][     org.kde.kstars.ekos.align] - "Effective telescope focal length is updated to 577.08 mm."
[2021-09-19T00:40:13.551 EDT INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 48m 16s) DEC ( 58° 14' 53\") Telescope Coordinates: RA (22h 48m 15s) DEC ( 58° 14' 52\")"
[2021-09-19T00:40:13.553 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 00' 10\" degrees of solution coordinates."
[2021-09-19T00:40:13.563 EDT INFO ][     org.kde.kstars.ekos.align] - "Target is within acceptable range. Astrometric solver is successful."
[2021-09-19T00:40:13.566 EDT DEBG ][   org.kde.kstars.ekos.capture] - Align State changed from "In Progress" to "Complete"

so the target now becomes finding out why a second flip can be requested and how to suppress it - who is the master of MOUNT code (that wraps the drivers)


 
2 years 6 months ago #75679
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Jamie,
there must be something that changes your scope position suddenly from RA = 22h 48m 15s to RA = 02h 48m 15s. This is what creates the mess.

Do you have a second mount in your network? The question might be silly, but I know from own experience that this causes trouble if they have the same name even on separate INDI server.

Could you please turn on the INDI mount logging next time?

Cheers
Wolfgang
2 years 6 months ago #75680

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
Think I found it
At some point we get a nonsense value of hour to flip of -8 - this is meaningless as we only move forward in time so it is either an attempt to set a value that will not be used or a bug itself - BUT - it triggers this code in MOUNT
The check of hrsToFlip I think needs to be in a range or reworked - since we JUST flipped there must be some better indicator such as a combination of the v alue check && a check for pierside? - The intent here is ok but it is open for double or more execution if the hrsToFlip value is not being set correctly - I suspect the intent was to set hrsToFlip to 0 or some positive number ????switch (m_MFStatus) { case FLIP_NONE: meridianFlipStatusText->setText(message); emit newMeridianFlipText(meridianFlipStatusText->text());   if (hrsToFlip <= 0) { // signal that a flip can be done qCDebug(KSTARS_EKOS_MOUNT) << "Meridian flip planned with LST=" << lst.toHMSString() << " scope RA=" << telescopeCoord.ra().toHMSString() << " ha=" << ha << ", meridian diff=" << offset << ", hrstoFlip=" << hrsToFlip << ", flipDelayHrs=" << flipDelayHrs << ", " << pierSideStateString();   initialPierSide = currentTelescope->pierSide(); setMeridianFlipStatus(FLIP_PLANNED); } break;
2 years 6 months ago #75681

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
I know this part, but believe me, the problem is that the mount reports a by 4h different RA value without slewing. As you could see in the code part you are citing, the log takes the current telescope position when reporting and not the target position.
2 years 6 months ago #75682

Please Log in or Create an account to join the conversation.

  • Posts: 148
  • Thank you received: 19
finally got debug logs turned on and running that same sequence tonight - odd things is this version of ONStep I have been running for almost two years now and it has only had an issue with 3.5.4 and higher, partly due tothe bug we juts fixed in the the driver but I suppose there are others - the mount output has been a constant - Hopefully I can catch tonight
2 years 6 months ago #75689

Please Log in or Create an account to join the conversation.

Time to create page: 1.152 seconds