New TheSkyX ASCOM driver

Sequence Generator
49

I have already waded through these logs. My analysis is in post 27 of this thread, about a month ago.

The two logs are quite consistent and you can see how the values will follow from the TSX log to the SGP log.

It’s my opinion that there’s a bug in SGP when the Ra and LST values are close to 24h/0h. Maybe there is a sync being sent with an invalid Ra. One that’s less than 0 or greater than 24. The driver will, correctly, raise an error at that point.

Jared, I think this is now up to you. I have done all I can to help with the data available to me.

Chris

50

Well, what I can tell you by those logs is that the meridian flip failed extremely early. SGP didn’t even fire up the thread to invoke the flip so it’s not surprising that there is nothing in the ASCOM logs.

Do you happen to recall if a dialog popped up stating that the flip had failed? It would have been different from the one stating that the sequence had aborted.

There is certainly something wrong with how the degrees past the meridian is being calculated for RAs very close to 24. I’ll address that. Even still I don’t believe this is what’s causing the flip to fail. I just don’t see any indication of that.

I would be interested to see if this prevails at other RAs and if it’s completely repeatable. Can you manually invoke a flip? Does that work?

Thanks,
Jared

51

Thanks Jared,

If it’s failing that early would tests that didn’t involve solve and sync be useful? It will be a lot easier to get information if it can be done without acquiring an image and plate solving it.

Chris W will need to answer the questions about dialogs.

52

The video capture will show the dialog boxes as they come up. The original issue was occurring at 10 degrees past the meridian - that surely cannot be a rounding error? To quote my earlier observations:

So - there is a successful outcome when centering is disabled

Jared and Chris - I’m still predicted to have a clear night tomorrow - what do you want me to try with the Paramount?

53

I don’t think it’s a rounding problem, more that angles are circular. If you subtract 350 degrees from 10 degrees the simple answer is -340 but actually the answer is +20 degrees because the angles wrap round at 0/360 degrees. It’s very easy to slip up with this sort of thing.

Jared will need to reply about what tests will be useful. He said that the flip thead hasn’t started and I think this means there was no image - solve - sync activity. There were 35 seconds with no logging before the fail message. Could this be waiting for Chris to acknowledge a message box?

The successful flip shows this:
TSX Log data:
20:15:42.334 m_SkyTele.GetRaDec Ra 1.12902888131002, Dec 61.6230638886533
20:15:42.334 RightAscension Get - 1.12902888131002
20:15:42.334 Declination Get - 61.6230638886533
20:15:42.336 Altitude get - 78.6189953384598
20:15:42.337 Azimuth Get - 335.169228427915
20:15:42.350 SiderealTime Get - 1.79845307667288
20:15:42.364 Get - pierWest, sop 1
20:15:42.365 Connected Get - True
20:15:42.366 CanSlew Get - True
20:15:42.366 SlewToCoordinates set - 1.12902888131002, 61.6230638886533
20:15:42.366 SlewToTarget set - 1.12902888131002, 61.6230638886533
That’s started the slew.

The SGP log data:
[13/12/2014 20:15:42] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 10.0204350095643 >= 10
[13/12/2014 20:15:42] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] Meridian Flip: Skipping Solve and Sync
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] Meridian Flip: Stopping the Auto Guider
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] PHD Advanced: Stop
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] PHDA: Sent command (PHD_STOP)…
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] PHDA: Received (0)…
[13/12/2014 20:15:42] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[13/12/2014 20:15:42] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[13/12/2014 20:15:42] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using slew
[13/12/2014 20:15:42] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 1.12902888131002 Dec: 61.6230638886533

The obvious difference is that the Ra and the LST are both small positive numbers that give an hour angle of +10.02 degrees rather than an hour angle of -349 degrees.

Also the solve and sync skipped message is sent by the pier flip thread so it looks as if solve and sync had not been started in the first failure.

The impression I get is that the first flip would have failed regardless of solve and sync being active and it would have failed with the old driver.

Chris

54

While we’re waiting for further clarification on this issue and really just so I can understand better what is going on:

My understanding and please correct me If I’m wrong, is that once the Paramount crosses the meridian and a slew command is given, the mount will automatically perform a flip and slew to the target. If that is the case, why is it not a simple matter of giving that command and performing a plate solve after the flip? This was brought up with similar issues with SGP controlling a flip with a Celestron mount and it was mentioned that SGP has to know where it is before the flip so it knows where it’s going but I still don’t no why. Doesn’t the mount itself control that? Even with my Celstron mount if I issue a slew to a target after it crosses the meridian, it will automatically flip and find the target. Please help me understand why it’s not just a matter issuing a slew command to get what were looking for here.

55

Where can this be found? Or is this something you’re planning on doing this evening?

I guess just what you’ve been doing to make it fail. Also it would be nice to see if you can try to get the flip to occur when the sidereal time is near 0 and the RA is near 24h. I’m not completely convinced this is the issue…I think this may be a red herring, but it’s certainly odd.

Martyk22, I’ve created a new topic from your post. You can find it here:

Thanks,
Jared

56

Jared - I have not made the video yet. Late Friday night sill looks promising. I’ll do the following settings:

PHD2 2.4.1c / Beta 3 2.4 SGP
Notifications (GNS) turned off to reduce log traffic
Safety monitor (Boltwood) turned off to reduce log traffic
Meridian flip on, set to 2 degrees (By the way, the Paramount limit in TheSkyX is set to 1.5 hours)
Meridian centering turned on (essential as I do not use T-Point in my mobile setup)
Logs turned on for PHD2, SGP and TSXAscom
Video turned on, Also sprach Zarathustra set as background music

Load Sequence
Check TSXAscom driver uses the Paramount direct guide settings for my MX
Auto slew/center on sequence start enabled
Focus adjust on filter change enabled and autofocus on sequence start or 1C change enabled.
Once the equipment is connected in the sequencer I’ll use the filter tab to select a filter (currently, if I do not do this, the focuser is not moved to the absolute focus position for that filter but does correctly make the relative moves on a subsequent filter change - if you have an OAG, as I do, that also means that the guider calibration at the start of sequence , and before any autofocus kicks in, can go awry as it is out of focus.)

I normally use PHD2, with dither, but at present I’m still uncertain if it is automatically firing up correctly on a timed sequence start, so I’ll calibrate the guider before starting the sequence.

After all that, it had better go wrong… :blush:

1 Like
57

I think it will be fine.

The same circumstances as your failed pier flip comes at around 16:15 on Friday - in daylight. It’s probably going to be August before it’s dark at the relevant LST.

Chris

58

Quick question: Is all this testing being done with 2.4 and are you using the SBIG API?

I am leery about moving to 2.4 on my main system and have had problems with the API/PhD recently
so that would complicate diagnosis in any case.

I did install all the most current everything (TSX, SGP 2.4 Beta, 1.3 API, current build PhD 2) just today on my laptop so may be able to try this out w/o messing with my main desktop (once I fix a hardware issue with my mount- hopefully today).

I did renew my TSX subscription (arrgh, expensive!) today so I assume the latest version of the TSX driver is the one on the SB website?

59

I’m using the current 2.4 and things seem to have changed but not improved.

I tried the experiment I described - Use M52 and start about 16:00 I was a bit late and m52 had passed the meridian so I had to do a slew to something on the east and then use the HC to move past the meridian. I left the time to flip (TTF) at about 20 minutes.

This is what happened:
This was about 16:10:06
After a few minutes noticed that the TTF was now 23:59:00
This was about 16:20:16

The TTF continued to reduce but no flip was done, even though the hour angle indicated that the mount was well past the flip limit.

Left the sequence to complete and saw no flip
17:06 sequence finished.

Did a slew to Navi, just east of the Meridian, and started another sequence

Set up Sequence 12 * 5m frames
17:12 Start sequence
17:12 Time to flip 00:45:00
17:13 Increase number of frames to 14
17:18 TTF 00:38:40
17:22 TTF 00:34:30
17:27 TTF 00:29:45
17:46 TTF 00:10:27
17:56 TTF 00:00:38
17:57 TTF -00:00:10
17:57 Flipping
17:58 Finished
17:59 new frame started
17:59 TTF NA
18:00 reduce frames to 10
18:04 finished, close down.

The log files look similar to what Chris W posted a month ago except that the hour angle of -349 degrees or less does NOT trigger a flip.

I started a new sequence for another object and that behaved as expected. The TTF counted down, went to a small negative value and the flip was done.

I’m running with an AVX mount, running StarSense, connected to TSX using the ASCOM driver then using the TSX ASCOM driver. I don’t think that using a Paramount would make any difference.

It looks as if there’s some bug in SGP that affects flipping but it only happens when an object with a Ra of around 23.5 has crossed the meridian. It’s an edge case, I’m not sure how big it is, maybe with 10 degrees past the meridian it will be about 40 minutes.

I have log files but don’t have a dropbox account. If the old Yahoo group is still extant I could post them there, otherwise let me know how to get them to you. The zip file is about 170 kb in size.

Chris R

60

dropbox account is free and very easy to use.

Peter

61

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.

62

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.

Thanks,
Jared

63

Folks - the meridian flip worked- log files from ASCOM driver, SGP and screen capture video are uploaded to dropbox:

meridian flip jan16 - video capture
ASCOM.SoftwareBisque.1922.013130 - driver log file
sg_logfile_20150116191926 - sgp log file

Meridian flip just after 22:01 - object has RA of 5:41

Hope that helps diagnose the issue. This is consistent with Chris’ idea.

64

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).

65

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,
Jared

66

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.

67

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.

Chris

68

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