Help: HEQ5 pro guiding gremlins frequent 12 arc second spikes

[dizzy2003]

I have a heq5 pro mount (with rowan belt mod) and have all but given up on astrophotography because of this guiding issue. Scope is a 100mm Apo. asi cameras (asi 533 and 120mm for guiding) using eqmod pc to mount (and also asi air plus).

Essentially I have these random spikes that show up on the guiding graph that result in a double image of stars a few star widths apart. They happen frequent enough that shooting at over 30 second exposures results in half the shots being ruined :(

PHD2 guidelog image attached. (note the final part of the image I changed dec aggressivenes to 5% hence why that correction takes so long)

So things of interest, spikes are on RA and Dec! mostly RA though
Spikes are both above and under the graph (so tracking can be ahead and behind). Between spikes guiding is quite good.

(errors on Dec and RA on either side is what really confuses me)

Errors are fairly consistent in size 12.5 arc seconds. (Note <for scale> if I tap the guide cam with my finger nail I get a 4 arc second spike.)

Its possible this started after a night of the telescope mount being stuck grinding the telescope against the mount.

Things I've mostly ruled out.
Power supply, tried 3.
USB cables, tried 2 (no hub in use)
Computer, tried PC and ASI Air plus
Wind/wires/wobbly random bits.
I've opened it up and cleaned/regreased
I've tried east heavy/west heavy
I've tried minimise backlash, I've tried loosening effectively adding backlash.
I tried switching the RA and dec motors
I can hand turn the pullies freely through full 360 on RA and dec without binding or overly heavy resistance
Slewing is fine
Balance is good.
Calibration is good.

I'm kinda thinking main pcb issue bit I dont know.. and its an expensive guess.

[sunslayr]

How did the steppers feel, could you turn them easily a full 360 with no binding? I had something similar when my stepper motors had failed. They would miss steps making guiding unreliable. When I removed one I could feel it grinding rather than turning small steps at a time. Also check Eqmod logs make sure there aren't any errors over serial.

[jwoody]

That doesn't sound good.......
The only thing I can add is reset PHD to default, but such a big movement in RA and Dec probably not.
What happens if you choose the guiding assistant and let it run ?
Are there any bad, odd noises coming from the mount, especially when you get these big spikes in the graph?

Jeremy

[dizzy2003]

Am not sure how it should feel but its not grindy. And thats also why I swapped the dec and RA motors to see if there was any different on the assumption it was hitting RA all night)
I do get occasional eqmod comms errors, but I always have ,which is why I had to disable the limits check, and how I had the 'accident' in the first place:(
Also when tracking there isnt actually any commands being sent the on board PCB handles tracking pulses eqmod just sends commands to start and stop tracking and any change of tracking rate.

[dizzy2003]

I spent about 20 minutes watching the gears turn (with little bits of tape stuck to them) and listening to the steppers and I couldnt notice anything untoward when a spike happened. Am using asiairpro now which doesnt have guide assistant but calibration looks good. when my laptop was being used(its died) I did try resetting to default and doing full guide assistant run without any improvement.

[ChrisV]

I don't have a Skywatcher. If it's happening regularly what does that period relate to - one rotation of the worm shaft, stepper motor, etc.

rotating the steppers manually should feel like even clicks. If not that, can you disengage the steppers and manually turn the worm shaft - it should feel smooth while turning.

[dizzy2003]

As far as I can see theres no set period to the spikes, they can be 5 seconds apart several minutes apart and anything inbetween.

Yeah hand turning the drive shafts is smooth and non binding.

[Startrek]

I’ve owned a HEQ5, one worm cycle is 9.6mins
IMO a regular short period 12arc sec spike is either intermittent spurious data drop out during a guide pulse cycle or physical damage to the worm gear or main gear on the Ra and Dec.
My hunch is the latter due to the scope hitting the mount and grinding
You couldn’t visually see damage to gearing causing a 12arc sec spike ( it’s microns )
It’s a tough one to find.

[dizzy2003]

so I did a run with no dec guiding, and I still saw Dec spikes of about 12'' so that kinda ruled out pulse data issues for me (Unless theres something really bad happening inside the pcb with data crossover) its annoying asiair wont let me disable RA guiding pulses too.

As I understand it the large brass cylinder of the worm is brass specifically to be the weaker element that might get worn away (compared to the steel(maybe) worm screw part). My assumption is that if this was worn (as you say I cant see anything) it would be worn in one place not worn all 360 degrees, at worst 8 hours out of the 24 hours for the full circle might be worn, so I could expect to at least have a 25% chance of it not be using a bad bit of the worm gear (assuming I've randomised it enough).

I find the dec spikes the most incomprehensible. Without Dec guiding, none of the dec should be doing anything! which implies somehow a fault is in the RA that somehow produces an error in the Dec (sometimes) but no spike in RA sometimes. Which seems unlikely.

I guess if comms were intermittently scrambled an RA pulse could be received as a Dec pulse. I think i need to get my laptop back online so I can run a test with PHD2 just monitoring but not issuing any pulses. Having said that though, I did set the RA only guiding to be 5% aggressive, and didnt see any changes in the sizes of the 12"" spikes. I wonder what the data packets for pulses look like.

[JA]

Hi Michael,
In order to rule in OR out mechanical versus electrical or software issues affecting the guiding I would first do a back to back comparison, during the same session, of images with guiding versus images without guiding and look to see if the double stars you saw previously in even 30 second images are present in the unguided images. If they are not present I would focus my attention on the electronics and software rather than mechanical drive or wear issues.

Best
JA

[dizzy2003]

So initial tests (with asiair plus) doing 60 second subs guided and unguided have some interesting results.

Unguided appears to NOT have the double stars, but does have RA streaks with a similar frequency to guided (approx every other image).

Also trying different guide rates the spikes are proportional to the guide rate
0.5 guide rate produced 12.5'' spikes 0.9 guide rate produced 25 '' spikes and 0.25 guide rate produced 6'' spikes (Not sure what to make of that)

attached graphs and small subsection of the image of M20 as well as a full image.

Note scope is f9 100mm apo, so 900 FL no field flattener. using l extreme filter, cam is asi 533mc pro

The intermittent streaks in unguided imply to me its mechanical. But the guide rate being proportional to the spikes makes me thing electrical/comms So :shrug:


Maybe theres 2 issues..

[doppler]

Are you using a guide scope or oag? Random spikes can be caused by differential flexture between cameras when using guide scopes.

[JA]

The main determinant for me is the obvious star trailing (RA streaks) on UNGUIDED images 3,5,7 and 8, but NOT, despite some minor star ovality, on the other UNGUIDED images 1,2,4,6 &9. It clearly demonstrates a loss of drive to the RA axis, probably for just under one second*.

I suspect, when the guiding is TURNED ON, the guiding system tries to compensate for the apparent star movement (caused by this intermittent loss of drive) and the guiding system injects that large 12.5 arc second correction pulse.

*. It would be good to know the length of the star trail in UNGUIDED images 3,5,7 and 8 in original image pixels. Can you zoom in on the RAW 3008x3008 ZWO533 image in Photoshop and measure the length of the star trail in pixels, either diagonally or as so many horizontal pixels x vertical pixels. I suspect it to be around 14 pixels based on your image scale and the possible tracking intermittent failure time associated with the 12.5 arcsecond correction pulse, whilst tracking at the sidereal rate, but who knows? All info helps solve problems.

Electrical issue more likely, given the apparent randomness/Irregularity(?) you reported of the fault, who knows.... more info

BTW - have you ever tested with everything PLUGGED OUT except for the mount, a camera (preferrably DSLR) and power to see if there's still star trailing?

Best
JA

[JA]

Can you advise the specs (Output Voltage & Max current) of the 3 power supplies you tried? Or pictures of the makers impu/output rating label on the devices.

These mounts are somewhat marginal at a power supply voltage of 12Volts and many suggest their use at higher voltages, typically 13-14Volts. I believe even the manufacturer's spec includes such a range. I will check and repost a reference.

EDIT: I just checked and Skywatcher specifies 12 to 16 Volts DC 3A, see red circled spec in pic below...

EDIT2: I also found a Skywatcher USA site that specified it as 11 to 15 Volts DC 2A (so they're not even consistent ??)

Best
JA

[dizzy2003]

Am at work at the moment but I did zoom in on the really bad star trail (image 3) and it did look a similar length to the 12.5 arc second errors.



The short bursts of no tracking is what I assumed the original spikes to be. sidereal being 15''/s so I guessed at just under a second of no tracking to get the spike.

And I have had cases of just tracking the moon (during a lunar eclipse) over hours the mount falling behind where it should be

I guess in asiair after I changed the guiderate I should have recalibrated, but that doesnt really explain the doubling in spike, the spike should happen first (2 second exposure on guidecam) then the correction should happen, and if it needed a recal the correction should just be over or under.

Re power supplies am at work at the moment so will have to get exact details later. But I know the one on the mount is 14V and at least 3Amp (and was bought from possibly RS components) the power isnt shared its dedicated to the mount. The asiair has its own power supply shared with the asi 533 , some ebay 12v 6a power brick. the 3rd unused is also an ebay job.

[dizzy2003]

Guide scope but my tapping on the guidescope produces a 4 arc second spike which I figure has to be more than any flex would produce. and am seeing 12 arc second spikes

[JA]

Hi Michael,

As far as diagnosing the root cause of the intermittent star trailing problem you are "LUCKY" in a way that the problem relates to an apparent intermittent, but recurring, lack of tracking. Why do I say "lucky"? Because you can dispense with the time consuming testing required with mount setup, aligning, guiding, imaging etc.... All you need to do is focus on the mount itself for the moment. Later when the cause is narrowed somewhat, and some changes potentially made, retest it for tracking using imaging.

We only need the mount, its power supply and means of starting its tracking. Perhaps a hand controller would be easier than the ASI Air which might inject more variables. Later we could retry to initiate tracking with the ASI Air to confirm.

Call this Home diagnostics 101 for your issue:
1. Remove the HEQ5 Pro side panel to expose the RA and DEC drive motors and gears.
2. Inspect the gear drive for anything untoward, excess wear, tooth problems, debris in the drive train,etc...
3. Check that the RA pinion gear and RA driven gear are locked tight on their drive shafts.
4. Check that the DEC pinion gear and DEC driven gear are locked tight on their drive shafts.
5. Check any backlash present.
6. Power the mount ON and go through the hand controller start up procedure and set TRACKING ON.
7. FOCUS your attention very closely on the RA pinion gear. Based on Skywatcher's specified 705:1 gear ratio I would expect the RA motor pinion to make 705 revolutions per 24h in which time the RA axis will revolve once. If we factor that down further the RA pinion gear will move ~29 revs per hour or ~0.5 revs per minute or ~3Degrees every second. And that's the kicker. We know from previous tests that the mount looses tracking for about a second every few minutes. I think that , although difficult, and perhaps with a magnifier or video you should be able to see the RA motor pinion STOP for about a second every 2-3 minutes as per your previous findings. Bear in mind the RA motor pinion is, I'm guessing, something like 10mm in diameter then if it stops for ~ 1 second a point on its circumference will not have moved the requisite ~0.3mm. That's the size of the change you should focus on, hence possibly use a magnifier.
8. Observe whether the issue also exists with the DEC pinion as per step 7.
9. If you have been able to see the fault as described (the intermittent stopping of the tracking), then you are lucky because you now have a test bed on which you can make changes to help you search for the root cause. Try different power supplies, reseating any motor connectors You need to remove another cover for that). If you are electrically inclined or have a friend who is you could look at the motor drive voltage/current and see what happens to it during a stoppage of drive. Also check the power supply voltage as a function of time. A storage oscilloscope function would be great for those tests. I could imagine that the mount crashing in to the tripod may have overloaded the drive electronics and potentially damaged the output drive, fried an output transistor(?) depending on the circuit protection.(???)
10. Retest above with ASI Air control of tracking ON to the mount incase somehow there is an intermittency to the cable????

The fact that this loss of tracking is presumably occurring in RA and DEC suggests a common (probably electronic) cause in the drive circuitry or problems with the internal mount power or power supply.

Best
JA

[dizzy2003]

@JA

It has a rowan mod.
I happen to have been down this road before back in april, where I tried to use a time lapse mode on my phone to look for issues filming the gears.

https://www.youtube.com/watch?v=MLZM-2pWufk

I think that was like 20 mins of realtime but cant remember.

I think I need to try doing this with the mount loaded up, maybe for a few more hours. I think I came to the conclusion that the errors are too small to see anything going wrong, even timing rotations.

Will absolutley double check the grub screws on the motor drive shafts are tight. But I did try (months ago) swapping the ra and dec motors without any benefit seems unlikely boath would have been slipping but who knows.

Thanks for all the advice so far BTW..

Mike.

[dizzy2003]

@JA I'm skeptical I am 'lucky' :) because I cant see how the tracking issue would cause such huge spikes in dec. I think maybe theres multiple issues at play here. But yeah solving RA would be a great great start and you never know might mysteriously fix dec.

[JA]

That may have been helpful to know:D, but mostly the same applies in terms of physical checks, other than to suggest checking the belt tension is not too low or some possible belt damage.


I agree that's why I suggested it is more likely there's a common cause such as electronics / power or supply

Best
JA

[JA]

Have some one look at the voltage supply / current used by the motors as a function of time. Perhaps a faulty component or one damaged by the mount crash.
PS: Can you also try a hand controller on the mount with no guiding, just tracking in case something is getting garbled somewhere?

Best
JA

[dizzy2003]

@JA

>I have a heq5 pro mount (with rowan belt mod)

you had me doubting myself, but I did say rowan mod right at the start. :)

I did try looking at the pulses to the steppers with a home brew arduino oscilloscope, but it was a bit chaotic in there :) Would love to be able to get some internal info on whats going out to the stepper motors

As I understand it the tracking is handled by the cpu on the PCB. the hand controller /eqmod simply tells the pcb to track or not to track, and what the tracking rate is I wonder if I can pull the eqmod cable and have it still continue to track that could rule out random comms signals doing stuff.

[JA]

My bad.... Looks like I missed that:D



That's interesting .... perhaps that is what is going on/off intermittently? It might be instructive to test the mount with only tracking initiated via hand controller alone and then look at the images for any star trailing.

Best
JA

[dizzy2003]

Well heres an interesting result, its still ongoing testing but.

I setup with asiair as normal to make sure I was getting errors. so asiair guiding and doing 60 second exposures seeing spikey errors as usual.

So then I stop the asi guiding and plug the guidecam (asi 120mm) into my laptop and run phd2. (I actually home the mount then point it back to m20 which I wish I hadnt done should have just left it).

But the phd2 monitoring isnt showing any spikes, its showing very bad polar alignment and its showing pec errors but otherwise its normal enough.

I plug the guidecam back into asiair (enable guiding on asiair) and the spikes are back.

My initial reaction is the asi 120mm is some how causing USB errors that are sending the mount crazy.

This is very promising news.


Edit:

When I switched to laptop I used a longer cable from guidecam to computer, am now trying that cable with asiair guiding, if its the usb cable from the guidecam that would be a huge win (cheap) at the same time also mega frustrating that its been months to narrow it down to this 1 thing. Normally this short (40cm) usb c cable would have been plugged into either the asi533mc as a hub or direct to asiair (I tried both incase it was the asi533 hub)

Its been about 4 mins with the new cable and no spikes and rms is at .58''
But scope is almost at miridian so it could be that its coincidentally at a good spot.

Edit2: spoke too soon just had a 8 arc second spike after about 6 mins on new cable

[dizzy2003]

attached is an image of the laptop monitoring the ra /dec error with phd2. while asiair was imaging and was connected to the mount.

Just to be clear I think this is pretty good (polar alignment was crap, we are really just seeing pec and probably some atmospheric noise certainly no gremlin spikes)


On the subject of my bad polar alighment, I align repeatedly with asiAir get it under 30 arc seconds, but meansuring it its often 8 arc minutes out!
My suspicion is that when asiair requests the mount to turn 20 degrees in RA, it might only do 19.6 because of these issues I have, resulting in the maths being ot and the polar alignment ultimatly being wrong. I look forward to trying the polar alignement without the 120mm to see if its aligns better

[sunslayr]

Maybe you should check if all the bolts on the housing and saddle are tight. Perhaps something is loose and flopping about.

[dizzy2003]

Theres no play that I can find. nor even in test where I tap the guidescope with my finger and only get 4 arc second spikes

[ChrisV]

So
- no spikes when not guiding = nothing wrong with mount
- no spikes when guiding through a PC = nothing wrong with camera, guiding and cables
- spikes when guiding through asiair = something wrong with the ASI air or specific cables used with It?

Great detective work

[dizzy2003]

No Not quite.

The PC and asiair both suffer same spikes.

At this point it appears to be the asi 120mm camera, which is ironic because I cant guide without it and its guiding that I always use as a test to see the spikes in PHD2, and its probably about the one thing thats been consistently plugged in through all my tests. I have always just assumed it must be the mount (having bene through the power supply and eqmod cable alternatives) that the camea worked but produced usb comms errors was not on my radar.

It was only when the asiair controlled the mount (really just leaving it tracking) and the guidecam was connected to the pc as a phd2 monitoring tool that I got good phd2 results (no spikes)

So my next test will be recreate the spikes (easy) then disconnect the 120mm camera and use the asi 533 for guiding. view the guide graph, do I get spikes, swap back and forth a bit. If it still indicates the asi120mm is the problem, double check with a few different usb cables on the asi 120mm.

Assuming it is the asi 120mm and not a cable or two! (unlikely) I will make a warranty claim, its 2 year warranty and is 18 months old.

Am really hoping its not just random coincidence playing with my conclusions. and it really is the guidecam.

[Startrek]

Hmm….
I had ongoing issues with PHD2 using the 120MM USB2 camera
Bought the 120MM-S USB3 camera and has been working flawlessly ever since

Which 120MM camera do you use ?

The older 120MM USB2 camera did have inherent connectivity and data flow problems ( ZWO offered a driver patch but I ditched the camera )

If your using the 120MM-S USB3 with a quality certified USB3 cable no longer than 1.5m ( eg Startech brand or similar ) then ignore this post

Cheers
Martin

[dizzy2003]

Its described on the invoice as "ZWO ASI 120MM Mini Guider"

It has a usb C connector and a st4 connector. and came with a cable 1.5m , but I think I may be using a cable that came with the asiair pro its a very small one. But It might just be a cable I bought at some point, to have a short cable to the asi 533mc hub

[Startrek]

I use the 120MM Planetary camera for guiding , not the mini
As far as I know the Mini cameras are ok provided you have all the latest ZWO and Ascom drivers installed and latest windows updates

Just another suggestion , have you checked the power management of your USB drivers on your computer
Attached is how to check Windows 10

Cheers
Martin

[RyanJones]

I’ve been watching this post with interest although I haven’t had any solutions so that’s why I’ve stayed quiet. From the last few posts where you seem to be leading towards the camera, I just want to clarify something. Is your 120MM mini connected to your camera as a hub or directly to the AIR ? I have always run mine direct to the AIR. It all seems a bit interesting though given it’s something that has just started happening.

Cheers

Ryan

[dizzy2003]

Yep the windows usb power management was an early attempt to fix (I should have included it in my initial post). Plus wouldnt be relevant for the asiair.

My computer asi drivers probably are a bit out of date, but the asiair is bang up to date.

Doesnt look like theres such a thing as firmware for the camera so thats a shame.

[dizzy2003]

As part of my trouble-shooting I have tried both, as at one point I thought maybe its the asi 533's usb hub because I had seen people having issues with USB hubs. Either direct or via 533's usb hub spikes happen.

[RyanJones]

I must say it’s a really interesting problem you’re having. The non periodic nature rules out some things and the fact that it’s the same magnitude excursion but on both axis really does confuse things. I shall continue to watch. I hope you find a solution to it.

Cheers

[dizzy2003]

I wish I could enjoy the investigation from afar :)

[dizzy2003]

WELL FFS

no main cam, just guiding, swpamming the guide cam between 120mm and 533mc

Spikes on both. :(

Attached image.
weirdly spikes are different 120mm is showing spikes on RA and dec at same time

Spikes on 533MC are slightly smaller and dec only.

nothing makes sense anymore..

Maybe just heq5 comms is broken..

[AstroViking]

Hi Michael,

Probably a long shot, but do you know anyone local to you with a known-working mount that you could put your cameras and ASIair onto?

You seem to have tested just about everything else.

Cheers,
V

[dizzy2003]

Unfortunately no.

I dont think the cameras or the asiair are the issue anyway (now).
Its unlikely the 120mm and the 533mc both have the same issue.
Its unlikely my windows laptop and asiair both have the same issue.

Currently wondering if the spikes were combined from both cameras would that display a similar frequency to when I have normal guiding and image capture going on. And if so that would imply more traffic on usb equals more errors. having said that normal imaging would not create much USB traffic from the imaging camera (once every 60 seconds or whatever the exposure is)

The only thing I really have conclusive is sending guide pulses to the mount seems to cause spikes, and the spikes are in proportion to the guide rate.

:shrug:

[JA]

Hi Michael,

I would suggest you go back to ZERO or as close as possible, to understand the root cause of the problem. That means testing ONLY the mount, with nothing mounted or connected, just the hand controller to start the tracking. Then if something is discovered with mount tracking that indicates a glitch in tracking , it's the mount at fault. If nothing is found add further complexity/variables and then look for a glitch, reassess and continue until potential cause is found.

We know from tests (imaging with and without guiding) that you've done that the issue presents itself every few minutes with a similar magnitude of ~12.5 arcseconds on both RA and DEC drives.

As I discussed a few posts ago, given the Skywatcher stated 705:1 drive ratio of the HEQ5 mount, the 12.5 arcsecond correction pulse you are experiencing should equate to just under one second of elapsed time or 3 degrees of rotation FORWARD or BACKWARD of the RA or DEC motor pulley (or motor pinion gear in the case of a standard non-belt modified HEQ5)

Watching an ~10mm diameter pulley rotate and observing whether it stops , retreats or advances 3 degrees in one second may not be that easy to do. (understatement) and that's why your earlier idea to video the drive pulleys was 100% on the money, BUT you did it in time lapse mode where one rotation of the motor pulley took about 12 seconds instead of ~120 seconds. You should go back to that investigation and video the drive pulley, zoomed in as close as possible to the pulley, in real time not at ~10:1 timelapse. Then when you have several minutes (say 10 minutes of realtime video, open the video in a video editor and go through it frame by frame looking for any odd movement or lack of movement, be it: stopping, reversing direction, slowing speeding etc... Yes it will be a few thousand frames but at a typical video frame rate of 30 frames/second you should see everything you need to see to confirm the existence of a possibly 1 second or so long event that occurs every few minutes. If you don't see anything go longer until you're certain of an issue or that there's no issue.

As an alternative, to amplify the tiny motion we are trying to observe, you could try also mounting/balancing a tiny red laser pointer to the top of the motor drive pulley with some blue tack, place the HEQ5 in a large dark room so that it is lying on its side flat on a table and look for non-smooth/start/stop etc.. motion of the red laser dot across the walls over several minutes.

Best
JA

[dizzy2003]

Ha yeah your right I made the video 10x more inaccurate by using time lapse. a major issue I had with trying to time it was judging when exactly a full turn had occurred. I will try it again soon though and see what happens, and specifically with and without a guide camera connected and running taking images (as I still suspect it might be the connection of these items causing comms errors, after the result with the guide cam monitoring from a device not connected to the mount which showed no spikes)

I also want to pursue the test I did with the guidecam on the computer while asiair drove the mount, see what happens when imaging/not imaging.

Be interesting to see if I can clear run of non streaked images (within the range of pec errors anyway) or does taking Images on the asiair cause spikes I see on the computer monitoring the ra/dec errors. Bonus points if I can go back and forth between these errors while filming the cogs turning with time stamps so I can match up frames to phd2 spikes.

[Startrek]

Just browsing the EQMOD forum , I found this post which seems to have similar issues with his HEQ5 mount , cameras , tracking and guiding etc… to your problem

Don’t know if this helps , but worth a read I suppose

https://groups.io/g/EQMOD/topic/heq5_comms_errors/90508713?p=,,,20,0,0,0::recentpostd ate/sticky,,,20,2,0,90508713,previd%3D1 655378905155698710,nextid%3D1650546 582773794168&previd=1655378905155698710&nextid=1650546582773794168

Cheers
Martin

[dizzy2003]

I did some more tests last night, I need to go back through them all carefully, but it seemed like non guided tracking was fine. Doing 30s exposures and 60 second exposures.

As soon as I started guiding with phd2 the spikes came back, then I had about 20 minutes without any spikes then I slewed from M8 to comet 2017 k2 parastarr and immediatly started getting spikes again. (Which makes me wonder did I just find a good spot on the worm gear then moved to a rough spot)

Anyway its occured to me that I should try the st4 port for guiding. I've never touched the ST4 port, but I assume I can guide with it from phd2 with my computer connected to guide cam via usb, and the guide cams st4 port connected to the mount.

[dizzy2003]

Yes I know him. he's me :)

[Startrek]

Well blow me down
Apologies, didn’t see dizzy2003 anywhere on EQMOD
Gee I hope you find this gremlin
So bloody frustrating hey
Cheers
Martin

[dizzy2003]

Havent been able to get any guiding going with ST4.



If I set the asiAir to st4 via camera the mount stops tracking.

I tried the computer connected to the camera which is connected to the mount via st4. and phd2 set to st4 via camera. but no signals got through the mount had a hand controller plugged in. unplugging the hand controller seemed to stop tracking.

So am not sure how anyone is meant to use st4 via the camera with a heq5 pro.

Attached is an image zoomed in of using computer to monitor mount with PHD2 which asiair takes pics

and a zoomed out full hour.

Am not sure if thats good or bad for that polar alignment.

The pics at 60 second exposure werent great especially being at 900mm FL. But thats what you would expect with the ra/dec having what visually looks like about 4 or 5 arc seconds of movement in each 1 min exposure.

Theres certainly no spikes.

[DiscoDuck]

Sorry if this has been raised already (have only just seen this today and caught the end of the thread), but if the problem only happens when guiding is switched on, could the spikes be due to over-compensation by the backlash compensation algorithm?

If you switch backlash comp off, do the spikes disappear?

If it's too large, whenever dec changes direction you will get a spike - and then at seemingly random (not periodic) times.

Just my 0.5 cents.

Paul

[dizzy2003]

Sounds like an easy thing to try out..

Allthough I dont think asiair does backlash compensation.

[dizzy2003]

So I taped an old phone to my mount and had it display the guiding graph

Built a cardboard contraption to hold a second phone that filmed the first phone and the gears moving.

so for now I'm going to ignore dec (because the results are confusing) but for RA

theres +pv spikes and negative spikes, which is weird for a start. But Anyway What I see in the video is

+ RA Spikes, I see the motor turn twice as fast for a second or so then I see the motor stop, then I see the spike appear on the graph. I believe the graph is a bit delayed (has a bit of lag) and I am seeing the cause of the error (double speed RA motor movement for a second) followed by the phd2 guide fix (stop RA for a second or so)


-RA spikes I see the motor suddenly stop turning, then it runs at double speed to catch up. So the stopping is the cause of the error then the double speed after is PHD2 fixing the guide spike

To me this seems like control board issues. If I only ever saw it stopping then that could be mechanical, but having it sometime turn twice as quick for a bit causing the error indicates non mechanical issue.

Is that logic sound?

I saw some great guiding between spikes at one point it was about 0.5 arc second RMS.

Anyway I uploaded a video to youtube

https://youtu.be/VG2WA5tCrgc

Description has some time stamps. I was going to edit the video down and zoom in, but davinci resolve would not load this 120Hz video from my samsung phone.



Hmm do I now pull the trigger on a replacement pcb ?

[RyanJones]

Hi Michael,

It is an interesting video to watch and I like the way you’re going about finding the problem. Before pulling the trigger on a board though, I’d be making sure that the reason the motors are doing what they’re doing isn’t because they’re being told to. I’m seeing no period to the faults and I feel like if it were a board fault the amplitude of the spikes would vary more than they do. I wouldn’t expect the spikes to be so consistent in nature from signal drop out unless there was consistency to the period. That’s just my take.

Cheers

Ryan

[dizzy2003]

Yeah there's certainly no guarantee its a pcb issue but am struggling to think of alternatives..

Its also interesting to me that the spikes are of consistent length and are directly proportional to the GuideRate so 50% guiderate is 12.5 arc seconds. 100% guiderate is 25 arc seconds. (In this video I set guiderate to 100% to make the spikes easier to see)

my assumption is that some noise on the comms is causing a signal to be occasionally be misinterpreted and it lasts the length of the guidepulse.

I should see if I can see what the comms commands actually are.

I've tried 2 different computers and a asiair and 2 different eqmod cables. so unless I need to try a third cable it seems like any comms errors is internal rather than external to the mount.

[RyanJones]

That’s really interesting. So the error is a single guide pulse in length what ever that guide pulse may be. So what is your guide interval ? And what happens when you shorten or lengthen it ? Not that I think that would be a “ fix “ but it would be interesting to know. I still find it quite interesting that is has the same fault on RA and Dec with the same amplitude and yet not the same frequency.

I’ve said before, I’m at a loss to help explain it at the moment but I’m certainly trying to think my way though it.

Ryan

[dizzy2003]

I'm guiding with 2 second exposures, I have tried different exposure lengths but not with any great rigor, I didnt notice any difference but would need to run some more careful examinations to check.

Its confusing that its RA and Dec and also both sides +ve and -ve. In the video I couldnt actually see any motor movement during dec errors but I need to put a bigger visual spike on the dec motor.

I have found a local guy who does PCB repair hoping he can at least check the solder/caps for me and spot any obvious issues.

[DiscoDuck]

Have you checked the commands being sent to the mount to see if there are errant commands from e.g. PHD at the time of these spikes. I believe EQMOD has a log.

That would narrow the issue down between the controlling PC and the mount.

[dizzy2003]

I have not(i dont think asiair has logs for commands), its unlikely software related as it happens with both AsiAir and windows PC. I am using eqmod on pc, but AsiAir is INDI based.

Would be nice to see those logs though to see if its a phd2 command at that time that gets misinterpreted by the HW. (my current theory)

[JA]

On the subject of possible electrical faults you should consider removing the curved cover over the RA Axis shaft to expose the motor connections and PCB AND whilst carefully observing the guide graph touch / wiggle the motor PCB connectors, PCB board at various points AND whilst tapping/wiggling, etc...look for any obvious response in the guide graph also look for any signs of defective components like bulging/leaking capacitors, burnt/overheated components, broken /frayed wires or dull looking solder joints, cracks in circuit board traces etc....

Best
JA