here is a link to the log file just created
here is a link to the log file just created
Good to hear that it’s going.
The commands and responses should give details of the data that the mount is sending to SGP and will help to find out what’s happening at the time that the meridian flip time changes. It will probably need the csv log and the SGP log for the same sessions.
Yes, WiFi is just another thing to go wrong. Hard wired connections are much more reliable and the simpler the better.
Just seen the csv log, it’s returning Ra, Dec, Alt, Azm, sidereal time and side of pier. Now to see what happens when time changes.
I have recently changed to a 10 Micron GM1000HPS and do not appear to have a problem with my time to meridian flip. I have been away from home for a few days (and am away this weekend) however, I will try to get into my obs tonight and check settings.
I know that the location setting in the handset will set your hemisphere and I had initial confusion setting the local time - UTC and Timezone offset and DST - due to the phrasing in the manual. I stupidly was setting UTC as my local time on the day (GMT+1hr for British Summer Time), then setting Timezone as +1 (becuase I was ahead 1 hour due to DST) and then ticking the daylight saving time option. I found the time on my handset was off by 2 hours and it took me a few attempts to get my setting correct! So, at the sake of driving you nuts, do a triple check of time. If you are slewing accurately, it displays correctly on the handset and tracking unguided well it must be set right (as you say).
There is a Mount Logger available on the 10 Micron site for download. Which 10 Micron firmware version are you running? I run 2.13.6 the current version for the 1000HPS (there are other beta versions available). I use Per’s driver and it is straightforward to use.
I connect using an ethernet cable via router - your issue could be related to the wireless connection but I’m not sure. I have the wireless version too but have only used the ethernet cable. You could try posting on the 10 Micron forum for help too if you haven’t already.
Happy to help if I can,
Sidereal time looks decent. Not sure about Long/Lat as I don’t see that anywhere. It’s really interesting that it takes such a massive jump from 22:56 to 23:06, but I can’t pin down why.
If you could do this same test again. But provide the telescope log and SGP log for the same run we can correlate those things together and see where the misinformation is coming from. I’ll keep mulling over these logs and see if anything pops out.
Chris got me dialed in on getting a log from Per’s driver. So tonight (it looks like the weather will be willing) I’ll turn Meridian Flip on and post the log from Per’s driver and the sgp log after the time jump. Unfortunately, as fate would have it, tonight will be my last shot for almost a month as scheduled travel will take me away from home. Hopefully the data from tonight will be enough to locate the problem [of course, we all know how it goes — the automatic flip will just work tonight ;-)] I will triple check again tonight time; dst; lat/lon in the mount and computer. These have all been checked at least twice, but when things don’t make sense sometimes when you go back and check that third time you find you had been seeing what you expected and not what was. But even if one of these were wrong I cannot imagine how that could cause a jump in the hour angle SGP tracks to decide when to flip. As I said before a really odd fact is the displayed “time to to flip” jumps way ahead to -3:59:31 one night and -3:59:26 another and then does not appear to change. I did note that an auto focus run seems to have happened just before the massive jump in HA. That could be coincidence or a clue. It sort of has the feeling of what would happen if SGP (I have no idea how it is implemented) has a pointer to the cell where HA is updated and somehow that pointer is overwritten so it now points to some random piece of memory. If the data I (hopefully) capture tonight does not lead to an answer, perhaps looking at the code and tracing the HA calculation backwards and then logging all its inputs in the SGP log as time passes might be helpful.
I appreciate the effort you all are putting in to fixing this. It will save me much sleep! Also,as an unfortunate aside, wanting to not stay up so late for a 3rd night in a row I tried to flip early (the 10Micron will flip 30˚ before if you want) . By inspection I believed, incorrectly, I could flip at 9˚ early. Oops, small mount crash. Turns out there is a adjustment screw that sticks out almost an inch from my FW and it was positioned perfectly to hit the tripod leg at the end of the flip. Other than a scratch on my new tripod, which shall serve as a reminder to not cut corners, all is well. I waited 20 minute to make sure it was safe, slewed back, re rotated (the impact had rotated the camera almost 21˚) and continued on. So, my brilliant move to get to sleep earlier kept me up another half hour past transit and cost me 5 subs. Geesh. I’m sure I am not the only one who can confess to such an error
If we can’t figure it out from your logs this is what we’ll do. Hopefully it doesn’t come to that.
Remember the line “It was the Dukes, It was the Dukes” from Trading Places? Well, “It was the mount, It was the mount!”
I just posted the following on the 10Micron forum
I have a new GM1000HPS with which I am generally pleased. But I have not been able to do unattended meridian flips because SGP tried to flip hours too soon. With the help of the SGP folks I was able to capture the SGP log and the log written by Per’s driver. What became immediately clear is it is not Per’s driver or SGP, but rather the mount which is the source of the problem. Tonight I’m running a series of 6 minute subs, the scope was at az/alt 75.2/59.7 when it started what was probably the 9th sub. The prior sub occurred at LST 17.55794. For this one, and all subsequent subs, :GS# returned 24 (23:59:59.99). To make sure it was not a driver or logging issue I went to the physical hand controller and sure enough LST is stuck at 23:59:59.99. Since SGP uses hour angle derived from the mount’s data to decide when to flip, once the LST jumps to 24, it tries to flip even though LST is actually <18 at the time. Of course the mount refuses and SGP terminates the session. Help please – staying up to babysit flips is killing me!
The HC reports version 2.13.16 which appears to be the latest released firmware
The following are set in the HC and are correct for my location
time is set from the computer and the HC displayed time match local wall clock time
Thanks to all here who helped me figure out what was going on.
I knew it had to be something coming from the data we were getting! Just didn’t know what as everything was looking ok…until it wasn’t!
Let us know how things work out.
Thanks Jared and apologies for wasting your time – but I probably would not have figured it out with Chris and your help.
Unfortunately, I will be out of town for 3+ weeks but I’ll make whatever progress I can without access to the mount. It is hard to imagine it is a firmware issue because others would presumably be facing the same issue. That leaves hardware, but that seems a long shot too.
I’ll post back here when it gets all sorted out.
According to Ed Thomas, who forwarded my reports to 10Micron as an authorized distributor, the folks at 10Micron have confirmed a flaw in their reporting of sidereal time. According to Ed, they indicated that a new mount beta firmware addressing this problem will be uploaded to the 10Micron forum shortly. Unfortunately I will not get to test if for 3 weeks or so.
Thanks again to everyone here who helped me get to the bottom of this. I must admit, it did not occur to me that the flaw might be in the mount.
Many years of debugging this sort of thing have convinced me that it’s not worth speculating about the cause of a problem without evidence. This is in contrast to most of the internet where wild speculation and leaping to conclusions, usually the worst, seems practically compulsory.
I’ll have a gm1000 coming soon in my obs… Could please someone test if with new firmware update flip problems are solved and frejvall driver continues to work properly?
Thanks in advance
I watched this topic very closely. Last night I did some Imaging on IC5070. About 01:00 in the morning there has to be a flip. The session was done without any problem.
Using: SGPro 2.5.17 and GM1000HPS with FW 2.13.22. Autoflip off in mount. Flip is done via SGPro.
I’m probably jumping the gun here, since we’re now in a Midwest monsoon. A couple nights back, I saved a sequence while my imaging was going on in SGP. I labelled it AGO FLI. Previously it was called SEQ 2. The next night when I went to use the newly created sequence, I had a similar occurrence that rgbtxus is reporting here. Time to Meridian flip was showing and not Time to Pier Flip…-2.22hrs. This time did not change thru out the evening and after the first image was completed, a pier flip was attempted and failed of course. That’s when I noticed the lower right hand window showing the odd ball time to pier flip. I then turned off auto meridian pier flip and continued to image through the session. At pier flip time I ran a manual flip and all imaging continued for the rest of the session. I am using Per’s 10u driver.
What I now think could be happening is that the time from the mount and saving the live run sequence may have screwed up the newly created sequence. My reasoning is as follows:
1.) The Sequence 2 (SEQ 2) file does not report the time error that the AGO FLI SEQ shows.
2.) Yesterday, before the rains set in, I ran both sequences with equipment connected. SEQ. 2 showed time to pier flip. AGO FLI SEQ. showed the exact same time error and reported time to meridian flip, not time to pier flip.
3.) I have yet to look at the logs for both sessions, so I can’t give anymore information for now. Not at that computer. Based on what I have seen in this post and my own experience, it appears that saving a sequence while doing an active imaging session may have contributed to the problem. I have used SEQ 2 successfully for daytime meridian flips with Per’s driver, but have yet to use it for an actual evening session involving a meridian flip. When I did use SEQ. 2 it was at a post meridian flip time and all went well.
When the lightening tapers off, I will look at the logs and see if there is a clue presented. I can post the logs if that may help others....................Gunny
Last night was the first time I was able to successfully do meridian flips without a problem. Turns out the problem was the firmware version of the 10 micron mount and my poor daytime testing procedure for pier flip. I was using ver. 2.13.6 which had a glitch with the LST. LST would lock at midnight after the first image was taken and result in no pier flip. SGP would report time to meridian flip as a negative at this point. I have since installed the latest beta version of firmware from 10u ( 2.14.4 ) and all worked flawlessly with SGP. Besides the firmware revision, I set the flip, and guide tolerances’ to 3 and 5 in the HC and -5 for the time to flip setting in SGP.
Where I was fooled by the daytime testing was only taking one image in the time b4 a meridian flip. All worked well. In the evening, where I was taking multiple images b4 the flip, the LST problem would appear randomly during the sequence and result in my having to do manual flips.
I’m relatively new to the 10u mount and definitely a novice when it comes to SGP so I’m really grateful to Jared and Ken for this great piece of software. Just wish I had discovered it before I wasted my money on brand x and maxim. Your autofocus routine is the best I’ve come across. When you consider that focusmax costs $150, there is no doubt that SGP is the best bargain out there. Again, my congrats to you guys and thanks for your hard work on SGP …Gunny
Do you have the SGP option ‘Wait for Meridian’ ticked in the Flip options?
Yes, I do have that checked along with auto center after meridian flip and -5 for time to meridian flip. I’ve had several nights now where all has gone well with SGP and the 10u mount. Hope that helps…Gunny