¿ªÔÆÌåÓý

DEC error post L6 upgrade


 

Good news is that I was able to select 3 targets and each time the mount was pretty accurate and no problems making corrections like before.

Strange news is that my guiding was awful when selecting it through PHD2, but when NINA automatically started it the guiding was good. Some research to do (later).

Bad news is I have really no idea what my problem was, or the exact method to resolve it (so not much help for others). I still have odd issue with NINA reporting my time differs from the mount, yet both Windows PC & mount are spot on. I think at one point I was using this Windows as a NTP source before switching to a NTP on my Linux server. I may set the mount to use the same machine as NINA to see what happens. This could be a NINA problem and not a mount issue.?

All in all I had wanted to get to L6 as I intended to finally get Pempro after seeing the announcement that it now supported L6, so kind of finally motivated myself to get it. But first I had to do the upgrade. Ultimately somewhere along the way I made a mistake that plagued me for over a week.?


 


Update v41b

Several nights without issue, and then we had a clear night so I went to do the usual routine. Except this time the problem re-occurs, I had M81 in Framing and selected Slew & Center, and the same problem that it just can not correct DEC. I went to a different target and same thing. Went back to CWD park, disconnected everything and power cycled the mount. Reconnect NINA & Cartes and everything was back to normal/good.?

So since the previous good evening and last night, nothing much changed, but the "problem" does reoccur but then seems to fix itself.?


 

Need troubleshooter and NINA logs, Sean. There¡¯s nothing to go on, except for your reports of intermittent unexplained behavior.


 

On Sun, Jun 2, 2024 at 02:50 PM, Paul Kanevsky wrote:
Need troubleshooter and NINA logs, Sean. There¡¯s nothing to go on, except for your reports of intermittent unexplained behavior.

?

Paul,

I upload NINA and Troubleshoot logs to new folder " L6 Dec Issue". This was around 10:20-10:30 CST. By 11:07 I was able to start a sequence.


 
Edited

Thanks, Sean. I'd have preferred the full zip file that is generated by the Troubleshooter, as that includes ASCOM logs which are not in the folder you created. Other than that, a quick review I see the following that troubles me, but then, I'm not sure if I'm reading the NINA log correctly. From your Gemini report, you are not using J2000 coordinates:

Precession=False
Refraction=False

Yet all the target coordinates in NINA log appear to be precessed J2000. Not sure if that's how it should appear in the NINA log, or not, but this could be the reason slews are not winding up where NINA expects them. An ASCOM driver log for this session would help clarify what actually happened there:

2024-06-01T22:22:56.8056|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|912|Slewing from RA: 09:54:35; Dec: 69¡ã 04' 41"; Epoch: J2000 to RA: 09:52:46; Dec: 69¡ã 01' 48"; Epoch: J2000


Is there a reason that you have Sync disabled in the NINA centering routine?

2024-06-01T22:23:18.0369|INFO|CenteringSolver.cs|Center|95|Sync disabled

If you can share the ASCOM driver log for that session, it might help determine what happened and what coordinates were actually provided to Gemini.

Regards,

? -Paul



 

On Mon, Jun 3, 2024 at 09:46 AM, Paul Kanevsky wrote:
If you can share the ASCOM driver log for that session, it might help determine what happened and what coordinates were actually provided to Gemini.
Last night I went out just before 10:00PM and this time I experienced DEC worked fine, but RA was not correcting. I saved the logs for this period under subfolder 06-03, and the log files should contain just the period from 22:00~22:16 for ASCOM and 19:26~22:17 for NINA. Knowing what I know now the best path is to shut down/disconnect everything prior to starting and clearing logs. Since my telescope is in a Skypod it is powered on & left connected so the log did not rotate or start new for that session. Result is 1GB+ ASCOM log.?

The log files stop at around 22:16 because that is when I decided to disconnect and shut down everything. Prior to this I did check in Gemini "Gemini expects J2000", and did select in NINA to both Coordinate and Time synch? earlier that day.? After Cold Start of mount, disconnecting and reloading NINA, deselecting and then selecting "Gemini expects..." I was eventually able to plate solve > correct > continue. By this time it was late, I was tired, and so when it slewed correctly to M81 and started sequence I went to bed. It looks so far that that evening everything went as expected. Only a glance at M101, M51, etc.. but they do look centered correctly.
?
Better option would be in the next day or so we are going to have clear skies. Before I start up everything I am going to clear all logs and start fresh (i.e. power cycle mount, reopen NINA, etc.) and if I experience the same issue the log files should be a little more better condensed.?


 

Problem not solved, but I may be on to something. The other evening and tonight I encountered the same problem. But these last 2 nights it was RA that would not correct (whereas before it was always DEC could not correct).? So like the time before after plate solving fails to center I set the mount to park, rebooted Gemini, reconnected and disconnected etc. Finally when I was almost ready to give up I tried something. Went into Gemini Settings and unselected "Gemini expects J2000....", then went to slew and center and it worked. Now 2 nights I encounter this issue, 2 nights it is RA

This is after deselecting J2000 in Gemini:
2024-06-05T22:21:43.0058|INFO|CenteringSolver.cs|Center|85|Centering Solver - Scope Position: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00¡ã 00' 00"; Distance: 00¡ã 00' 00"; Bearing: 00¡ã 00' 00"; Centering Coordinates: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Solved: RA: 09:54:35; Dec: 69¡ã 05' 08"; Epoch: JNOW; Separation RA: 00:01:57; Dec: -00¡ã 00' 04"; Distance: 00¡ã 10' 29"; Bearing: 89¡ã 27' 05"; Threshold: 1

2024-06-05T22:22:09.6259|INFO|CenteringSolver.cs|Center|85|Centering Solver - Scope Position: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00¡ã 00' 00"; Distance: 00¡ã 00' 00"; Bearing: 00¡ã 00' 00"; Centering Coordinates: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Solved: RA: 09:56:30; Dec: 69¡ã 05' 09"; Epoch: JNOW; Separation RA: 00:00:02; Dec: -00¡ã 00' 04"; Distance: 00¡ã 00' 14"; Bearing: 71¡ã 32' 16"; Threshold: 1

It basically takes only 2 tries.


 

As I said from your logs, it appears that NINA was precessing all coordinates to J2000 while Gemini thought the coordinates it was getting were JNow. That's certainly a cause for concern. Not sure how that could've happened, but in your second set of logs, both were set correctly (or at least agreed with each other): Gemini expected J2000 and NINA sent J2000 coordinates. Let's see if the JNow setting keeps working for you :)

Regards,

? -Paul


On Thu, Jun 6, 2024 at 12:49 AM, Sean wrote:
Problem not solved, but I may be on to something. The other evening and tonight I encountered the same problem. But these last 2 nights it was RA that would not correct (whereas before it was always DEC could not correct).? So like the time before after plate solving fails to center I set the mount to park, rebooted Gemini, reconnected and disconnected etc. Finally when I was almost ready to give up I tried something. Went into Gemini Settings and unselected "Gemini expects J2000....", then went to slew and center and it worked. Now 2 nights I encounter this issue, 2 nights it is RA

This is after deselecting J2000 in Gemini:
2024-06-05T22:21:43.0058|INFO|CenteringSolver.cs|Center|85|Centering Solver - Scope Position: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00¡ã 00' 00"; Distance: 00¡ã 00' 00"; Bearing: 00¡ã 00' 00"; Centering Coordinates: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Solved: RA: 09:54:35; Dec: 69¡ã 05' 08"; Epoch: JNOW; Separation RA: 00:01:57; Dec: -00¡ã 00' 04"; Distance: 00¡ã 10' 29"; Bearing: 89¡ã 27' 05"; Threshold: 1

2024-06-05T22:22:09.6259|INFO|CenteringSolver.cs|Center|85|Centering Solver - Scope Position: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Offset: RA: 00:00:00; Dec: 00¡ã 00' 00"; Distance: 00¡ã 00' 00"; Bearing: 00¡ã 00' 00"; Centering Coordinates: RA: 09:56:33; Dec: 69¡ã 05' 04"; Epoch: JNOW; Solved: RA: 09:56:30; Dec: 69¡ã 05' 09"; Epoch: JNOW; Separation RA: 00:00:02; Dec: -00¡ã 00' 04"; Distance: 00¡ã 00' 14"; Bearing: 71¡ã 32' 16"; Threshold: 1

It basically takes only 2 tries.


 

To close out this topic and give a summary; My solution was to insure "Gemini expects J2000" to be deselected when using NINA. As this was in a screen I rarely if ever looked at I can not remember if this was ever selected. I can say if the topic was covered by Brian V in any of his tutorial vids I would have followed whatever was advised. When I first purchased my mount I had a good few weeks where the mount sat in my room just watching the tutorials.?

With a number of days & sessions now everything is working as expected. With a few good sessions behind me now I am glad I did make the upgrade. My guiding does seem to have improved. When I look at the RA/DEC/total they have improved. Below are just a few examples and after looking at multiple sessions pre & post the numbers below are reflective.
L6:
RA:? ? ?0.30" (0.14 px)
DEC:? 0. 28" (0.13 px)
Total:? 0.41" (0.19 px)
L5:
RA: ? ?? 0.57" (0.19 px)
DEC:? ? 0.97" (0.32 px)
Total:? 1.12" (0.38 px)

Did have one scare, while I did calibrate in PHD2 when I had changed cameras & guide scope, the guiding would start off good then all of a sudden completely drop off. Problem solved using the Calibration Assistant. One other strange phenomenon that probably has an easy explanation. I have lived here for 3+ years with a mount on a ground level deck. If I walk in/out of my Skyshed Pod it will screw up guiding. Oddly the train track nearby that shakes my house never seemed to affect guiding. I could not understand that as I expected it would result in some blips. But for 3 years whenever the trains passed by I would not see any change in guiding. Until now. Last night was 1st time I ever saw my guiding errors jump up while a train was passing, once it passed numbers dropped down. Hour later the same thing. Errors are being corrected so it does not have much an impact, just strange it is visually seen now in PHD2 whereas it was not previously.?


 

Must be all that extra resolution. The ASIAIR Plus I have been using for a few years saw the tracking error drop about 15-20% after going to L6.x I have not got the most steady or consistent skies here in L.A. but the L6 updates seemed to work.?

--

Chip Louie Chief Daydreamer Imagination Hardware?

? ?Astrospheric Weather Forecast - South Pasadena, CA?


 

Good to hear you got it working, Sean. The "Gemini expects J2000" setting is off by default in the Gemini.NET driver. You must have turned it on at some point for it to be active. The setting is there to accommodate software that can't precess coordinates to JNow. NINA handles both, JNow and J2000 correctly when this setting is changed. Perhaps there's something else in your software set up that is causing J2000 not to work with Gemini, but if it works with JNow, there's no need to change it.

Glad to hear the guiding has improved with L6! Not sure how the new firmware could change the effect of passing trains, perhaps something else has changed mechanically in your setup.

Regards,

? -Paul


On Fri, Jun 14, 2024 at 11:12 AM, Sean wrote:
To close out this topic and give a summary; My solution was to insure "Gemini expects J2000" to be deselected when using NINA. As this was in a screen I rarely if ever looked at I can not remember if this was ever selected. I can say if the topic was covered by Brian V in any of his tutorial vids I would have followed whatever was advised. When I first purchased my mount I had a good few weeks where the mount sat in my room just watching the tutorials.?

With a number of days & sessions now everything is working as expected. With a few good sessions behind me now I am glad I did make the upgrade. My guiding does seem to have improved. When I look at the RA/DEC/total they have improved. Below are just a few examples and after looking at multiple sessions pre & post the numbers below are reflective.
L6:
RA:? ? ?0.30" (0.14 px)
DEC:? 0. 28" (0.13 px)
Total:? 0.41" (0.19 px)
L5:
RA: ? ?? 0.57" (0.19 px)
DEC:? ? 0.97" (0.32 px)
Total:? 1.12" (0.38 px)

Did have one scare, while I did calibrate in PHD2 when I had changed cameras & guide scope, the guiding would start off good then all of a sudden completely drop off. Problem solved using the Calibration Assistant. One other strange phenomenon that probably has an easy explanation. I have lived here for 3+ years with a mount on a ground level deck. If I walk in/out of my Skyshed Pod it will screw up guiding. Oddly the train track nearby that shakes my house never seemed to affect guiding. I could not understand that as I expected it would result in some blips. But for 3 years whenever the trains passed by I would not see any change in guiding. Until now. Last night was 1st time I ever saw my guiding errors jump up while a train was passing, once it passed numbers dropped down. Hour later the same thing. Errors are being corrected so it does not have much an impact, just strange it is visually seen now in PHD2 whereas it was not previously.?

?


 

Thanks for the wrap up Sean. ?Many threads get left ¡°hanging¡± and it hard to know if you are actually helping. ? So a good wrap up feedback is very important import for other to learn from. ?


Cheers
--
Brendan