Tracking Issue

[malc-c]

I've just rebuilt the Observatory PC and as part of that build downloaded and installed CdC ver 3.10 and EQMod 128f. 

Last night I found that whilst the mount would slew to a target, the target would drift in RA even though tracking was enabled.  EQmod would show RA advancing rather than being static.

I shut the PC down and tried again today.  I chose the sun as the target, the mount would slew to position, and then the RA would slowly advance.  When zoomed in in CdC the telescope recticle would also drift rather than remain on target.  Not knowing if CdC or EqMOD is responsible for issueing the commands to the mount I chose CdC to be the first application to replace.  The current version was un-installed and a really old (3.4, circa 2011) version that had been previously used installed.  Once the same long / lat details etc were entered I again repeated the above.  This time the reticle remained on the Sun, RA was fixed and the scope tracked as it should.

Has anyone else experienced similar issues with recent versions of CdC ?

[chrisshillito]

Hi Malcolm,

I just downloaded CDC V3.10 and it is working fine for me, with the EQMOD simulator at least . I opened up the EQMOD ASCOM trace window and I can't see CDC doing anything out of the ordinary  - it just checks that racking is enabled prior to the slew, if it isn't it starts it, It then checks that EQMOD can slew asynchronously and then performs the slew. There is no setting of the tracking rate itself, it just commands EQMOD to start tracking.

So you have me puzzled!

Chris.

[malc-c]

Hi Chris,

I'm puzzled too.  If the issue had only occured on Tuesday evening then I would of said it was "one of those things" that PCs do from time to time, but as it occured again after the PC hd been turned off over night some for of communications were breaking down.  At the time on Tuesday evening, selecting the tracking option (solar, luna, siderial) in EQmod made no difference either.  I assume that CdC basically sends the instruction to go to the RA/Dec co-ordinates and issues the tracking mode instruction to EQMOD, which "translates" this into data the mount can understand, and once issued the mount performs the slew and starts tracking?  In my case the tracking instruction was either not sent by CdC, or ignored by EQmod or the mount... The fact that the mount responded to slew commands would suggest that communications between the PC and mount were fine, so somthing in the tracking commands / protocol was "incompatible" and being ignored or not sent as mentioned.  I also assume that as the scope reticle in CdC would move off target, and the RA was constantly changing, CdC was either thinking that Tracking had not being enabled, or the data from the encoders in the mount were being relayed through EQmod and the scopes position updated - maybe this means more to you as you have a better understanding on how the process works than I.

Don't know if it matters, but I downloaded and installed the latest version of ASCOM prior to installing EQMod and Cdc.  Not sure if the order of installation matters, but obviously having un-installed 3.10 and then installed 3.4, CdC was the last application installed with EQmod and Ascom already installed and registered.. (clutching at straws here !)

Anyway, it all appears to work now, and just need to have a break in the clouds (day or night !) to see how well it tracks a target.

[chrisshillito]

The only reason CDC checks the tracking and, if needed starts it,  prior to the goto is that ASCOM strongly recommend that drivers should reject a RA/DEC slew out of hand if tracking isn't active. EQMOD ignores that particular dictate so slews are always implemented and tracking is always started automatically on slew completion.

So If you had EQMOD tracking prior to the goto then CDC would only check the tracking status and wouldn't actually start it, and irrespective of whether CDC started the tracking or not EQMOD would start it on slew completion. So I'm still puzzled!

Chris.

[malc-c]

Chris,  I'm confused even more now.

The clouds cleared so I had a target (al be it a big one) which I could now track

The Goto was way off, but I think that was down to CdC still thinking it was on EU time zone rather than BST.. I resolved this by manually setting the time to use GMT+1 and now the slew to teh Sun was more or less where it should be, and not pointing wayward at some point in the ground !

However,I was still having tracking issues after I removed the old version and went back to 128f.  So rebooted everything, but this time just opened EQascom, set it to normal park, set the mount to reflect this so it knew the starting point, and then using the NSEW buttons moved the mount off park. and engaged siderial tracking... the RA did not remain fixed, and the arcsec was counting up.

I've reverted back to v1.24g and tried the same experiment - RA was locked solid

I parked the scope, launched CdC ver 3.4.1 and instructed a slew to the sun - away it went and locked on target.  The RA info remaind solid and tracking was running.  I opened up the camera software and after a bit of a correction with the gampad had the sun in the FOV.  Tracking in EQMod was set to Solar and the sun remained on screen for fifteen minutes.

This is so strange...... but at least now I'm at a point where I have the slewing and tracking working, and can now fine tune the polar alignment using PHD2, well assuming I don't get any further issues !

[Earl]

the dift align does the job well, my last subs were 30 mins with no problems.

I have to redoo it all once my dome is serviced. as during the process im sure it will get knocked.

[chrisshillito]

Other than the fact that its display won't match you actual sky It shouldn't really matter what time zone or indeed location CDC is set up with - ASCOM goto commands are sent using RA/DEC coords which of course don't change with location or time. So long as you PC time is correct EQMOD should slew to the right place (assuming its starting from an accurate home position).

With regard to the tracking problem -  do you have PEC engaged? - something messed up with PEC could cause the RA to move.

Chris.

[malc-c]

Hi Chris,

Unless PEC is enabled by default in both installations, then no it hasn't been engaged.  I've successfully repeatedly shut down and restarted the PC and slewed and tracked the sun, so fingers crossed the gremlins have gone and I can continue with the set up and hopefully start using the scope again.

Thanks for your input.  Guess we'll never get to the bottom of this.  I'm not that fussed about using old software, so long as it slews to target, tracks and syncs that's all that matters to me

[malc-c]

Well I rebooted the PC and did some more testing as the big target was visible in the sky (sunny for two days now... must be summer !)

No repeat of the tracking issue.  I could engage tracking having moved the scope to any part of the sky and the RA / DEC co-ordinates remained static.  So onwards to resolve a further issue with CdC not accepting the system time, and thinking that the long / lat co-ordinates were in eastern europe ! which might of been why the slews were so far off !

Having downloaded the country datafile from the net I selected my home town and it populated the long / lat with co-ordinates that were close to those from the GPS dongle.  I corrected these to match the GPS data and updated the settings - Bingo it changed the time zone to London, and BST - I checked the time zone settings and with the "use system settings" enabled it matched the clock on te PC which matched local time.  I checked EQmod and confirmed the same long lat data was present, and that the enable custom mounts was checked and set to 4:1 to match the belt drive ratio.

So then to check the physical scope setings, and having set the AZ to 180 degrees in EQMod I used a spirit level on the weight bar to confirm it was horizontal.  I then set the ALt to zero degrees and checked the dovetail was level - parked the scope in the default home position, and it was spot on.  Polar alignment had been done a week or so ago using the built in PA tool in EQmod, and the scope hasn't been knocked since.

I then selected the Sun and CdC instructed the slew... the scope stopped out of position, approx 10mm in the E/W cross-hair on the starsharp solar finderscope.  I then used the gamepad to find the sun and centre it in the scope using the QHY5 camera and QDvideo software.  Selected solar tracking and the sun remained fixed.

I've attached an screen dump showing the position the scope was in when tracking the sun, in relation to the chart - which is around 2 degrees off... anyone have any suggestions as to why the goto, and then the resulting true solar position was so far off from the chart, given that all the date / time and location information is correct and synced between the two applications.

[malc-c]

Uhmmm...

I powered the PC up again and went into CdC's time settings, turned off the "use system time", and reduced the hour by one to reflect GMT - selected the sun as the targe, and this time when it slewed the sun almost hit the centre circle in the solar finder, and much more indicative of a PA error, or flex as the scope was no on the east side pointing West rather than West pointing East as it was earlier...

So it seems that CdC wasn't taking BST into account....The question is, why !

To be honest I'm not that bothered... if now have a set up which comes within a few arcminutes off the target after a slew I can live with that.  I'm hoping that after some drift alignment with PHD2, any small PA error may be removed and that will tighten up the goto's in the future.

I would also like to compare the accuracy of the GPS dongle in some way, as this too may be the cause if it's not that precise - garbage in / garbage out so to speak !

EDIT - I was wrong.  Whilst tthe goto was closer, the final position between where CDC thinks the sun is and where the scope is pointing when the sun is in the FOV of the scope is still out by the same amount.  Interestingly, in the about option the position given for the sun is different to that where the EQMod is saying the sun is once it's locked in and tracking

[malc-c]

Well it's not CDC -

I installed C2A and ran through the same tests, and it was out by the same amount.  The only conclusion I have is that the PA alignment went wrong and I've somehow got the PA off axis. 

Maybe I placed polaris on the 3 O'Clock position  when it shoud be on the 9 O'Clock position which would place the NCP 2 degree off ?

[Earl]

Malc to be honest run the PA routine in PHD2 so you know thats sorted first before worrying about this, you need to be at square one.

I also just use plate solving for syncs and centering no point modeling or worring if apps are confused at what they are looking at, a solve and sync tells it exaclty what it is looking at.

[malc-c]

Earl,

I have to agree.  If I get the PA sorted, and then get issues it would then rule out PA as being the cause.

[malc-c]

Guys,

I've taken advantage of the recent clear nights and have used PHD2 to do some polar alignment.  Setting the scope to the intersection of zero degree and the miridian wasn't a problem, and after several runs managed to get a flat trend line with zero error, but I don't have a clear E / W horizon, so pointed the scope East and go as low as I could, but the scope wasn't in a perfect T with the weights down due to the observatory roof.  Adjusting the altitude bolts to get a flat trace as very sensitve, but I managed to get a trace were the error was down to 0':20" to 0':48" over the run.

I parked the scope in the default home position, un-parked and reset the encoders - Slewed to Vega, and it was right down in the FOV of the camera.  When centred the result was RA of 18h 40min 9sec, DEC +38d 25m 50s  which compared to the position cds has in the about window (RA 18h37m28s and DEC +38d48m17s).   So around three and a half minutes in RA and 23min DEC error !  - Would you (Chris) say that this is within tollorance for a goto, or still too far off and further investigation is needed.  Once centred I synced the position and then went on to do the same with a host of other targets, all of which required centreing, but were all in the FOV of the 400D camera, so I do have a workable platform

[malc-c]

I've not bean able to use the scope since doing a drift alignment and syncing on a few targets as detailed above, however I installed the SkytechX software to give it a try and see how well int interfaces with Ascom and EQMOD.

Whilst I couldn't physically see jupiter, I used it as a target, and found that with the same long lat data as EQmod, the resulting slew was off target.  I then did subsequent parks and slews and got differening results each time.

Original park position given in EQmod: RA  23:18:13  & DEC +35:07:27

First slew to target - Slew complete      RA 10:16:42  & DEC +11:40:52

Reparked - RA 23:20:51  & DEC +35:07:27

Second Slew to target - Slew complete  RA 10:16:12  & DEC +11:44:41

The positional data in the planetarium software for Jupiter is 10:14:38 and DEC +11:48:54

I'm really confused...

• Where does EQmod get the data from for the RA and DEC that is displayed in the EQmod application, as far as I know, the HEQ5 doesn't have physical encoders, so how does it know it's position
• What actually controls the mount... and where would the descrepency creep in.
• Why would there be such a variation between slews and parks.

Just to cover, that originally after polar alignment the encoders were reset and all sync points were cleared before I did the initial goto, correct and sync session mentioned above. 

I've now tried three planetarium applications and had the same issues with over shooting the target, both on the charts and in real terms.  The mount has a 4:1 belt drive, and this custom mount has been enabled in EQMOD, but if this was simply a wrong ratio issue then ethe gotos would be miles off target, so it's not that.  The clutches are tight, really tight so I's not slip, and the mount / scope  has been ballanced.

This is really beginning to get to me, so much so that I am losing interest in astronomy and thinking of selling up...

[malc-c]

Ok, just to add a little more confusion into the mix:

On my main PC (fresh build of windows 7 two days ago), I installed the latest version of ASCOM and EQMOD.  I set the toolbox option up to use teh EQAScom Simulator, with a custome 4:1 settings for the HEQ5 custom mount option.  I entered the same long / lat into EQMOD that the SkytechX has so both were singing from the same hymn sheet.  I launched SkyTech and connected to the telscope - EQmod(sim) opened - selected Jupiter as the target and slew.

Skytech gave me the RA and DEC for Jupiter as  RA 10h:14m:40.2s with a DEC of +11d:48m:43s

The co-ordinates in EQmod(sim) was   RA:10h:15m:30s and DEC of +11d:44m:04s

Why... there is no real scope to send back any encoder info... surley the same data should be displayed by both applications ?

[malc-c]

Maybe getting somewhere... I did a test with CDC and noticed that in the about window it listed three sets of co-ordinates. Apparent position, mean of date, and mean J2000.  The closest match out of these three to the ones sisplayed in EQMod was the mean by date.

Closing CdC down and opeing up SkyTech, and repeating the slew the result was way off, and no where near the J2000 co-ordinates shown in the about window. - hopefully I can attatch a pdf i made which might help explain things ?

EQmod issue.pdf

[Earl]

have you guided a sub ignoring sync info?

[Earl]

id also use plate solves to sync too,

[malc-c]

Earl,  that makes no sence to me whatsowever.   The issue also occures when using the simulator - so it's not down to a mis alignment or slipping clutches / motors etc...  If the software is not correctly positioning the mount there is no reall point in doing any detailed polar alignment.

[Earl]

with my em i just used PHd2 to drift, never once used a model, slewed to my target did a plate solve and the centered on what i wanted, i never bothered looking at any numbers poitn models they serve no use.

[Earl]

I usd this approach for a HEQ5 and NEQ6 also, focus on PA ignore everything else, Subs are the judge of good PA for which i used 30 min subs, and with PHD2 also with bad horizons (it makes very little differnce i found) I could not physically adjust the equipment any finer without modification.

[chrisshillito]

Whilst I couldn't physically see jupiter, I used it as a target, and found that with the same long lat data as EQmod, the resulting slew was off target.  I then did subsequent parks and slews and got differening results each time.

Where does EQmod get the data from for the RA and DEC that is displayed in the EQmod application, as far as I know, the HEQ5 doesn't have physical encoders, so how does it know it's position

• What actually controls the mount... and where would the descrepency creep in.
• Why would there be such a variation between slews and parks.

If you can't physically see jupiter then you don't really know if EQMOD was off target with its slew. If in real life you slewed to an object, found it centered in the eyepiece but not centered in the planetarium would you care that much? All you'd have to do is hit a sync and all would be back in step.

EQMOD calculates the current RA/DEC coordinates by looking at the motor encoder positions, the current time and your site location. In addition if there is any pointing model active (alignment points or an active sync offset) then this will also be taken into account.

When EQMOD is commanded to slew it does the same but in reverse - i.e. works out what motor positions are required to move to the specified RA/DEC coords taking into account the  location, time and pointing model. Of course moving the motors to the calculated position will take time - and in that time RA will have shifted so once the motors reach their target another goto is issued to the same coordinates (and again adjusted by the model) and this iterative process continues for up to 5 iterations and until the calculated stepper position and actual position are within a set number of microsteps at which point "near enough" is considered "good enough"

For Parks movement is absolute - i.e. the mount is commanded to got to a fixed encoder position, Time, Site and pointing model have no effect on a park move and to be honest it makes no sense to ever the RA/DEC value of a park position.

When it comes to EPOCH you need to make sure that all the software you are using is setup to use the same EPOCH. So if your alignment points were synched using J2000 coordinates then you need to be using J2000 coordinates when you issue subsequent gotos  and EQMOD's is going to be reporting RA/DEC values that are effectively J2000 (compensated for pointing adjustments). EQMOD does have a setting in its setup where you can set what EPOCH you want EQMOD to report to other clients . Note that this doesn't mean that EQMOD will precess the coordinates  - simply that if any client cares to asks what EPOCH it should use then EQMOD can tell it (so for smart clients this is a way to force a common EPOCH to be used - unfortunately most clients aren't that smart and you have to set them up manually). If you have any doubts as to what coordinate system your planetarium is using when commanding gotos / syncs then use the EQMOD ASCOM trace feature to watch what data is being passed in the associated messages.

When it comes to the EQMOD simulator I can't say for sure how it runs with custom mount settings - its purpose is only really to allow folks get familiar with the EQMOD controls and I know that it was originally written only as a EQ6 Pro simulator and I would caution drawing any conclusions when comparing its behavior with a real "non EQ6" mount.

Chris.

[malc-c]

Chris,   Been doing some further test, this time using the scope.

1. Launched Skytechx, connected to the mount, selected the sun as the target, slewed.  Slew was complete with an RA of 10:1:47 and a DEC of +12:04:01 displayed in EQmod.  Took a photo and the sun was right on the edge of the image.  Moved the mount with the NSEW buttons until the Sun was centred in the image.  The result displayed on EQMOD was RA 10:05:17 and DEC +11:47:50.  Parked the scope and closed down Skytech and EQMod
2. Launched CdC, conneted the scope, selected the Sun and slewed.  Slew was complete with an RA of 10:1:47 and a DEC of +12:04:01 displayed in EQmod.  Took a photo and the sun was out of the field of view.   Moved the mount with the NSEW buttons until EQmod read RA 10:05:05 and DEC +11:48:22.  Took an image and the Sun was very close to centre.  Parked the scope, changed the settings in CdC to use mean by date.  Slewed to the Sun, and EQmod displayed RA 10:01:47 and DEC +12:04:01.  The resulting image had the sun out of view.  Moved to 10:05::05 and +11:48:22 and the Sun was centred.  Parked the scope.
3. Repeated #2 but selecting different options in CdC for co-ordinates. - Confirming it was also set to EQ - still the same results.  CdC and EQMod was closed between each try.
4. Finally repeated #2 and this time synced.  Parked the scope closed CdC and then re-opened.  Slewed back to the Sun and took a shot - Sun was not in the image - checked the sync point window and it hadn't saved the correction.  In fact it hadn't saved any of the last session sync points ! - At this point I parked up and powered the PC and hit the drinks cabinet !!

Can you advise me where the EPOCH settings are in EQMod so I can try and make sure that both CdC and EQMod are singing from the same hymn sheet.  As to why the sync points are not saving I have no idea.  I do have an old hard drive and might try swapping them out and rebuilding the observatory with XP which is less fixated on security as I'm guessing that this is the issue behind saving data !

[malc-c]

Could this issue be down to PA ? - even though I use the EQMOD PA tool as a base, and then PHD2 drift alignment ?

This may mean more to you - but gives he offset in #4 above