Seelive

Hope they get it sorted quickly for you.

Just a diode in the positive supply will provide reverse supply protection.

So here's my stack of your lights + calibration frames (no processing, the TIF straight out of DSS). This is with the stacking method set to Auto, quite an abstract work of art!: And this is with the stacking set to Bilinear, still not good enough but a lot better. As previously pointed out by carastro, the lights stack perfectly without the calibration files, but I've not have the chance to try each possible combination. That's something I've also seen in the past but never got to the bottom of it - I'll leave that to you!

Definitely DC to DC converters are the way to go at those power levels. Based upon your circuit diagram, your total output power requirement is 70 Watts with a maximum current draw of 7.5 Amps. The 24 Volt supply would therefore need to be rated for at least 180 Watts, and the linear regulators would need to capable of dissipating up to 110W. Even if the DC to DC converters only had an efficiency of 80%, then the 24V supply rating would be reduced to a minimum of 88 Watts, and the total power dissipation would only be 17.5 watts. Depending upon whether you go for off-the-shelf DC to DC convertors or decide to build your own, you may need to use a linear regulator to generate the 7.4 volt supply, but it you use a LDO type from say a 9 Volt output DC to DC converter, then any additional power dissipation will be minimal.

I've had similar problems in the past, especially with Milky Way images. DSS has successfully stacked some of my images with the threshold set at 2% (more than 40000 stars detected!) but on other images, even with the threshold set at a much higher value, I've still ended up with 'swirls' (at worst, or just elongated stars in one particular area at best) in the stacked images. I've found that changing the alignment mode from 'Auto' to Bisquared or Bilinear cured the problem. If you look in the stackinfo.txt file, you will see the stacking coefficients used for each image. If you see any numbers (within the brackets next to the alignment method used for each image) much greater than 1 then the stacking is likely to have had a problem. Unfortunately, each number is to 20 decimal places and there are quite a few of them for each file!)

It seems that the serial and ground connections between the handset and the mount are OK as the mount/handset works as normal with the USB port connected. I agree with Lonestar that it could be the cable, but it would be very unfortunate (but not impossible) that it just happened to be the supply pin connection that was faulty (1 in 8 chance). Do you know anyone with the same mount so that you could try their cable?

As far as I'm aware, you only have to mark the comets position in the first and last frames and DSS will automatically sort out the position of it in all the other intermediate frames.

I've used the free Starnet software (https://sourceforge.net/projects/starnet/files/) to remove stars from images quite successfully on several occasions to allow separate processing of the nebula and the stars before recombining them. Their is a PI module version but more relevant to you is the standalone version (which is what I use). The images do need to have some stretching applied for it to be successful.

If the handset no longer functions when it's just connected to the mount, then it sounds like it's not getting the power from the mount to operate it. When the USB is connected, the handset can get it's power from the USB port. If you just connect the USB to the handset but not to the mount, does the handset power up but complain that it can't talk to the mount? It could be something blown in either the handset or the mount, SkyWatcher don't seem to make their electronics particularly bomb proof. See it you can measure any volts coming from the mount (I've seen the RJ45 plug pin-out on here in the past but you would need to do a search). If there is a supply coming from the mount then it's likely that the handset at fault.

I wouldn't have thought it makes much difference on a comet between a modified or an unmodified DSLR, but others may disagree. As to prime focus or piggy back, I suppose it depends upon what focal lengths you will be using. If you're talking about Comet NEOWISE then it's now got quite decent a tail so just make sure it will all fit within your FOV.

I'm sure a lot of people would say go down the EQMOD route and forget the handset, but as I said, my current set up works for me and does what I want, so I don't see the point in adding another layer of complexity even though I perhaps should (I would probably still be using windows 98 if I could!).

I appreciate that it's a real pain when things go wrong, and I'm certainly no expert in this field, perhaps someone who is (and I'm sure there are plenty on this site who are) can help you further. I suppose I was lucky, I installed everything and it all seemed to work first time. I would suggest that, for the time being, you just ignore the pop-up window and close each time it appears until the more important issues are sorted. With the weather as it has been here and the light nights, I've not used my set-up for a few weeks. If I get the chance, I'll set it up tomorrow to see what I actually get. I'm still a little confused over your comment '... and try the Manual Guide buttons in PHD but nothing happens'; PHD won't do anything until it has selected a star from the guide camera image to guide with.

I hate today's software too! Bring back DOS, at least I stood a chance of understanding that!. I've not come across the 'driver error about location' so I would be only guessing at an answer. When you say the 'direction buttons', are you talking about within PHD2? I get a small popup screen when PHD starts up that I think is related to C2A but has nothing to do with PHD2. Normally, I just close it and use the handset to control the mount, but to use it, I had to configure the setting in C2A to get it to run properly. Without configuring C2A it seemed to try to move the mount at maximum possible slew speed.

Yes, that's correct. For some reason on my Windows 10 laptop, I've found that the COM port for the mount keeps changing so if you just click on 'CONNECT' it probably won't see the mount. Click on the spanner (MOUNT SETUP) first, it will find the mount, and then click 'CONNECT'.

You need to install the ASCOM driver for the SynScan hand controller from the SkyWatcher web site (https://skywatcher.com/download/software/ascom-driver/) to allow PHD2 to control the mount when the hand controller is used. You don't need to change any setting on the hand controller itself. Once the driver is installed, PHD2 will connect to your handset in the same way it connects to the guide camera. You can control the mount either using the handset or an ASCOM compatible planetarium software package (I use C2A). With regard to the connections, the SynScan control box cable plugs into the left hand RJ45 socket and the PC is connected via the USB type B socket on the right. The guide camera connects directly with the PC.

My guide scope has a fixed orientation on the mount and I align marks on the guide scope and guide camera so that the set-up is virtually identical between sessions (PHD2 is tolerant to minor misalignment).

No, I don't use the PC Direct mode (I think that it is primarily only used when updating the motor controller firmware) nor the Synscan Relay V4, Version 4.2 firmware. I have a V5 handset running firmware version V4.39.05 (although a later version V4.39.10 was released in December 2019) and all the handset settings are still set to the factory default. When I first started using the mount I tried controlling it via the guide camera ST-4 port, but I could never seem to be able to get PHD to guide correctly. The guide camera and handset now both individually connect to the PC via a USB hub and it seems to work fine.

Pin 1 is the top right pin in the photo as you correctly assume.

Once I'd loosened the declination axis I haven't had a problem using PHD2 with my EQM-35. During the calibration (which I only done the once last September), it did moan about the declination axis having too much backlash but, as the guide log below shows (from my last imaging session in April), the declination axis behaves better than the RA axis. It usually takes a few minutes from first starting up/repositioning the mount for the declination axis to settle down (so I don't think I would want to employ dithering!) The mounts periodic error and backlash correction are both turned off, and I don't use EQMOD, PHD2 drives the handset USB port.

A bit late to the party, but I've have an EQM-35 for about 9 months now. I chose it because it needs to be portable and I would personally struggle lifting and carrying anything heavier for any distance. I only use it for astrophotography with a DSLR and a 400mm lens, so the whole imaging kit including the guide scope and camera only weights about 4 kg, well within it's maximum recommended load. I use PHD2 for guiding and normally achieve less than 1 arc-sec RMS error in both axis, so my images are fine, but don't expect it straight out of the box. The declination axis had to be loosened to get it to move smoothly and the polar scope was out of alignment. Although the declination axis backlash is quite large, I haven't needed to adjust it - PHD2 seems to be able to cope with what's there.