malc-c

I would certainly be happy with a graph that was on the +/- 4 second scale... There is not a lot more to say as the other contributors have already covered things. As for the PA issues, it could simply be that the guidesope is not 100% parallel to the RA axis. But that is something you may never get, and you may end up making things worse. I've covered how I aligned my guide scope with the main camera which got me close enough to 10" alignment. At least you're getting results this time - well done

OK for now, forget about the periodic error... you need to go back to basics as I suggested. You need to take each step suggested at a time and confirm that each step works. Then focus on getting PHD2 tracking. I would even go as far as suggesting all existing profiles are deleted and you start with a fresh install of PHD2. Get the calibration right. Try and work out if the cause is an overly aggressive setting for the pulse guiding in EQMOD. Oh and please try and confirm or answer the questions we are putting to you, such as I asked for clarity on how you have the camera and mount set up, only to receive half the information... 5m passive cable is on the limit for USB, and I personally will only use 3m passive cables maximum and switch to active at 5m. The problem might be due to data drop out because of the cable. For now, try replacing the 5m cables with shorter ones whilst testing. Presumably another 5m cable is used for the camera, so the same applies. Once you prove the transmission is OK with the short ones then repeat with the longer ones to confirm that the doo indeed work. Think of this as a detective story, eliminate the suspects one by one and eventually you'll find the culprit...

Firstly, that's a nice set up. With the weight of the guidescope you might find that the balance is close, but I still feel that this may be the issue given the fact the mount seems to be stalling in the southernly direction when trying to calibrate. I'm not 100% familiar with the newer mounts that have built in USB connection on the synscan controller, but I'm assuming that it provided the same function as an EQDIR cable and allows a PC to control the mount. If so, having the handset connected as well might have some bearing. I agree with David, that the traces do appear to be aggressive overcorrections, but then I always thought that was the purpose of calibration and running the utility to track the star and work out the optimum values and backlash compensation, both of which you have done. Maybe change the RA and DEC pulse guiding rates in EQMOD to x0.2 and then see how it goes, and then increase this step by step until the corrections become too aggressive. You would need to try a calibration between each test It's not clear from the images as the cabling is not easy to follow, but it looks like you have some very long USB cables coiled up by the handset. If these are 5m passive cables then this can also lead to communication loss. Can you also confirm that you have a USB cable connected to your computer and the synscan unit, and a separate usb cable from the camera to the computer, or do they connect is some other way? Just to cover the basics - with the handset connected and the USB lead removed, set the handset to speed 9 and operate the mount in NSEW as far as you can rotate the mount in each axis , taking care when the counterweight is up and the scope down. If the mount moves OK, then disconnect the handset, connect the USB lead to the computer and launch EQMOD. set the speed step to 4 and repeat the test, if all goes well then this confirms that EQMOD can control the mount and the custom configuration entered is correct. The slew speeds should be about the same regardless of if the handset or EQMOD is used. - This means that the mount is functional and nothing is binding or slipping, or causing the motors to stall. Then its just a case of playing with the pulse guiding settings in EQMOD and PHD2. David picked up on your location, which must put Polaris low on the northern horizon. Maybe using the southern celestial pole may be better. I don't know if it has any bearing, but maybe EQMOD is expecting the mount to be facing South rather than North given your latitude ?- then again it may not...its not as if the mount is effectively in an ALT / AZ position.

Can you please post up a photo of how you have set up your scope and mount - nice wide shot of the tripod, mount and scope so we can see what you are using

It wouldn't surprise me if the counterweight bar alone weighed around the same as the scope .... But seeing what scope it is, how is the guide scope and camera fitted ????

Heck, I've just looked that up.... the scope is tiny..... and only weights 1.5kg. I think the issue you have is that you can't balance that small mass on the EQ35-M. The counterweight may be right to the top of the weight bar and it still have issue as each one weighs 3.4kg. Skywatcher do a 1.8kg weight - £42 form FLO (but out of stock)

Steve - I had a bash

I'm no expert when it comes to dissecting PHD logs, but this isn't right The axis should be at right angles to each other.... This calibration is better, but then you have all these south steps where the mount isn't moving Looking at the calibration settings it shows the "Assume orthogonal axes = no" - basically from a bit of googling this is to do with the association of the RA/DEC axis and camera axis - Reading up on this error this is what the PHD2 website has to say I think you need to possibly go back to basics and disconnect all the equipment. Check the balance and centre of gravity of the set up. Ensure the mount moves smoothly in all directions with no binding or has any backlash (if you lock the axis does the scope still move slightly). Ensure your guide scope is lined up with the same optical axis of the main scope. Point the scope at a bright star and centre it in the field of view of the main camera - have the mount tracking at sidereal rate. Then use sharpcap or similar application that may have came with the guide camera to centre the same star in the centre of the image the guide camera is seeing. Now use the directional buttons on the handset or EQMOD to move the mount north and watch the motion of the star in both cameras. If the guide scope image moves at a different angle to the main camera, then rotate the camera until the images move in the same direction, ie if the star moved directly up in the main camera image, then it should do the same in the guide scope image. Now polar align the mount. Sharpcap has an excellent utility for doing this using the guidescope or main scope if the camera has live views. - Its worth the £12 annual cost. Having confirmed that the mount has no major backlash issues, the cameras are aligned and the scope is perfectly balanced including the centre of gravity then load up just PHD2 . Connect it to the mount using ASCOM, and the camera. So now all you have running is EQMOD (ASCOM) and PHD2. Set the slew rate to 4 in EQMOD and then use the NSWE buttons to locate a suitable start, ideally on the meridian and near the celestial equator - IE south. Clear any previous profiles in PHD2, have logging enabled and enable the calibration. Hopefully you should see a nice set of steps at 90 degrees to each other and guiding will start. Let it guide for 30 - 40 minutes. If you still have issues then post up the log files again Now like I stated, I'm no expert, and certainly not in PHD2, but the above would be how I would approach the problem. Hopefully some of the more experienced imagers might jump in and offer their assistance.

But was the centre of gravity checked as shown in that video... The thing is that looking at that image, after the initial jumping around the mount was being guided at the end. - Seeing that the zig-zag traces at the start are first in DEC and then in RA it would suggest that is some part of the calibration run, or similar before PHD finally gets round to guiding.... - It may well be that you are looking at the graphs whilst it does the configuring and thinking there is an issue, when in fact there is nothing really going on? - I must admit however that I don't see that behaviour with my guiding, so maybe there is still more to this than we know. Can you describe exactly how you have the computer connected to the mount, if the ST4 cable is removed etc... just for clarification.

Sorry, I was confusing the current draw of the steppers as measured in an goto system. D cells are 1.5v, so will provide 6v. The 4.8v would be the voltage or 4 x rechargeable (NiCad / NiMH) as each cell maxes out at 1.2v - If running them at 1.2v below the suggested voltage has no effect on the tracking then that's fine

IMO the USB port will not be able to provide the current required to drive the mount, and will be a volt less that that needed. Ideally you need a 6v 3Amp power supply with a 2.1mm tip positive plug to power the mount. You might get away with using the powerpack - trial and error, but if the slewing stalls or tracking is slow then you may have to stick with using D cells or adapt a 6V motorcycle battery

Oh I totally agree... An EQ3, with simple RA Drive, and a telephoto lens and camera is an ideal start into wild field imaging... and wouldn't brake the bank. But again is a different "category" of imaging, and may be something the OP might want to add to their list of things to check out. But getting back to the OP's original post, I took this to mean either using his 130 (ignoring the spherical mirror issue), or upgrading the complete rig. And by decent planetary images, took that to mean close up images rather than wide field. I guess it might help if the OP gave us a budget and defined what it is that they are hoping to achieve in terms of end results.

This was my first attempt at M51 taken using the equipment below... can't remember the number of subs / darkes etc....

In this day and age, this is going to be difficult. To get a mount that has the precision to track well, takes a decent payload and is solid it will be goto. By that I mean it will be driven and have the ability to be controlled by a handset or computer. You don't have to use the handset / PC to slew (goto) targets, but it is required to enable tracking. Something has to send the command to the mount to start tracking and to track in sideral rate. 30 years ago you could get mounts that had motor drives that constantly drove the RA axis at sidereal rate as soon as the power was applied so you positioned the scope at the target manually and then locked the clutches and away it would go... but with the advent of cheaper components and advancement in technology that evolved into the modern goto computerised systems we see today and is now commonplace on higher end mounts ( you can't get a new HEQ5 without goto for example). However for mounts like the EQ5 there are still options to drive the scope without having the computerised goto system. such as this dual axis kit , but whilst the EQ5 is a nice mount, it may not tick the boxes for payload and stability (as previously described ). I guess we have all been there... wanting to dip a toe into the water but not wanting to waste lots of money, but equally not wanting to buy something that doesn't perform.

In that image of the camera screen it seems that all stars are elongated, but the fainter stars haven't left traces as the scope moved, which would suggest that the movement between the start of the exposure and the end may not have been linier. It's like the exposure started, tracking started, and then tracking advanced slightly at a faster rate on one axis and then resumed at the end of the exposure. The fact the fainter stars didn't register the short distance gives the impression the exposure is of double stars. I've seen similar when the backlash in the mount hasn't been taken up after a slew. Can you confirm your scope is fully balanced? In this old but useful video explains the issue of balance and CogG I'll also try and remote into the observatory PC and take some screenshots of my set up which may help

Just googled the firmware and it's version 7.17.00310 which was released a year ago in April-2020 and it was to fix a bug with a particular camera. The previous version was in July 2019. - Synta (Celestron) provide their own CFM uploader for updating firmware available here for updating firmware on mounts and handsets, so presume this is what you have tried to install the update ? To be honest, there is a risk when performing updates and unless there is a particular problem then often it's best to leave things as they are. But seeing you have an issue it may be worth doing on the advice of the retailer. However googling the issue you will see you are not alone - here's one example - so maybe worth doing some more research before attempting the update

In the 400D (and possibly the 450D) there are two IR filters If you remove both and leave the sensor open then you will have a "full spectrum" camera. The drawback is that the sensor has no protection against dust etc, which is why some will fit clear glass as a form of protection. It also means that all wavelengths are passes, including those from street lights and other sources you don't want Most guides such as this one - give you some idea of what's involved in fitting the Badder filter

It would probably require a different cable, but if you had a PC-DIRECT cable connected between the computer to the handset, with the handset in PC-Direct mode, and then the handset connected to the mount, then all you would need to do is come out of PC-Direct mode on the handset and use the handset and normal to park the scope. The PC direct cables used to be a DB9 to RJ45, so you may need a standard USB to serial convertor to replace the EQ-DIR cable

So you are thinking of using something like an RJ45 "Y"cable ????? Uhmmmm Not 100% sure it would work - you would probably end up with having serial "packet" data corrupted as both devices would see the mount and be trying to communicate at the same time. You are basically trying to parallel TX and RX serial data to two devices at the same time - don't think it would work. Why don't you use whatever driver for the scope to perform a meridian flip - I know EQMOD can be configured to force a flip at a given point, but given the hardware would assume you are not using EQMOD as the driver

I opted to fit a Badder BCF filter - as detailed here If you are careful, take your time and have a steady hand the process is quite straightforward. This is how it effects the images - The raw unprocessed image on the left, and then simple "auto levels" in Photshop to correct. Naturally for DSO's you leave the red in And then processed slightly to remove the grain and make it more appealing to my eyes

Rob, from experience getting into imaging isn't cheap. To get a mount that is stable, tracks well and is solid then you're looking at best part of a grand for an HEQ5 as the entry level. Granted there are posts where people have used EQ3 and EQ5 goto mounts, and have got some exceptional results, but the hoops they jump through to get there can make the process frustrating. Best analogy is comparing a basic 1000cc car and a 3ltr audi. Both can do 70 on the motorway, but in the Audi its' less work and the result is smooth and refined. Whilst you are not looking for goto - it really makes thing easy and if you opt for DSO's that need guiding then the precision of the HEQ5 comes into its own. Imaging on an undriven mount would be impractical. But it also depends on what imaging you want to do. You have lumped DSO's in with luna and planetary. No one scope (and certainly not the 130) will fit all. The 130 would be fine for luna imaging, either with a single shot DSLR, or CCD camera. Planetary work needs a lot of magnification and aperture. Using barlow lenses to increase focal lengths will dull the image of Mars, Jupiter and Saturn, so you might get dissatisfied with the results. You could get some decent results with a DSLR for DSO's but due to the long exposures you will need to use guiding, so this then puts you in the realms of computer control, running PHD2, EQMOD and using an EQDIR to connect the mount.... so you could find yourself the deep end, and needing deep pockets, which is why having a decent mount that works well such as the HEQ5 is worth the investment. I'm speaking from experience. I started with a 200P on an EQ5 goto. I then wanted to venture into imaging as light pollution at the time was making visual observing difficult. I connected a webcam (Philips SPC900) and used a cheap netbook to capture the Moon and then processed the result in a free stacking application. I was happy with the result, but when I tried the same on Jupiter the results was underwhelming - I stacked two barlows to increase the focal ratio to f20 and whilst the disk of Jupiter was now larger, it was very dull. It also meant the detail was poor as the camera lacked the pixel count to give a decent image. I then switched to using a canon 400D to try DSO's and soon found that I couldn't get longer than 60s exposures before tracking errors spoilt the image. It was at this time that I invested big time and upgraded to an HEQ5, with a ST80 and QLY5 guidecamera, and built a RPR observatory to house it in. Now I can be up and taking my first image in less than 15 minutes. In hindsight I wish I had opted for the HEQ5 /200P option at the start, as I ended up selling the EQ5 mount and tripod for a loss.

But surely it can be that hard for a manufacturer to mount the lased LED central and parallel to the edges of housing.... I would have thought adding the option of some form of adjustable support would be more complex than permanently fixing the diode in place. Given the simplicity of the Hotech you would have thought the pricing would have been the other way around, but then all the cheap collimators don't have the self centering mechanism, and that is where the cost may lie. Plus as others have pointed out , the quality of the laser is far better than cheaper devices, making collimation more precise. For me it's nice to have that confidence in knowing that any error shown when collimating the scope is going to be due to the misalignment of the optics and not down to misalignment or calibration of the tool I'm using. If it means paying that little bit extra then I have no issue as I know it will save me time doing the task in hand. But let's face it, astronomy is not a cheap hobby...

I can't see how you can get two stars of every star in one image (like a double exposure) as you would get trailing between the two stars suggesting the mount isn't tracking. Try this.... Power up the mount and the PC Launch your planetarium software and connect to the mount via EQMOD (don't use the toolbox - that is for setting up and testing) Select a target and slew the scope to target Check that EQMOD says tracking - if not then enable sidereal tracking Open PHD2 - Select the option to connect to the mount and camera (connect all) Click the cycling button so a star field is displayed. Click on the brain icon - there is an option to force calibration under the guiding tab - this clears any existing calibration settings - save and exit Choos a star - or use the option to have PHD2 chose its own star. Click the guide option and PHD2 should do a calibration run. Hopefully it will run through without complaining When complete the cross wires should go green and the mount should start guiding. Watch the graph, after a few minutes it should settle down and whilst the traces may not be flat they should stay within a range and follow the zero line rather then trend up or down by a large amount. Then open your imaging application - it should detect what's running and connect to your imaging camera. Take a test exposure, which for me using a DSLR is typically 120s which will show up any issue and confirm the framing. Posting up information on your planetarium software, and the images you are getting will help further diagnosis.

As others have said, they are factory collimated and they never seem to drift.... I've never seen the point in buying a collimation tool that itself needs to be collimated. If you don't set the tool up right then it won't set the scope up correctly. Can you imagine buying a bubble spirit level and being required to adjust the position of the bubble

Basically this was what I was trying to cover. From DSS website Star detection For each picture DeepSkyStacker will attempt to automatically detect the stars. In simple terms, DeepSkyStacker considers that a star is a round object whose luminance decreases regularly is every direction, and whose radius is no more than 50 pixels. Note that DeepSkyStacker will reject elongated star images which might occur if your mount isn't tracking correctly. I've underlingned the point I feel might be an issue. If the exposures are long, without tracking there could be enough elongation of the stars for DSS to reject the image and discard the image. In the past I have managed to stack images where the camera had been removed and replaced resulting in some subs being 90 degrees to others (IE like stacking portrait and landscape images of the same subject) - It worked, but that was because all images were taken with a guided EQ mount and the star shapes were nice round and the triangulation algorithms DSS uses still worked. I had to set an area in DSS that was inside the overlap for it to work, but it still means that that I didn't have to throw away a previous sessions data.