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..
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.
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
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.
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
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.
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
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.
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.
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
Sounds like an easy thing to try out..
Allthough I dont think asiair does backlash compensation.
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.
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 ?
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.
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
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.
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).
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.
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
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.
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.
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.
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)
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....
