symmetal

You'll need to change the Com 3 serial speed in the COM3 entry in Device Manager\Ports as well as in Eqmod COM3 settings to be the same 115200 baud or they won't communicate with each other. Alan

I wasn't aware of the PHD2 PPEC and will give it a try next time. It sounds useful. The Eqmod PEC once recorded is applied continuously from then on while tracking. This requires the PEC corrections to always know the current phase of the worm gear cycle. If these get out of step by the mount getting knocked or manually slewing with the mount off, the PEC corrections then get applied in the wrong place making things worse. This happened to me a couple of times and having to record the PEC again is a pain. There was no way of knowing if the PEC was in or out of phase so I never bothered with it again. This was a few years ago. Whether it is better now and can keep itself in step better I don't know. The PHD2 PPEC looks promising as it's reset for each new target. After learning the PEC corrections over 2 cycles (while imaging so no time lost) it is applied only while imaging that target. It also handles dither OK. If you then slew to another target, it starts the PPEC learning process over again so it doesn't need to keep track of the phase of the worm cycle so won't get out of step. You can therefore use both PEC corrections together as almcl says, as the PHD2 PPEC will just correct for the errors left over after applying the Eqmod PEC. Alan

If you're guiding there isn't much to gain using PEC. I tried it with mine when I first started, assuming the guiding corrections needed would be less and so lead to better guiding. But in reality there was no noticeable difference in the guiding. It's also easy to get your PEC corrections out of sync with the mount worm position unless you're very careful in setting the mount position when it's turned off and on. Alan

Sorry John, rather than just East or West I meant to say the line that passes from East to West through the CP. I was mixing my Equitorial/Azimuth grids. Alan

Happy to help Robin. Just a pity it looks like it'll have to go back to SX. The Mini USB connector is not very robust as the plugs don't seat fully in, and there isn't much holding them there. The smaller micro USB connector is better in that respect. Alan

The Mount USB port is used for normal Ascom communication apparantly. This quote from the CN forum linked above seems to be how to get it to work. There doesn't seem to any manual or instructions that references the USB connector. Alan

I assume themount USB socket connects to a EQDirect module internally rather than having it built in to the cable like other mounts. Alan

I'm surprised you had a USB to RJ12 cable but the RJ12 autoguider outputs are opto isolated pull down outputs so wouldn't mean much to the hub. A resistance change on a data line might make the hub think somethings connected and beep but that's all. Alan

As you've tried another cable (and a third) it points to a broken lodestar. Not good. If it's out of warrenty I would remove the back plate and inspect around the connector solder joints if they're easily accessable. Alan

I just connected my lodestar to a USB charger only output and the light comes on so it's purely a power indicator. Alan

I'm pretty sure the light is just power indication and not communication. Have you tried gently waggling the USB connector on the rear of the lodestar to see if the light lights at some point. This would point to a broken USB solder connection on the camera rear. Alan

This lengthy topic on the CN forum may help. It looks like it's 115200 baud, though there are others issues too. Alan

Kevin, Yours looks correct, being in the 'Ports' section. The USB type COM ports aren't 'real' COM ports as such, but simulate COM ports to any device that expects to see one. Just to confirm that the COM4 in your screenshot listing is your mount, just unplug and replug it and it should disappear and come back. Does the USB mount possibly not use the default 9600 baud rate. You may need to change it in Eqmod to match or change the COM port speed in the device manager 'Properties\Port Settings' to 9600. Also check it's listed as 8 data bits, no parity, 1 stop bit, flow control none. Alan

Just tried with my Lodestar and it appears on its own under 'USB devices' as 'Starlight Xpress CCD'. USB devices should be the section below 'USB Controllers'. The Atik One I have appears under 'USB Controllers' You haven't a section called 'Unknown devices' or something similar it may have got listed under. You'll have to delete this entry and try again to get it to recognise the camera. Hopefully. Alan

Another way to confirm that the RA in the Home position is actually pointing East/West, is if you unpark and slew to an object in the East or West. The counterweight bar doesn't move. It just slews in Dec. In the Northern Hemisphere my home position RA reports it as facing West. From your first post it appears it faces East in the Southern Hemisphere. Alan

Does it appear in device manager in the Ports section as a com port, or just the USB section. Eqmod will only see it if it appears to replicate a 'real' COM port. Alan

Try another cable. Unplugging the previous one may have been its last straw. Also check in device manager that the lodestar has not got flagged with an exclamation mark if a dodgy cable caused a installation problem when you swapped ports. Alan

Phew! Glad you got it sorted out John D. I admit I'd glossed over the fact you were using AStroEQ and that the basic mount parameters are therefore unknown to EqAscom/Eqmod and need to be initially set. At least you've learned a bit about Home positions now that you wouldn't have been aware of, if everything had worked first time. Alan

The first star you sync on shouldn't be 6 hours wrong. It's only the home position which reports this 6 hour difference as the home position has the counterweight bar in the wrong position when viewing on the meridian. As soon as you do your first goto from park Eqmod should automatically correct this 6hr RA 'difference'. As I mentioned above if you goto an object on the meridian from park the scope rotates RA by 90 degrees (6 hours) automatically to make the RA correct. If you goto an object which isn't on the meridian it will automatically rotate RA the correct amount from park (between 0 and 90 degrees as required) to report the correct RA on the target. As you have a permenant setup with good PA your first goto should put the object fairly well centred in the eyepiece if you use a modest focal length eyepiece to start with. Centering the object and syncing should be all you need to do. On your previous post you were slewing manually but that shouldn't make any difference to the Eqmod readout. For a first test just slew to a target that's close to the meridian but away from the Celestial Pole and you should find your counterweight bar is now near horizontal and the RA reads correct. I shouldn't worry too much about the Side of Pier settings. It's terminiology is confusing. The first line of the Ascom Standards Side of Pier states I believe with the latest EQAscom, the Side of Pier is best left set to 'Pointing'. Alan

In the standard Home position, weights down facing North (or South in the Southern Hemisphere) and just powered up with no sync alignment points set, the Eqmod RA reading will be 6 hours out from the RA of the Meridian and the Dec reads 90 degrees. This is because whenever it is unparked and the scope slews to point to an object on the Meridian the counterweight bar is always horizontal. The Eqmod RA then reads correct. If you unpark and slew to a point on the meridian very close to the celestial pole the scope just rotates 90 degrees in RA until the bar is horizontal. In reality, in your home position the scope will not be pointing exactly at the CP. Eqmod assumes it is when it's powered up first time and uses this to work out where to go on your first Goto. When you centre the target and issue a 'Sync' command the pointing model will note the error from your first Goto. Other Sync commands from different Gotos will add more points to this pointing model to help counteract the fact that your mount may not be perfectly polar aligned. If it is perfectly aligned then only one Sync command after your first Goto is necessary. When you then 'Park' the scope it returns to its home position. Because of your 'Sync' modified, and therefore more accurate pointing model, the physical home position is not pointing exactly at the CP, and Eqmod will report where it now believes it's pointing so the Dec probably reads around 89 degrees or so. The RA now reported will be 6 Hrs different from the RA Eqmod believes it's pointing to, which can be any RA value between 0 and 24 hours depending in which direction your scope home position in reality deviates from actually pointing to the CP. The closer the Home position is to actually pointing to the CP, the more 'random' this Home RA reading will appear to be. This RA reading however does tell Eqmod (along with the Dec reading) in which direction the Home position is off from actually pointing to the CP and uses it for future Gotos to make them more accurate. The physical pointing 'accuracy' of the Home position isn't important, as you can tell Eqmod that pointing to anywhere in the sky is the 'Home' position and it will use that for the first Goto. The more inaccurate your 'standard' Home position is from actually pointing to the CP just means the first Goto will be further away from the target. Centreing the target and 'Syncing' will then correct this Home position error. There is nothing 'special' astronomically speaking about the standard Home position. It's just a safe position to leave the scope. You can easily remove the scope without worrying that the counterweights might inadvertantly swing around under gravity and cause damage or injury. If you delete the alignment points then the 'standard' Home position is again assumed to be pointing at the CP and the Dec again reads 90 and the RA is 6 hrs from the Meridian. Alan

Great image Adam. Didn't realise how close the Ghost is to the Iris. I also tried the Ghost after seeing an image posted here, (same one as you I expect ) and took 600s RG and B images (10 of each to start with). There was little to no colour in the Ghost and it was very noisy, so I didn't add any more. I should have added some luminance, so may have another go in the future. Alan

Here's a video by Tony Hallas describing the colour mottlle effect when using DSLRs and agressive dithering is the best way to combat it. As Wim says at least 12 pixels is recommended. Alan

Both results are the same, just expressed in different units. 44.2378 N is in decimal degrees and is the same as 44 degrees 14minutes, 16 seconds N. Likewise 0.9689 W is the same as 0 degrees, 58 minutes, 8 seconds W Astro equipment usually use the deg, min, sec system so the synscan app reading is the one you want to use directly. If you want to use the Google Earth decimal reading you'll need to convert it first. Here's an online calculator to do the conversion with an explanation. Alan

I wouldn't worry too much that it doesn't read 90 when you park after gotos and syncing. When you use goto to go from one position to another the scope may need to reverse direction in RA and/or DEC and so the mount movement may have to take up the backlash in some cases and not in others leading to the object not being centred each time. As long as it doesn't seem to get worse the more gotos you make as it did in your first post is what you want to achieve. It doesn't actually issue a sync in the home position as that's the worst place in the sky to sync on. The RA can be anything you like and it's still correct so is meaningless. The Dec should still be at 90 but due to the backlash errors encountered during the gotos this may not be the case. There are backlash adjustment settings you can make in Eqmod which may improve the centreing of objects but I've not tried using them. I use automatic centreing using platesolving so the backlash errors are automatically corrected. Alan

Under Alignment/Sync section change the User Interface from Append on Sync to Dialog Based. With Append on Sync you can end up with many Sync points close together which upsets the pointing model and gotos. Dialog Based will effectively replace an old sync point point close to your position with a new one. Also delete the alignment sync points from time to time to start afresh. (Buttons just above the User Interface selection) I find after a while the home position does report itself at 89 degrees or so though its physical position doesn't seem to have changed. Deleting the alignment point data clears these errors. Alan