Ok this is really weird. A few days ago I got a new GM1000HPS mount. The first two session didn’t happen to need a flip, but yesterday and today did. Both nights, after shooting 1 sub it tried a meridian flip — way way too early. Lets forget about last night because I did not keep good notes. Here is the situation tonight.
My time zone is UTC -6 and daylight savings time is in effect. (Dallas TX)
My computer and mount agree on this and agree as to wall time
The SGO telescope control panel says
time to meridian -3:59:31 and that is not changing as time moves on
at the moment the mount is pointing at az/alt 110/67 – very far from a flippable state and it of course refused SGP’s flip request
The correct location lat/lon is in the scope.
Anyone have any idea what the heck is going on???. BTW the same SGP box that shows the bogus time to meridian shows the proper RA/DEC for the scope (well it looks right – they don’t match because the scope is displaying JNOW and SGP J2000. I’m using Per Frejvall’s driver, as do the vast majority of 10Micron users, and it converts J2000/JNOW as needed.
Dennis, thanks for the thought. I don’t think so, but that seems like it could cause this sort of behaviour. I checked the mount twice, I’ll recheck on next power on but I’m pretty confident it has the correct lat/lon set which I assume it uses to derive a notion of what hemisphere it is in. Also, IIRC the PAE display was of the form 00:00:43 which would mean the mount knew it was in the northern hemisphere. And of course it tracks beautify which I do not know if it could do if it were confused about which side of the equator it was on. I searched the manual and there is no hemisphere setting that I missed in the menus. I assume anyone else who cares, like SGP, gets their notion of hemisphere from the mount. Maybe pier side is not being understood.
Like Dennis mentioned, I would check Lat/Lon, Sidereal Time and Hemisphere. These may be set in your mount hardware or in the actual ASCOM driver. We get the values from the ASCOM driver but it could get these from your PC or from the mount. So also double check the time on your PC.
My Gemini controller likes to switch me from West to East hemisphere whenever it resets. I think it’s time to put a new battery in. That results in similar behavior. The mount generally knows where it’s at and will track just fine, but when slews are issued things get a little weird and naturally the time to merdian/flip is weird.
You could also try disabling the meridian flip and seeing what it says for “Time to Meridian” If that seems sane then the problem could be in the meridian flip settings.
Thanks Jared. I double checked Lat/Lon, but who knows, maybe I blew it twice, so I’ll check a third time when I power on tonight. I also double checked time in PC and Mount and just to make sure I was not nuts and somehow flipped the sign on the UTC delta I checked it on my CEM60 mount. It reads UTC -360min which matches the UTC - 6 hours I set in the GM1000HPS. I guess I’ll have to double check the sign of that number tonight. I could find no switch in the mount or driver for setting hemisphere so I assume the mount derives this – after all given Lat/Lon it has all the info it needs to do so.
I did disable meridian flip – after all, I had to to continue because a resume caused SGP to attempt a flip, which the mount refused (as was proper). The “time to meridian” remained negative almost 4 hours and the computed time for the flip, unsurprisingly, was in the past. Surprisingly the “time to meridian” did not change as the night wore on. So, if it is computing it it has either been limited by some MIN or the computation does not involve the current time – which seems impossible.
I suppose a possible complicating factor is the mount will track and slew 30˚ past the meridian and go weights up. I have disabled that via mount settings since I did not want to fuss with that until I was comfortable with “normal” operation before I worked out what I could allow with my gear while avoiding mount crashes. I remember I also double checked that those settings were in place last night. IIRC I set it to go 1˚ past the meridian.
In answer to Dennis’s subsequent note. I was not using any other program like Stellarium that might be talking to the mount except the 10Micron software hand controller. I will try shutting that off tonight and see if it imapacts the behavior, but that seems like a long shot since I assume 90+% of 10Micron users use it and there must be some 10Micron SGP users out there – certainly John Wainwright, whose mm.py I am using.
Thank you all for taking the time to help me sort this out. I am loving the 10Micron, but I clearly have some things to work out
For reason that are unclear this problem appears to have spontaneously disappeared. Between last night and tonight, where time to flip is positive and counting down, the computer was not rebooted, sgp was not stopped and restarted. In fact, its target was not changed, no times or time zones where changed anywhere and the driver was left on align on sync as it was last night. What did change is, on a recommendation, I changed the driver from J2000 to JNOW. I did not build a new model tonight. I did slew to vega and do a plate solve and sync from SGP. We’ll see if it continues to behave and flips at the correct time. Of course the mount was powered off and powered back on between the nights.
DARN! right after I wrote the above I checked back and now the time to flip is -3:59:39 %^$^&%$^%$ And it just failed the flip - of course. So I just turned flip off and resumed. Looks like I will have to stay up and baby sit the flip again &^%&^%&^%&^. Now, there was no interaction with the imaging computer when this happen. It appears to have been spontaneous. At this instant Az 99˚36’18", Alt 57˚58’38", RA 20h0020.0, Dec 22˚46’18". It was suggested I try the 10Micron driver and not Per’s, but before I switched, it appeared that the problem disappeared, so I am still running Per’s driver. Extremely frustration. I’ll go recheck all the time, TZs, etc now to make sure none of them were somehow changed.
If you can attach your SGP log where flip was enabled and you were imaging that may help.
Also where are you imaging? Are you fairly close to the pole? What is the RA of your target? (Or just send the log as it will answer all those questions )
Ok, here is what the log has to say
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] TEMP - Current Event2: 0
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 59.916375 >= 0
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Skipping Solve and Sync
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Stopping the Auto Guider
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[7/19/2016 11:06:39 PM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[7/19/2016 11:06:39 PM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using sideOfPier
[7/19/2016 11:06:40 PM] [DEBUG] [Telescope Thread] Setting Pier East
[7/19/2016 11:06:40 PM] [DEBUG] [Telescope Thread] Pier Flip failed when using side of pier: System.Exception: Flip requested but cannot be done at present position.
[7/19/2016 11:07:12 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope command to meridian flip has completed
[7/19/2016 11:07:12 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope failed to perform meridian flip
[7/19/2016 11:07:17 PM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[7/19/2016 11:07:17 PM] [DEBUG] [MF Update Thread] Performing serialize…
[7/19/2016 11:07:51 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Procedure complete
[7/19/2016 11:08:52 PM] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (True)
[7/19/2016 11:08:52 PM] [DEBUG] [Sequence Thread] Adding sequence level notification: Failed to meridian flip, aborting sequence.
It believes the scope is on the West side. It is (that is looking to the north while standing behind the mount the scope is on the left side). But HS is currrently -027˚20’06". SO where did 59.916375 come from???
The immediately prior sub start was logged as
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] TEMP - Current Event2: 0
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 59.916375 >= 0
[7/19/2016 11:06:39 PM] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Skipping Solve and Sync
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Stopping the Auto Guider
[7/19/2016 11:06:39 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[7/19/2016 11:06:39 PM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[7/19/2016 11:06:39 PM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using sideOfPier
[7/19/2016 11:06:40 PM] [DEBUG] [Telescope Thread] Setting Pier East
[7/19/2016 11:06:40 PM] [DEBUG] [Telescope Thread] Pier Flip failed when using side of pier: System.Exception: Flip requested but cannot be done at present position.
[7/19/2016 11:07:12 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope command to meridian flip has completed
[7/19/2016 11:07:12 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope failed to perform meridian flip
[7/19/2016 11:07:17 PM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[7/19/2016 11:07:17 PM] [DEBUG] [MF Update Thread] Performing serialize…
[7/19/2016 11:07:51 PM] [DEBUG] [Pier Flip Thread] Meridian Flip: Procedure complete
[7/19/2016 11:08:52 PM] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (True)
[7/19/2016 11:08:52 PM] [DEBUG] [Sequence Thread] Adding sequence level notification: Failed to meridian flip, aborting sequence.
Note its has HA -39.255375
So, somehow between those two sub, 10 minutes apart, the HA changed from -39.xx to +59.xx
sorry, here is the log snippet
[7/19/2016 10:56:19 PM] [DEBUG] [Sequence Thread] TEMP - Current Event2: 0
[7/19/2016 10:56:19 PM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[7/19/2016 10:56:19 PM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[7/19/2016 10:56:19 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -39.255375 < 0
[7/19/2016 10:56:19 PM] [DEBUG] [Sequence Thread] TEMP - Current Event3: 0
Jared will need the FULL log, not the snippets that you think are relevant.
Also is there any logging from the mount? If there is it could help a lot because it may give chapter and verse about the information that the mount is passing to SGP.
The full log is at Dropbox - File Deleted
The sgf file is at Dropbox - File Deleted
Ignore the 1st meridian flip, that was done by hand the prior night
Then if you just search for “Meridian Flip”, you will see the hour angles roll past as it does 10m subs
-58.089
-55.4979583333333
-52.9093333333334
-50.3202083333334
-47.7279583333333
-44.4374583333333
-41.8465
-39.255375
then bang – out of the blue (and about 10 min past the one above)
59.916375
that caused SGP to request a flip, which the mount refused given that the actual HA was still something like -37.5
I do note an autofocus run had just completed
Thanks for looking at this for me
Staying up to babysit meridian flips is no fun!
Chris,
I posted the log and sgf along with a few observations that might be useful. I just got the mount and the manual does not reveal access to a log, which I have no doubt it keeps internally. I’ll ask around and see if it or Per’s driver leave any log files behind. In any case, as you can see the mount is happily tracking in RA taking a long series of ten minute subs and then out of the blue the hour angle sgp uses to decide whether to flip jumps up from -39+ to almost 60 – a great leap forward of almost 100˚ or 6.66 hours! I don’t know where SGP gets that HA, but it is most definitely wrong because the mount reported it was where it should be and I went outside and checked and it was still happily tracking on the west side of the mount with approximately another 2.5 hours to the point where it would be ready to flip.
The latest version 6.6.5.9 has two check boxes “Debug Log” and “Comm debug Log” which look as if they may produce useful information. The log is in C:\Logs\ and you need to create this folder to get logging.
I did see those check boxes and have been running with them set. C:\Logs\ also exists. But the driver does not appear to have written anything into that directory. In case this is what is needed I just created two subdirectories under Logs with the names you quoted. The documentation I have for the driver does not show the check boxes. Thanks for your efforts to track this issue down. It looks like I will be able to image tonight too. If the driver does not put anything in those sub directories, then perhaps I should try the 10Micron driver and see if it exhibits the same problem. I have not use it so far as I have assumed it does not have the ability to continuously update refraction parameters.
Another night. Another failure. Unfortunately I just realized that since I left the automatic meridian flip switch off, none of the information logged last night appears in the log file. But when the run started SGP displayed a valid time to meridian. That continued for a while, maybe an hour. I did not witness the change, but when I checked back, time to meridian flip had once again changed to -03:59:26. And like last night, this number is not changing and as I write this the mount is pointing at hour angle -19˚ and tracking and imaging normally. My plan had been to try the normal 10Micron ASCOM driver, which I have never used before, to see if that also showed the same behavior. Unfortunately it threw an error when I tried to connect to the mount. Since I did not want to lose more imaging time I proceeded with Per’s driver. I’ve done a little reading and think the problem may be that the 10Micron driver requires a hard connection and I am connecting to the mount wirelessly. I’ll have to sort out why I could not connect. But, the bottom line is my problem remains. At Chris’ suggestion looked for the log files Per’s driver implies it creates, but so far I have yet to find such a log file. If anyone knows where to look or whatever other step I need to take to active logging, please let me know. Thanks to all who are helping me track this most annoying issue down.
I gave the wrong directory name, sorry. It should be “c:\log” with no ‘s’. What I see is a single file called dbg.csv which contains data, just saying that no mount has been detected in my case.
The code checks for this directory name and if it isn’t present won’t write anything.
I had to disassemble the driver dll to find this.
It isn’t the way I’d do logging and doesn’t use the ASCOM provided log functionality.
Thank you Chris. I just set that up (my mount is still up. It was supposed to be imaging while I slept, but of course the driver lost communication with the mount shortly after I went to sleep. Maybe connecting via wifi is not the best idea. It’s always something But the dbg.csv file was promptly made and is being populated. Probably too late for any useful data on this run. But after it does an image (too light out for it to be of any use), I’ll provide a link to it so you can see what sort of data is written. It looks like a log of command strings sent to the mount along with its responses.
)
But the dbg.csv file was promptly made and is being populated. Probably too late for any useful data on this run. But after it does an image (too light out for it to be of any use), I’ll provide a link to it so you can see what sort of data is written. It looks like a log of command strings sent to the mount along with its responses.