I’m connecting straight to the TheSky driver. I’ve no idea why SB are recommending using a hub, there’s no obvious reason.
thanks Chris - and I’m assuming you can connect PHD2 too to the driver. Clear skies on Sat night, so I will give it a go.
I’ve been able to connect more than one application to TheSky but to start with I suggest trying a test just to see how the side of pier change behaves with nothing else running.
Can you do this in daylight? I can do a quick align and set up a simple sequence that will track across the meridian and do the flip and nothing else.
It seems better to reduce the number of variables to start with, once that is working add extra things until it fails.
A huge benefit to this approach is that it doesn’t waste precious imaging time.
Hi Chris - yes, it occurred to me too that I could use the ASCOM camera simulator and disabled autoguiding and centering to allow the sequence to run.
With centering turned off and still using your driver through the Generic Hub - it worked fine and I could not make it go wrong. A little bizarre.
It is a clear night tonight, so I have left the computer on and will try it in anger with centering re-enabled, real cameras and a direct connection to the driver. (I have to use centering as I do not have a permanent setup and don’t bother with TPoint.) I’ll monitor it closely and see what happens, noting the log times.
If the pointing state changes correctly with centre off then it looks like the sync after the meridian has been passed causes the pointing state to change.
If so it’s a SB problem and they are the only ones who can fix it. The TheSky driver is merely the messenger. It reports what TSX tells it.
I suggest that you contact SB.
Further tests (real devices this time) on the same subject - with a direct connection to the latest driver (no generic hub) and with centering on set in the meridian flip settings caused another fail. I will try again with centering off.
The error message occurs immediately at the point the small SGP meridian flip timeout box disappears and before the large slew and centering process box appears, i.e. before any sync - as it has not yet taken the initial reference image for the platesolve. In that case, if I understand your logic, that does not sound like a SB error? (I just checked the log files the only ‘synctocoordinates’ and ‘synctotarget’ occur on the auto-centering at the start of the sequence (17:10:24) and after the failure at 18:32- when I manually re-slewed, centered and resumed.)
What I don’t understand is the difference between the two driver versions, I think you wrote both Chris. If both drivers are simply passing through TSX side of pier - why does the old one work?
The log files are in the dropbox folder. The time of the failure is at 18.29:
Thanks for the feedback buzz, just what I wanted.
I agree, not a SB problem.
There doesn’t seem to be any attempt to do anything at all, all the messages in the SB log are get commands, reading things. There’s no sync command.
The pier side remains West throughout and there’s no obvious reason why a slew to the current coordinates should not work and a little later, at 18:30:21.106, this is done and the pier side changes to East.
I’ve tried combining the SGP and SB log data for the relevant area, here:
[13/12/2014 18:27:22] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[13/12/2014 18:27:22] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
…
18:28:57.426 CanSlewAsync Get - True
18:28:57.428 m_SkyTele.GetRaDec Ra 23.3457957727223, Dec 61.2108975926937
18:28:57.428 RightAscension Get - 23.3457957727223
18:28:57.429 Declination Get - 61.2108975926937
18:28:57.431 Altitude get - 78.9647461607485
18:28:57.432 Azimuth Get - 334.014399843888
18:28:57.448 SiderealTime Get - 0.0143952152011408
18:28:57.461 Get - pierWest, sop 1
18:28:57.492 Connected Get - True
18:28:57.496 Connected Get - True
18:28:57.497 CanSetPierSide Get - False
18:28:57.510 Get - pierWest, sop 1
18:28:57.522 Get - pierWest, sop 1
[13/12/2014 18:28:57] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: -349.971008362818 >= 10
[13/12/2014 18:28:57] [DEBUG] [Sequence Thread] Running blocking meridian flip…
18:29:02.429 CanSlewAsync Get - True
18:29:02.432 m_SkyTele.GetRaDec Ra 23.3457952488855, Dec 61.2109270725568
18:29:02.436 RightAscension Get - 23.3457952488855
18:29:02.436 Declination Get - 61.2109270725568
18:29:02.438 Altitude get - 78.9590302097353
18:29:02.439 Azimuth Get - 333.971083476527
18:29:02.457 SiderealTime Get - 0.0157890198117236
18:29:02.470 Get - pierWest, sop 1
…
18:29:32.720 CanSlewAsync Get - True
18:29:32.723 m_SkyTele.GetRaDec Ra 23.3458015893441, Dec 61.2110433804652
18:29:32.723 RightAscension Get - 23.3458015893441
18:29:32.724 Declination Get - 61.2110433804652
18:29:32.727 Altitude get - 78.9246126752253
18:29:32.728 Azimuth Get - 333.71223164758
18:29:32.745 SiderealTime Get - 0.0241582686476924
18:29:32.754 Get - pierWest, sop 1
18:29:35.272 Connected Get - True
18:29:35.274 Connected Get - True
18:29:35.275 CanSetPierSide Get - False
18:29:35.289 Get - pierWest, sop 1
18:29:35.302 Get - pierWest, sop 1
[13/12/2014 18:29:35] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (False)
I’ve removed duplicates but not, I hope, anything relevant. The data should be fairly clear.
Jared and Ken, can you see why the meridian flip should fail?
Chris, Ken and Jared - for info, after the flip error message I manually re-slew and re-center the target. Just before the fog came down again, I moved the telescope round to the west side, pointing east at the same approx declination and ran a short sequence with centering disabled. I nudged the scope round in RA in TSX so it would flip on the next exposure.
The Meridian flip worked and the mount started to slew round - at which point I aborted it. The comparative log entries are right at the end of the updated log files (with ‘success’ in the filename), around 20:15:42.
If there is anything you want me to try. Please let me know. It might make sense to put the old driver back on ASCOM.org site in the meantime?
I think we need some feedback from Ken or Jared on exactly what is causing the meridian flip to fail in this part of the log…
[13/12/2014 18:27:22] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[13/12/2014 18:28:57] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: -349.971008362818 >= 10
[13/12/2014 18:28:57] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[13/12/2014 18:29:35] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (False)
[13/12/2014 18:29:35] [DEBUG] [Sequence Thread] ASCOM (QSI) Camera: Attempting to abort exposure…
[13/12/2014 18:29:35] [DEBUG] [Sequence Thread] ASCOM (QSI) Camera: Exposure aborted…
There’s a 35 second pause where there’s nothing reported, then the failure then a message about aborting an exposure. Could this be significant? There’s nothing going on in the TSX log.
The only other thing is that the degrees past to flip is reported as -349.97 rather than 10.03, could that be significant? I know it’s the same angle.
Sync is working with no problems, I can see several earlier in the sequence. It doesn’t look as if there is one being called at all.
There’s one possibility - I check the range of the Ra and Dec coordinates sent to the SyncToCoordinates and if they aren’t in the range 0 to 24.0 or -90 to +90 will throw an exception. This isn’t logged in my SB log. If SGP is sending a parameter that’s out of range it will get an out of range exception. The hour angle of -349 makes me wonder if this could be happening.
I went back into my older logs and have added a further logfile into the dropbox folder - this is using the old driver with SGP centering option enabled. Meridian flip is around 20:28.
This is showing the degrees past the meridian as +5.007 degrees.
The flip that fails reports degrees past meridian as -349 degrees. If SGP is converting that to a sync Ra it may not be setting it to the allowed range of 0 to 24 hours. That will cause an exception to be thrown.
We really need Jared or Ken to help with this. We need them to say what is causing the meridian flip to fail from their perspective.
Chris
It’s been 25 days now with no response, what’s going on?
I’ve done my best to report what is going on and tried to do my best in reporting things clearly.
There’s no shame in having a bug in SGP, it’s so big that some are inevitable, but it’s not very professional to ignore prblems.
By the way, I’ve seen another log, this shows the meridian flip being started:
[10/01/2015 23:13:11] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 13.8221704809012 >= 15
When I learnt to do arithmetic I was taught that 13.8 was less than 15. Is this some strange SGP arithmetic where that’s not the case?
Chris
Certainly not ignoring problems but sometimes we can’t reply to everything.
Unfortunately there isn’t enough logging around what the actual problem is. The error that is being reported by SGP is too vague. I’ll add some additional logging around the flip to see if we can get to the bottom of this.
I’m guessing this flip was invoked manually? There’s a path in which this would be output but only if the flip was invoked manually.
This is doubtful as we only sync to the coordinates that the plate solver returns to us.
There seems to be some weirdness here. The hour angle seems suspect. We compute the hour angle by the RA and LST as returned from the scope.
Thanks,
Jared
Let me add that I also have a great interest in seeing this issue resolved in a timely manner as I have a SB Mty on order and a working automatic meridian flip is very important to me as I’m sure it is to others.
From all accounts the Mty is going to be a very successful mount and SGP is a great piece of automation software and one of the few that I know of that doesn’t require yet additional software to work with the Paramounts. Getting these two products to work well together would be a win win for everyone and I hope SGP, SB and driver developers can work together to iron out issues,
Thanks,
Marty
Ditto here…
Hey Folks - let’s all get a sense of perspective. We had a functional TSX driver and it is unfortunate that Chris’ upgrade has an issue with centered meridian flips and SGP.
Let’s work together to find the solution.
Chris R: - When I tried your driver with simulators, they worked (I think you wrote the simulator too if I am not mistaken?) I’m thinking aloud but wonder if the pass-through of the hour angle is being converted incorrectly between number types (ie signed vs unsigned integer).
Anyway I will get log files for two scenarios, staying clear of the simulators- with and without centering and using the new TSX driver. You know what the UK weather is like right now, so I will do what I can as quickly as possible.
I really wish that you would not post the old driver Buzz. It doesn’t help me get the data I need.
I don’t provide the hour angle, LST and Ra yes, but Hour angle is not in the ASCOM specification. Both drivers get LST and Ra from TheSky using the same functions. Errors in this would be obvious.
I also read the side of pier from TheSky. This is also done in the same manner in the new driver as in the old one.
The GOF would call this the Facade pattern, I’m converting data from one format to another. Another way is to say that I’m just the messenger here. I can’t see how calling the same functions works in VB6 but not in C#.
This won’t get looked at until I get some log files. In particular log files from the TheSky driver. This will give me the data I need to work out what is happening. Log files from SGP for the same times will help.
There’s another person on the SB form with this problem - Chris Woodhead. I’ve asked him for logs as well.
Chris
All, Both drivers can be installed on the PC at the same time and simply selected from the ASCOM dropdown list. Personally, I am completing a book and need the functionality of the old driver to finish off the last images to meet my deadlines. The need for unattended meridian flip may be an immediate need for others too and with that in mind was the reason for sharing the old driver.
However, as Chris R says, unless we supply log files with the new driver, it will be difficult to track down the issue. I for one will dedicate some time to deliberately invoke the issue and copy log files and a screen capture video for later analysis. If anyone has clear skies this week, it would be brilliant if you can do the same. You need to enable the logging function in the driver setup screen. Please also note if you have the auto-center feature on the meridian flip enabled. I recall it made a difference.
Chris, I saw angles in the log file and just assumed it was something like HA. No problem.
thanks
Chris Woodhouse
Chris,
I’ve been asking for log files for the driver from you since you first reported this a month ago, it’s a bit depressing to get nothing other than complaints that this isn’t working.
The SGP log seems to be reporting hour angle but it must be deriving this from Ra and LST. I’ve no idea where these are obtained. If I had a log file I would know if they were coming from the driver.
BTW what mount do you have buried under all this equipment?
Jared,
The original full SGP log was posted by Chris Woodhouse, aka Buzz, about a month ago. There was a link to it but I think it’s gone. I tried to extract what I thought was relevant and my comments are back in this thread. From what I could see there was a 35 second pause during which the decision that a pier flip could not be done was made but there was no reason that I could see.
The line I quoted where 13 was considered to be more than 15 came from a log file that Chris W posted on the SB forum. This one is still in ChrisW’s dropbox. It’s so busy, with entries from GNS, PHD2, autofocus, filter, and so on that it’s difficult to see what is happening but there’s a meridian flip starting at 23:13;11 and finishing at 23:18:17
Chris W will know but I don’t think there was any manual intervention.
I look forwards to getting some feedback, both from Jared and the users.
Chris
RA and LST are pulled from the ASCOM driver and used to compute HA:
private double GetHAWithRA(double ra)
{
double lst = GetLst() * 15.0;
return (lst - (ra * 15));
}
override public double GetLst()
{
try
{
if (tel == null)
return 0;
return tel.SiderealTime;
}
catch (Exception e)
{
Logger.debugln("ASCOM Telescope: Error in GetLst",e);
return 0;
}
}
It appears the log in post #36 is not an error. If a log with an error is available I can look into it some more.
And yes, the PHD2 implementation in 2.4 is a little chatty at the moment. This will be trimmed down before we release 2.4.
Thanks,
Jared