New TheSkyX ASCOM driver

Sequence Generator
41

Chris I did give you both logs back in December - if you scroll up, you can see that you extracted and quoted them in your post (27). Since then SGP released their Beta versions and I deleted the dropbox entries. I had a clear out and I no longer have them. Sorry for that.

No big deal however, I’ll repeat the procedure and reproduce another set of log files.

The file in the dropbox now is with the old driver and a beta SGP version (hence the GNS). When there was insufficient time for the next exposure, a dialog box came up asking if I wanted to wait or flip now. I told it to flip. It was a few minutes ahead of the planned flip point - which may explain the maths question.

Friday weather is looking promising. I just need a few hours to repeat the trial with different settings.

42

Yup, that’s exactly it! The automatic meridian flip was converted to a “forced flip” and the message about needing the flip was output erroneously.

Thanks
Jared

43

I owe you an apology Jared, I had no idea that Chris Woodhouse had made a manual flip. He didn’t mention it. None the less we do need some answers from you.

As he says, post 27 is the best evidence we have. I have tried to merge the two logs, the SGP and driver logs, and can see no reason why the meridian flip should fail. The data I report is correct.

Unfortunately the original files seem to have been lost. It’s been nearly a month now.

I wonder if there’s some circle rounding error to do with the hour angle, sidereal time or right ascension that only occurs at one time or time of year. That’s why I mentioned the point of the hour angle being reported as -349 degrees.

Chris

44

Once Chris is able to get a new set of logs I can take a look. We should be reporting what failed and if I can’t find it then I’ll add some additional logging in the next beta.

Thanks
Jared

45

Logs using the new TheSky driver when a meridian flip works will also be useful because it will give a useful reference to compare a log when the flip fails.

To reiterate, I need:

  • The DRIVER log (check the trace checkbox in the driver setup; read
    the driver help for the location of the log file).
  • The SGP log for the same period.
  • A description of the setup, the mount type and how it’s connected to
    TheSky at least.
  • The time that the flip was done (or not) will be useful.

Be generous with information. I can ignore too much but if there isn’t enough I’m still stuck.
Don’t assume that someone else to do this.

Chris

46

No problem. I’ll get this to you asap. It is all set up, waiting for clear skies.

I will also make a screen capture video during the setup and commencement of the sequence, showing the different settings for the driver, meridian flip and TSX. I’ll then pause it and start it up again just prior to when the flip should occur. The PC time on the screen will link nicely to the log files.

I will also connect directly to your driver, rather than through Generic Hub. (You may recall that Dan from Software Bisque suggested to go through the Generic Hub in his post on the SB forum. I have tried it both ways before and it makes no difference to the outcome.)

47

Chris (buzz),
You can try restoring your previous logs from Dropbox.
https://www.dropbox.com/en/help/296

This has saved me more than once :slight_smile:

Thanks,
Jared

48

Nice one Jared - I have restored the original December logs for the driver and SGP. Rather than ask Chris to wade through it, I’ll write a RTF to help navigate the filenames and times of events. I’m wiped out for today. I’ll do it tomorrow and upload into the same dropbox.

I’ll still repeat the experiment with Beta 3 as promised.

BTW - when I started this hobby - I told my daughter that my pictures were of galaxies lightyears away. Hence the pseudonym Buzz.

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