CCDMan I’m using SGP 2.4 (beta 4) as it was released yesterday and PHD 2.4
The test is running as I write this - I can report good news that a timed sequence start booted up PHD cycling and calibration after doing the slew and center. A/F went without a hitch and it is now imaging. It reaches the meridian in a few hours.
I’m using QSI cameras CCDMan - so I cannot help with your SBIG question. The latest driver (the one under test) is the one posted on the SB forum. The old one has gone from the ASCOM site.
By the way, it is currently guiding using DirectGuide and my Paramount MX. I have PEC enabled on the MX but there is no obvious performance difference that I can see to ST4 or Pulseguide- I imagine that seeing conditions have more effect on tracking performance and I would need to do a quick back to back test to establish any meaningful performance comparison.
I’m imaging Horsehead Nebula - and will continue as planned to prove the is/isnot theory that Chris R is suggesting. It has an RA of 5:41 - so in theory, the flip should work, even with auto center enabled.
Nothing has changed with the meridian flip in 2.4.
Thanks for the diligence here. I’ll duplicate these steps this evening and see if I can get the same result. It still seems odd that the flip would get triggered and then not run. Maybe there’s something further down that’s triggering an exception that’s getting suppressed.
OK, thanks. I may give things a try with my laptop and 2.4 when the weather clears and assuming my hardware issue with the mount was fixed today (I suspect a bad home sensor wire).
Going through your video now. Some comments as I’m watching it
You mentioned wanting to get to your focus position set in the filter dialog. You can do that by clicking the “Focus” button on the focuser tab of the CP. It will go to whatever value is set for your current filter:
I’ll work to setup a test case to check the issue that was creating a weird negative.
Thanks for the tip Jared. I have some observations on an alternative sequence order that I will put in a another thread. @Chris, it is really easy to incorrectly jump to conclusions, especially with obscure issues: I did do back-to-back tests with both driver levels and it may have been that the boundary conditions of this numerical issue were not in play during the test with the old driver level.
If you are correct in this assertion and that the two drivers are identical in regard to the pass through of this data, the error condition should also apply to the old driver level.
In your test with the AVX mount, did you confirm that? If you didn’t just let me know the settings and I’ll try and reproduce it on my dumb MX mount.
Buzz, can you please now post to all the sites where you posted saying that there were problems with the new driver saying that you were mistaken. Say that the new driver is in fact fine.
Also edit the rtf file on your dropbox site to say this.
This will help to counter the incorrect impression that you might have given people.
What is needed is to select the same target and start at a time before it crosses the meridian. That’s around 15:35 at present. You will need to turn solve and centre off of course.
My experiment showed that the time to flip will jump from a positive value to a large negative value, about -359 degrees at some time before the flip is expected. The flip didn’t happen at all for me but maybe you will be able to trigger whatever causes the fail message.
You need use an object with a Ra that’s around 23.5 to 23.999 hours and to start at about 15:35, just before it’s crossed the meridian. I get the feeling that the window size is proportional to the distance past the meridian so you may need to set the flip to something well past, such as 10 degrees.
I’m not a fan of mindlessly applying unit tests (or mindlessly doing anything else) but this sort of tricky computational problem is the sort of thing where I’ve found unit tests to be well worth using to expose the various edge cases that can happen in this sort of thing.
Chris - Thanks for your work on this and highlighting the potential cause. I have edited the records on the SB forum and the Dropbox site accordingly.
Based on the evidence of a dozen experiments, my recent supposition was not unreasonable and for the first month, my posts did not draw any conclusion, merely stated the results of different trials and questioned the driver and SGP in equal measure. I also posted full logs in December a few days after you requested them.
Thinking about this issue further, if it is a maths issue in SGP - then it would potentially occur with all ASCOM telescope drivers which report the same information, not just TSX. There are a few isolated posts on meridian failures with the SGP forum archive but most have independent fixes. It will be good to validate the root cause and move forward.
I don’t know if you have spotted this but it seems to be part of the trouble.
The return value will go to a large negative value if the ra is large and the lst is small. That’s exactly what I saw and reported a month ago.
I’d do something like this:
var ha = (lst - (ra * 15.0));
while (ha <= -180.0)
{
ha += 360.0;
}
while (ha > 180.0)
{
ha -= 360.0;
}
return ha;
This is assuming you want the ha to be in the range -179.999… to +180.0, if you need it to be in the range 0 to 359.999 then the tests need to be changed of course.
This conditioning needs to be done every time you do arithmetic on angular values.
Chris and Jared - now that we believe the object’s RA value affects the outcome, I repeated my original sequence from December, imaging C11, with 10 degree meridian flip point, 20 min exposures and the centering - with the original driver. C11 is at an RA of 23:20:45
It failed in exactly the same way (as occurred with the lastest TSX ASCOM driver) - after the meridian flip dialog, in which is asks to flip now or wait and before the centering dialog comes up, a warning message came up saying the mount was on the wrong side.
Time to flip had gone over and was reading 23:nn:nn. I have saved the SGP log (old driver does not produce a log) if you need it.
Nice one Chris
OK, so to summarize the operational results (as opposed to technical results) of this investigation would I be correct in saying?:
There is no operational difference between the two drivers in terms of the bug under discussion and it is just chance that this problem was noted first with the new driver. In other words, the problem will occur with either driver assuming the same set of somewhat unusual circumstances. This is because the driver itself is not the problem (and now fixed in beta 6).
Or do I have that wrong?
If the above is right, there would be no reason not to move to the new driver (especially if running beta 6 or later), correct?
Also a second set of questions regarding the new driver features:
I assume the “Can Get Pointing State” checkbox is essentially the same as “CanGetPierside” in ASCOM Profile Explorer but now has an explicit user level checkbox? Good Idea, BTW - It has been a source of confusion.
I noted that “Enable PulseGuide” is grayed out unless “Enable Tracking Offsets” is checked. I assume that is because PulseGuide basically is tracking offsets?
So essentially the checkboxes are modifying the ASCOM.SoftwareBisque.Telescope profile, right?
Finally, I noted you CAN check both “Enable Tracking Offsets” and “Use DirectGuide”. Am I correct that there would normally be no reason to check “Enable Tracking Offsets” when using Direct Guide?
@CCDMan - you are right on both counts - The fault was discovered using the new driver but equally applied to the prior level using the same range of RA values. The Beta 6 release of yesterday has put in a fix for the RA<>HA conversion, so we are good to go.
I have been using a MX mount and had tracking offsets and direct guide enabled without any issues. If you hover the mouse of the boxes, Chris has thoughtfully put in pop-up notes.
The note for tracking offset says ‘Enable tracking solar system objects if mount supports it. This is required for guiding except with SB mounts’. The help button on the bottom of the dialog gives more information.