HEQ5 - Experiments with belt drive

[Gina]

Lovely job Malcolm

Hope you're feeling better now Tony, if not, get well soon

[chrisshillito]

I've attached the last section of the log file (for the 20 min exposure) and hope that Chris can tell me if the PEC has improved over the previous trace ?

Hi Malcolm,

To do PE analysis you really need an unguided log not a guided one. Also you'll have to tell me the focal length, pixel size and declination being used for this log. That said, pulling your data into PECPrep shows peaks in all the expected places although the error signal from the 12 tooth pulley is far more significant than from that contributed by the worm/60 tooth pulley. Hard to draw any firm conclusions with guiding on though as it could just be that the PHD setup is better at correcting the longer period/slower moving signal.

Attached is the frequency spectrum for your data. The magenta markers indicate signals associated with the worm/60 tooth pulley. The green markers indicate signals associated with the 12 tooth pulley.

Chris.

[Gina]

I think it very likely that the 12 tooth pulley is slightly off-centre in view of the problem boring out the centre hole.

[chrisshillito]

Gina,

You may well be correct in that assessment. Of course the frequency domain isn't the whole picture and it may turn out that the overall magnitude of error signal in the time domain is actually be very small and that might explain why PHD was seemingly unable to correct it.

Chris.

[Freff]

Lovely job Malcolm

Hope you're feeling better now Tony, if not, get well soon

Thanks Gina.

[Freff]

I think it very likely that the 12 tooth pulley is slightly off-centre in view of the problem boring out the centre hole.

If Malcolm is now using the original ones that were bored off centre it could well be. The ones I done were true at 6000rpm so at the low mount speeds they should be Ok.

[malc-c]

Chris, thanks for the analysis - I assume that as it's an un-guided log that means it can be done with just the mount running any time of day. I'll try that sometime over the weekend and will post up the log files with details required.

I think you guys are right in that any oscillation caused by the 12t pulley being off centre could induce the errors.

[yesyes]

As far as I understood this, you still need a star. PHD won't guide on it but record the star's movement across the FoV.

[malc-c]

Cheers Chris... I also remember something about un-checking something in EQASCOM - will need to do some swatting up before I start logging

[chrisshillito]

Yes you need a star for PHD to follow. Calibrate a usual but check the "disable guide output" check box in PHD (or disable pulse guiding on the RA axis in EQASCOM). Ideally you want 50 minutes of data. If the mount drifts too far in dec to keep the star in frame you can use the EQASCOM slewpad/gampad to re-adjust - but only in DEC.

Chris.

[malc-c]

Hi Malcolm,

To do PE analysis you really need an unguided log not a guided one. Also you'll have to tell me the focal length, pixel size and declination being used for this log.

Chris.

Hi, Just managed to grab around an hours worth of data between the clouds. Chris, could you do your magic and let me know if the belt mod is performing as expected ??

Scope - 200P (1000mm focal length - f5)

Camera - QYH5 (pixel size 5.2um x 5.2um)

Target - Betelgeuse - DE:+07°24' 25.78"

Gut feeling is that the belt drive mod on the HEQ5 hasn't improved the overall performance. Would love to be proved wrong

Cheers

PHD_log_01Jan12.txt

[malc-c]

Well the graph shows a wave that is very repeatable - No idea though if this is good or bad

[malc-c]

just trolled through previous posts and located the old graph

[chrisshillito]

Gut feeling is that the belt drive mod on the HEQ5 hasn't improved the overall performance.

Mechanically it is seems much better to me!

The overall amplitude of signal may not have been significantly reduced but then that should be of no great surprise. This simply indicates that biggest contributor to the PE is one of the components that has remained unchanged by the belt mod - i.e the worm itself. However, peak to peak amplitude really isn't everything. The belt mod has produced a periodic error signal that appears much smoother (significantly less high frequency jitter) and that is repeatable form one worm period to the next. Also there is the additional bonus of reduced backlash

PEC (should you wish to apply it) will be able to do a much better job on this error signal. Even without PEC the relative simplicity and slow moving nature of the signal (essentially just a modulation of the 127s stepper pulley signal by the 638s worm signal) should be easily guided out.

Whether the improvements made will actually deliver you a measurable improvement in your final image quality I really can't say. For instance it is quite possible that autoguiding can tame even the most unpredictable of mounts given the right choice of guide parameters. However, I believe that having a mount that now behaves predictably must be of benefit when it comes to the process of discovering your optimal guiding parameters

Note that my PECPrep analysis (attached) is a little differnet from yours in that I have applied filters to remove signals with periods longer than the worm (hit the auto filter button and the adjust the magnitude filter until the main peaks are green). By doing this we can focus on the response of the components driving the RA axis and ignore contributions form the bearings supporting it (or other external effects).

[malc-c]

Chris, thanks for your analysis of the log files, and it's pleasing to hear that the modification has improved the mechanical performance of the mount. I'll swat up on how to now apply PEC to the mount now that the error signal is more easily corrected.

One thing that I have found is that goto accuracy seems to be way off (at least it was last night and I hadn't changed / moved the mount since the last time I used it). I did think that this might be due to belt slip, but tension is nice and tight. I have set the custom ratio up for 5:1 using the values stated in the EQ6 belt mod thread when I asked the question... could it be that these values need tweaking ? I'm not that bothered as the main goal of this mod was to reduce backlash and make the guiding more precise, but it can be embarrassing when demonstrating the set up and the scope fails to slew to within an acceptable degree of precision of the target (last night it wasn't even in the finder's filed of vision !).

[malc-c]

Chris, Been following a PDF tutorial to output a PEC file for use with EQASCOM and I'm lost. Could you attache the VS-PEC file produced by your filtered analysis ?

EDIT:

No worries, just re-read your post and hit the auto filter - Doh !

Quick question, in the pdf it mentions that provided the scope was parked after it makes no odds if the clutches had been released after... I've since reset the home position of the scope by getting EQMod to slew from the custom park position to the default home and then releasing the clutches to correctly position the scope. Also if I re-sync the encoders, will this have any issue if I now load the smoothed PEC file into EQASCOM ?

[chrisshillito]

Malcolm,

The custom mount setting settings for the HEQ5 Pro 5:1 ration are:

Worm steps 64x200x5 = 64000

Total Steps = 64000*135 = 8640000

Tracking offset -28

Make sure the "custom Mount enabled checkbox is checked before hitting the big OK button.

With regards to PEC it doesn't matter what you do the mount once it's parked. What causes loss of PEC synchronisation is power cycling the mount whilst unparked. Encoder resysnching is a means to recover synchronisation but you would have had to previously defined a resynch position (and be synched to that position) prior to starting your PE recording.

Please note that if using PHD logs for generating PEC files you do need to have created an EQMOD timestamp whist the mount was tracking during the PE recording (or after so long as tracking hadn't been stopped). The timestamp then must be "applied" when importing the PHD log into PECPrep. This is necessary because PHD data does not include any direct reference to the mounts worm position, just a time stamp for each record. By using the EQMOD timetamp PECPrep can assign motor positions to the PE data. If you have a webcam I personally would recommend Perecorder in preference to PHD as perecorder is able to log motor position directly within its logs (because it was written specifically for EQASCOM).

Chris.

[malc-c]

Chris, thanks once again for your help and guidance. I'll download PECorder and run through another round of data gathering next session. As far as the custom settings are concerned, yes the data I entered is the same as you've just stated, and it's check box was enabled. I'll take the covers off the mount and re-check the tension of the belts just in case.

[malc-c]

OK, came out from work and was greeted by stunning view of Venus, Jupiter and the Moon... got home and had a meal before venturing out to try and gather some more data..

First thing that went wrong, for some reason when slewing I had a similar issue as I had a few weeks ago where the target was selected and the scope pointed to the floor ! - re-checked everything only to find that CdC had somehow picked a system date of August of 2021 !! Corrected this and then slewed to 1st target - goto was way off. Then as I stood by the mount I noticed a slight, but rythemic clunking...

Opened the cover and noticed the belt on the DEC drive was low on the large pulley, and that the DEC motor pulley had slipped lower than I had originally placed it. However the clunking came from the RA, so I backed off the grubscrew that adjusts the worm meshing by 1/8th a turn and that removed the clunking. I then proceeded to remove the DEC motor buy a mixure of torchlight and moonlight, and then reposition the 12t pulley. Then Tony's worse fears were realised, the hub and pulley parted company !!!!

I then located the last pulley I had spare - one of the originals and placed that on the shaft. I spent a further hour sorting the alignment out and then had it running sweetly with just enough tension on the belt. I then slewed the mount round 180 degrees on both axis before placing the mount back in the home position. Now for the good news...

Selected Aldebaran as the 1st target, the goto was off. I released the clutches and manually placed the star in the centre of the eyepiece, and locked the clutches again before syncing in CdC. Then proceeded to select around half a dozen stars from Deneb to Dubhe and each one was spot on - Selected M31 and bingo bang in the middle of the eyepiece !!

Right now to try the PERECorrder program to see if I can get some data for PEC... the software won't detect the QHY5 Not only that but the wind has now gusting and the scope was being blown even in the confinds of the observatory, so I'm goinng to call it quits for tonight and go in. It will be interesting to see if the goto accuracy is repeated next session... stay tuned.

[Freff]

Sorry to hear about your mishap Malcolm. I was afraid the that the 12T pulley was not up to the job being a three part component.

I'm sure a simple 12T cog can be sourced and then drill for a grub screw.

[malc-c]

Tony, you were spot on regarding the amount of material left on the 12T pulley (see attached)

I was about to give up on this project and replace the pulleys with the original gears, but thought as i has a spare pulley I'll carry on... so far so good. What might be a better option should any of the remaining 12t pulleys fail is to opt for a 15t pulley and set the mount to 4:1 ratio. The fact that there is no flat on the motor shaft means there is more chances of the pulley slipping round the shaft, or up and down on the shaft. I don't want to file a flat on the motor shaft as I may end up having to go back to the gearing. My other concerns with regards to the belt mods (EQ6 and HEQ5) is the stress the belt tension may have on the motor shaft / bearings ?

[chrisshillito]

Right now to try the PERECorrder program to see if I can get some data for PEC... the software won't detect the QHY5 Not only that but the wind has now gusting and the scope was being blown even in the confinds of the observatory, so I'm goinng to call it quits for tonight and go in. It will be interesting to see if the goto accuracy is repeated next session... stay tuned.

Sorry if I've lead you up the garden path but perecorder only works with webcams - (I did mention you needed a webcam in my last post). If you don't have a webcam then PHD is the next best thing but you just have to do the "eqascom timestamp" trick. Note that you don't need perfect conditions for PE recording - wind, bad seeing etc. can all be filtered out using PECPreps fft filters (mind you if the star is being blown off image that might upset things!). I usually record mine at dust when there's little else to do.

Bad luck with the 12 tooth gear - I followed Francis' advice and epoxyed mine in place.

Chris.

[malc-c]

Chris, I do have a web cam, but as I use the ST80 for guiding thought that I should be using that and the QHY5. If I use a webcam it would have to be through the main scope. Would that cause any issues when it comes to recording the data ?

Epoxy may be the answer... and I may end up going down that road, especially if the goto accuracy keeps up - best goto performance I've had since getting the mount

[Freff]

Malcolm it would be very easy to put a flat on the motor shaft. A two min job with a Dremel. If you don't have a Dremel a 1/4" file will do it.

[chrisshillito]

Malcolm,

There is no problem at all in using your main scope for PE recording/analysis. We're not guiding here, only measuring the mounts movement so the more resolution you can get the better (so long as the unguided star keeps in frame over the entire capture process). Also use the shortest exposures you can - PECPrep likes lots of data - the more it has the better the analysis!

Chris.