malc-c

Just to keep anyone else following this thread up to speed, I've been in daily communications via PMs as we try and resolve the issue. Thinking it was the driver chip, I persuaded Astro-Geek to purchase a replacement and suggested an easy way to remove the old one and solder the replacement to the board. Regretfully this had no effect, and the remaining two chips (a hex schmitt trigger and an OP-Amp ) were also replaced. Sadly the fault remained, and tonight Astro-Geek confirmed that all the discrete components have been tested by comparing like for like with the known working board. So this just leaves the PIC micro as the possible cause. Now Synta will have copy protected the raw HEX code, but as the firmware can be uploaded via a PC application this suggests the PIC as a bootloader running. The firmware that you can download from SW website is encapsulated in a wrapper so it's impossible to extract the raw HEX code and attempt a reprogramming.... The Copy protection also means that its not possible to read the code on the good board and then squirt it back to the faulty one..... So that basically means we can't do much more and that a new board is required. At least through deduction and Astro-Geeks willingness to attempt some resoldering (which by the image he sent me he did very well) we learnt a lot about these boards. Its been fun, and it would have been nice if the efforts resulted in a fix in the same way I fixed my HEQ5 with just a couple of capacitors, we'll just have to chalk this one up as unsolvable I'm sure Astro-Geek will keep us posted once OVL or other SW suppliers are able to source replacement boards from China

A lot of that detail is educated guesswork, and presumptions that other components haven't failed (I feel this is turning into a new Sherlock Holmes mystery - a lot of deducing !!) I'm not an electronics expert, but also having a background as an IT technician tend to follow a logical path when problem solving, which more often than not works... but I'm not infallible

Reading up on the goto dobs, they use DC motors with dual encoders on both axis. This would explain the two 4 pin headers labeled IR sens and the three pin Motor header. It would also explain how the scope can be moved whilst tracking, something that is difficult to do with stepper motors because stepper motors get locked by the two phases. Given this, it should be possible to use a standard DVM between GND and pin 3 and then GND and pin 8 to see if there is any voltage being sent to the three way terminal header. If there is no voltage then this would confirm the L293DD chip has blown. Repeating this on the good board that is known working should confirm this. Again this is presuming that the DC motors are being controlled by pure DC and not some form of pulse width modulation, which would need some scope or logic analyzer to confirm, but from what i've researched this evening, the direction control (and speed) is via the corresponding GPIO pins going logic high or low...

I thought that, and I think I've discovered something. The motors in this mount may not be steppers. If you look at the large image on page one you see that pins 3 and 6 go to the two outer pins of the three pin socket labeled MOTOR. There are two capacitors between pins 3 and GND and 8 and GND. As there is only one set of two wires this would suggest the motor suggest that the motors used are DC, and that the use of precision encoders are used to maintain tracking. Not sure how the motors are locked off as steppers have a holding torque....

Ah, so it was more of a physical issue than electrical. I've used NEMA motors in s few projects and thought the flats an shaft lengths were standard. Mind you, wouldn't put it passed SW to come up with some " exclusivity" in order to sell them at infated prices

£3.99 from RS.. so not expensive

Assuming the processor is fine and sending pulses to the driver chip, then this would seem the possible cause.

Uhmm... the L293DD chip is a push pull four channel motor driver... so it could be that chip that's not working

My guess is that its a driver chips that's failed (possibly one or both of the 14 pin packages) on the master. I'm betting that the two boards are identical with the same firmware on each, and the two processors communicate using some CAN bus or similar, which is why the slave board works and you don't get any error messages on the handset. Can you advise what markings are on those chips. With some flux and careful use of a soldering iron those should lift quite easily and would be the things i would replace if this was my board

Right, I have a better understanding on how the mount is configured. Bit confuddled with each board having two motor terminals, one being three wires as most steppers use four so no idea what the 3 pin socket does. I know it seems obvious, but have you tried a different RJ45 lead (without a diagram its hard to know if it used a cross-over cable or straight through) Is power to the "slave" board fed through the same RJ45 lead ? They appear to be identical boards, other than one has the power switch and socket and the handset connector removed. I doubt that they would have different firmware on the processor (could be wrong).

The only problem there is that unless a component glows or smokes there is no means of telling if the current draw is excessive or not as SW don't release technical data at this level. - but good suggestion otherwise. That's surprising you had to wait so long as the steppers in the mount are standard NEMA brand and these are commonly available from loads of sources

I must admit I'm struggling here.... On the HEQ5 and EQ6 mounts there is a small interface board where the handset / power and ST4 cables can be plugged in, with a cable connection to a single motherboard. The two steppers connect to the motherboard directly. In your posts you give the impression that there are sub assembly boards with the motors on board rather than just the wires from the motors on each axis. But as you have plugged each axis motor / sub assembly into the board on the good known working port and they work, then it would suggest its the chip that that drives that axis that's the cause of the problem. Can you post up a connection diagram? I'm presuming that the other connectors on the board are for encoders so the mount can still track and goto even after a manual intervention? However, as mentioned, without test equipment to see what signals are like on the chips I doubt that you will ever get to the bottom of this issue. With OVL out of action and not able to give you a lead time on spares then its a case of sit and wait until restrictions are lifted and a replacement board can be sought.

I personally don't think this is something minor Observations: The handset communicates with the mount. You can move the mount in AZ. The PC software can communicate with the mount and identifies the existing firmware. - This means the processor is working on the main board. The mount can be moved via the hand controller in the AZ plane - this would suggest that power is getting through to the motors and that the driver chips on that axis is fine (assuming that when powered you have resistance in the motor of the axis that has failed). The fact that you get no movement on the ALT plane would suggest that either the motor is non-functional, or the driver chip or one of the associated support components has failed. The fact you swapped motor connections and it functioned would thus point towards component failure for the driver board used. Now unless you have access to scopes or other test equipment and SW were forthcoming with a schematic (the latter I doubt), and the ability to desolder and re-solder to component level then it might be time to bite the bullet and purchase a new board. The drawback is that OVL have closed (AFAIK) due to CV19. I'm only familiar with the HEQ5 which has the one main board rather than a mainboard and two driver board (you mentions swapping ALT and AZ boards). If this mount has two such "driver" boards and you#ve swapped them and the fault follows the board then it would indeed suggest in issue with just that board. This could be a simple capacitor or, and gut feeling, the actual chip that does the pulsing. The only fly in the ointment is the fact that whilst the PC software can read the existing firmware, the bootloader wasn't able to update it.

Freddie, so my basic analogy for when I omitted to include the focal length was close? I'm guessing that the reason the software asks for the focal length and camera details is so it can calculate the movement in arcseconds and thus be meaningful when compared to other peoples results, or results on the same scope when different guide scope or camera is used.

Here's the comparason

Yeah, I think you're right, It's been fun learning what all the bells and whistles in PHD2 do... but I think in my journey documenting the process of getting hung up on seeking the holy grail of a perfectly flat line and tight clustering on the target graph raises several points. One of those that I found interesting was that I did a comparison of a single sub taken when I inadvertently left out details of the guidescopes focal length with one I took of the same target last night having created a new profile with that information correctly entered. At full frame, looking at the same groupe of star there was absolutely no difference in shape or size of the stars between the images. Now maybe I have been lucky and managed to hit that sweet spot on the balance and CofG and my PA an PEC are good enough that this omission had no impact. Or it could highlight an "issue" with PHD2 in that the numbers are all meaningless ? - Comparing the two target graphs they were so different, but there was no difference in the resulting image Anyway, onwards to the next learning stage, how to process and get the most out of the data I'm capturing 😉

Well the stars are round so it must have worked

Thanks for the tip. Log file attached.... best trace was the last.... I'm guessing that for an HEQ5 / 200P having those RMS values is a good result ? PHD2_GuideLog_2020-04-19_210404.txt

OK, well as its clear tonight I thought I would run one last series of tests, and this time the focal length of 181mm was correctly entered. I'll upload the log file later as I'm running a series of subs on NGC2903 and will stack them later to see if the stars are any worse or better. So to start with, having set the scope to 00:00:04 DEC and 08:50:55 RA I did a run of around 20-30 minutes. I then ran the guide assist four times (restarting the tool each time) and accepted and applied the suggested improvements after each time. I've attached the screen captures of the final three - The final result was a backlash value of 804. I then pointed the mount at NGC2903 and began guiding. Comparing the screen grab to the one shown at the same settings uploaded on Wednesday the trace is slightly but noticeably improved, and a lot flatter. But the target graph is more scattered, presumably as with the focal length inputted this affects the spacing ? I'll upload the log file tomorrow so you guys can comment on how good or bad the mount / scope is performing

For some reason this didn't get uploaded the other day One final image, NGC 2309. Again, just a stack of 18 x 240s subs and 18 matching darks - I'm happy with that, and no doubt with processing would be even better

Alacant, I think you have a point. So often we get wrapped up with trying to seek perfection that we never get round to actually doing astronomy. Regardless of what happened last night's PHD trials, I'm happy with the resulting images. I still need to perfect my processing skills, but that's a topic for a different day, but here is the results of 16 x 400s subs and 16 x 400s darks stacked in DSS. No flats, bias frames etc.... I've resized the image, but took a crop around the galaxy from the full frame.... stars look round to me I might try one more profile this evening just to see what the results are from curiosity... I'm guessing that as Michael has commented, with the backlash reduced and the results from the guide assistant the scope's balance and CG along with low backlash and decent star profile values it should mean the traces should be good. All I know is last night resulted in one of the sharpest images of M81 I've ever had.

Here's my take... When it was calibrating it moved the star 20 steps in X direction and back in Y, then 20 steps in A and back in B recording how many pixels or parts thereof it moved. It then starts guiding based on its algorithms or simply applying corrections based on the star movement. If the star moved 1 pixel in direction X it corrects sending a pulse it calculated to move the mount 1 pixel in direction Y thus maintaining the stars position, thus guiding. If the weather holds I might try another run, but this time ensure the focal length is entered. I'm guessing I could always load in last nights profile again if the results go really wrong ?

[removed word]... I thought it was too good to be true.....But it worked I must have missed that when I created the new profile - but then I ran the wizard, and would thought you couldn't move on to the next page without entering the info...... It is perplexing though.... enter the focal length, and I bet the guiding will be all over the place.... leave the focal length out, and run the calibration and you get amazing results that keeps the mount almost perfectly pointed.... If this is the case then what's the point of specifying the focal lengths.

Log file attached PHD2_GuideLog_2020-04-15_203913.txt

Ian, If you haven't already stumbled across my thread on resolving my issues with tuning the guiding on my HEQ5 have a read here https://stargazerslounge.com/topic/351622-phd2-graph-comments-please/ The attached screen grab is after a 40 minute run - I'm able to take 4 minute exposures with no issue. Its all down to balancing the mount, polar alignment and removing the backlash. I would recommend spending £10 and purchase SharpCap Pro if you haven't already done so. Use its polar alignment routine and get the polar alignment as good as you can. Ensure the scope is balanced and the center of gravity is as close to the balance point (Astronomy shed videos on youtube are an excellent resource). Then its just a matter of fine tuning the backlash on the mount... I was about to throw in the towel as it took me several attempts, but patience is a virtue