malc-c

With that handset all you need is a USB A to B cable to connect it to the PC. You then place the handset into PC-DIRECT mode with the handset still connected to the mount via the 8 way cable as shown. The handset will show up as a com port in windows Device Manager. Open the properties and set the speed from the default 9600 to 115,000. You should then be able to install ASCOM and EQMOD and control the mount from the computer. If you don't want to use the handset, than an EQDIR cable will need to be purchased (FLO / RVO and many other retailers stock them) to bypass the handset.

If you read through any similar posts you will get some conflicting opinions as to what would suit. Having started with an EQ5 and then found it wasn't up to the job with the scope I opted for and then moved up to an HEQ5 I would strongly recommend it. It's borderline grab and go... you wouldn't want to trek far with that over your shoulder, but it is still transportable. It has excellent tracking abilities for the class of mount, and I would recommend either getting the belt drive upgrade or buying one with it already fitted. With any imaging rig the mount is more important than the rig it carries. It's no good having the best camera / lens or camera and scope if the mount isn't stable. The HEQ5 is rock solid. Mine is housed in an observatory, manages an explorer 200P with a finder/guider scope and a canon D400 DSLR... I did have an ST80 guidescope, but that combo was really pushing the load capacity and stability to its limit, but still gave decent images as being inside the observatory it was fairly shielded from the wind. For imaging, go computer controlled. Use an EQDIR lead, EQMOD, and for £12 get shapcap which has an excellent and easy Polar Alignment tool. There are stacks of free planetarium software and imaging applications that support anything form webcams, DSLRs, through to SBIG cameras.... It's also worth getting some nice 8 x 40 or 10 x 50 binoculars.... so that you can sit back and look at the sky whilst the computer is running an imagine session as there is little or no input from the user once its running

Here's an old video (2013) on updating the firmware, when the chap enters the menu, utilities , firmware version his screen (presumably v4) us displayed in a totally different format I did find a similar image to yours on steves-astro.com (forum won't let me link the image for some reason) http://www.steves-astro.com/images/ns8gps/ but no indication as to what version that is.

Can you not power it up and see what version firmware it is running (might even tell you what model of handset it is)

It would seem the SW website really needs to make things clear, plus I can see one real issue for HEQ5 owners who have replaced their main boards. If you requested a replacement motor board for an HEQ5, it comes as an MC020 board with an ARM processor. But the the only listing for firmware on the SW website is for the old 2.04 version from 2018, which works on the PIC 16F886. - AFAIK that won't work ! The other confusion is for the EQ3 / EQ5 owneres. There s firmware (2.04) for EQ3 / EQ5 goto mounts, which states underneath that its "For EQ3, EQ5 Pro GOTO mounts". Yet the next firmware down is for EQ3 / EQ5 Pro- Goto mounts (2.07) states "Universal motor controller firmware for Skywatcher EQ3, EQ5 GOTO mounts." - Confusing ! At least they make things clearer for the new ARM based versions in the 3.09 firmware "This is the motor controller firmware for EQ3, EQ5, EQM35 mounts. It is for the version 3.xx motor controller which has an on board USB port."

Joe, I concur with everything you say, but I would it may well be that at the moment the processor has had a lot of those advantages throttled back. The handsets still transmit the protocol as serial at 9600 baud, so can't take advantage of any USB ports the ARM has, it will still need a bog standard serial UART. Now on mounts that have wi-fi there may be an advantage, but for direct connection nothing much is gained on a hardware front. One thing for sure, I predict a hike in the cost of mounts / or spare boards with these ARM processors on. Given the global silicon shortage, these ARM processors price have risen 10 fold in the past three months, from just under $4 to $33 each ! But as you say, more than one manufacture, so easier to source alternatives.

I think the main reason behind this is that a lot of the new scopes are using a new revision motor board that is based around an ARM microprocessor, where as older boards were PIC microcontroller based hence the MCU support (2). As these new boards use a totally different processor and platform, the firmware has had to be ported as a new version. What advantages migrating to ARM cortex processors over PICs has I have no idea.

If you use the search function and type in "collimation" you'll came across 100s of posts on how to collimate a newt. It's probably in the top 5 of frequently asked questions so there is a lot of coverage, including tools such as self centring adapters and laser

Glad to hear you've found a resolution. I've dropped you a PM regarding the old board.

No. I was referring to the daytime testing. If the scope is a permeant set up then just pull out the USB end of the cable out of the laptop. You can leave the other end as a fixed connection

I've found the old website archive with the images, however due to the timespan I can't edit the posts, so I've added them to a PDF with the page and image reference so you (or anyone else reading the thread) can cross reference them Images.pdf

Google "updating firmware on celestron telescope" - plenty of post and videos

Are you trying to connect the mount to a PC? - if so I would contact a suitable retailer such as FLO and ask if there is one that is suitable. A lot of scopes use standard connectors, but they don't wire them in the recognised standard so you can end up doing damage by using standard adaptors

No, The handset connect to the mount via a suitable cable that would have came with the mount - the manuals can be found Here

Seems runaways are a common thing with this mount. From memory (therefore I could be wrong) the mount uses servo motors rather than stepper motors so rely on encoders to provide feedback on the axis position, so it's more likely to be the motor board that is at fault rather than the motor itself. Replacement boards are available, but not cheap at around £180 Example here I've fixed a few Skywatcher board that had blown PICs on them, but the issues there was with communications not motor control. You could try flashing the firmware using the Celestron firmware manager application and see if that resolves the issue.

From the goto kit manual Pretty much standard plug configuration. The manual doesn't state the current draw - but form my experience the EQ5 drew around 1.9amps when slewing both motors without a scope attached, so 3amps would be the minimum IMO. The one RVO recommend is rated at 5 amps (60 watts)

You may find that windows installs the built in FTDI driver automatically, but sometimes it's worth having a backup option. Trial runs in daytime is the idea. Place the mount in the correct default home position, pointing north. Connect the EQDIR cable to the mount and power on the mount. Plug the USB cable into the laptop and windows should detect the new hardware and will possibly install the built in driver. If not then run the installer for the downloaded driver. Open up Device Manager and under ports make a note of the new com port number assigned. Double click it and select properties and it should be defaulted to a Baud rate of 9600, if not set it to 9600. Download ASCOM platform from here and install it on the laptop. Then download EQMOD and install Once installed, under the Start > All programs > EQMOD > EQASCOM run the toolbox program. This allows you to set up the parameters for EQMOD to use. In the middle section, select EQASCM from the drop box and then click the driver setup button. Under mount type select SyntaEQ if the mount is branded Skywatcher / Orion. Enter the com port details for the EQDIR cable and set the Baud rate to match the comports 9600 setting. In the site info box enter the location details and save it (or if you have a GPS device click the GPS button to read the data in). Lastly under Ascom options ensure the top three boxes are checked. Click OK to close that window. Now click the TEST CONNECT button.. If the com port info is correct this will launch EQMOD and talk to the mount. Next to the NSEW buttons is a speed setting - set this to 4 and then click and hold the NSEW buttons and the mount should move. You can then go on to install your planetarium program of choice and when that is set up with the same location info and connected to the mount via EQMOD you should be able to select a target (the sun for example) and it should slew to the position where, if fitted, the scope would be pointed at. One word of caution, when braking down after any session, power the mount down first before disconnecting the EQDIR cable from the mount. It shouldn't really matter, but the motor boards in these scopes seem quite sensitive. Apologies if you already knew this... but it may be useful to others who come across this thread and are not so familiar with the process.

Thanks you. Yes sorry some of the images are missing. They were hosted on my own website which is no longer live. The observatory is still used, and it's nice that when the whim takes me I can be up and imaging in minutes. In hindsight I would have done a few things differently, like increasing the fall on the warm room roof as I've had some puddling and water ingress recently, but this is now a decade since it was built so can't really grumble. I also tend to remote into the scope, so the warm room is now a small workshop, and store. Remoting in to the observatory PC also means no need for the microwave to warm up the pies at 2am in November

But that's a contradiction of terms. How can something be correct and be incorrect at the same time ??? I guess what you did was having made the changes and saved them you needed to power cycle the handset in order to register the changes ?

This has to go down as being one of the longest thread title for some time Nice images for a first attempt. If you are using the camera body attached to the focuser then there isn't much you can set on the 400d other than shutter speed and white balance. Set the white balance to daylight, and then it's just a case of stepping through the exposure until you get an image that suits you.

What scope and what mount are we talking about ? If you search for similar topics on the forum you'll see that a lot of these errors are caused by entering the incorrect date / time and location, or more correctly as the late Eric Morecombe would say, "all the right notes, but not necessarily in the right order". These handsets require information in US date format. Some users will set GMT time, and than say yes to daylight saving, whilst others set the BST and say no to daylight saving. Synta (manufacture of SW and Celestron scopes) handsets don't store mount information. When the handset is connected it interrogates the mount to obtain details from the mounts firmware which incudes the number of steps (or click on an encoder depending on the mount) it takes to rotate each axis 360 degrees. It then uses this information to work out the steps per degree for both axis. Once you have set the alignment up by selecting a target, slewing to it and then having made any corrections using the directional buttons then confirmed its centred in the eyepiece. When you then select the next target the handset then works out how many pulses it needs to send to the mount to move to the target based on how many degrees of rotation is required between its current target and the new target. It sends that to the mounts firmware which then drives the motor the number of pulses / ticks. Once the firmware has completed that movement it sends a command back to the handset to acknowledge the move is complete. Now if the target is way off, it would suggest that either the clutch is slipping and thus the mount is not moving far enough, or the handset has been programmed with the wrong data initially and thus it's miscalculated the required number of steps which would be too many or too few depending on the location and time it thinks you are in.

Peter, It's such an open ended question, and can be dependent on what equipment you want to use , presumably a laptop, but other hardware is available. Also, if you are thinking of using Windows or Linux as some software is more suited to one platform than another. On the assumption that you are using a windows based laptop, then EQMOD or GSS will be the application to handle communications between the laptop and mount. If you are using the wi-fi option built into the mount, then you'll need to install SW application to allow the laptop wi-fi to make an ad hock connection. The alternative would be to use a hard wired connection via an EQDIR cable. ASCOM or INDI, depending on your operating system would also need to be installed. Then you can install a planetarium application of your choice. Each will allow you to select a target and through EQMOD / GSS server have the telescope slew to it. That plus sharpcap should be enough to get you started

You'll need the VCP (Virtual com port) driver https://ftdichip.com/drivers/vcp-drivers/ chose the 32bit or 64bit (probably the latter if the laptop is new)

Most laptop power supplies are 19v - that could damage the mount, so check the label on the supply. You will need something that is capable of providing 12v at around 3 amps. such as this

I think that a lot of people get confused over what EQMOD is/does because its often called a "driver". Hopefully the following will help Craig grasp how this all goes together, and assumes the laptop is running Windows. To connect the telescope to the laptop you need an EQDIR cable. This is basically a standard USB to TTL Serial cable, but with the wiring changed to suit the connections at the mount. These EQDIR cables require a driver installed to handle the communications through the chipset used, which these days is typically FTDI. A suitable EQDIR cable and a link to the driver have been listed above. You then need to install the ASCOM platform on the laptop. ASCOM is basically a standard that equipment manufactures, and software developers have adapted so that applications can communicate between themselves and with the hardware that is connected, such as cameras, filter wheels and the telescope itself. EQMOD is an ASCOM compliant application that handles the movement and positioning. EQMOD doesn't require any driver itself, you set the application to use the serial port that the computer allocates to the EQDIR cable. EQMOD then sends and receives instructions and feedback in the form of commands that the motor controller understands. The most basic form of control from a laptop is to use a planetarium application. This makes controlling the telescopes position as simple as right clicking on an object in the application and selecting "slew to target". The planetarium application sends the positional data to EQMOD as the two are connected via the ASCOM platform. EQMOD then sends the instructions to the mount using the SW command protocol. Now NINA and other applications also contain a database of objects and can also send the same positioning data to EQMOD, but most people will use a planetarium application as they can easily see what targets are visible and all show where the telescope is pointing, so it makes life easier. So now you have the ability to select targets and make the scope slew to them and track them. That leaves an application to capture the images, and one to ensure the target is tracked correctly. PHD (and later PHD2) has been the preferred application people use. It uses the ASCOM platform to communicate with EQMOD and the ASCOM compliant driver for the camera on the guidescope. Then you have the application to take the images with the main camera. This too will use the ASCOM platform to share data between other applications and the drivers for the camera or application that communicates with the camera hardware. So in theory you could have four or five applications running, all taking to each other. Or you could do away with the planetarium application and use the database in NINA, or APT etc. Sometimes applications develop over time and incorporate functions that were found in other applications. For example APT started as a simple application to allow Canon DSLR cameras to be controlled form the PC to automate the process of taking multiple images. Now it has telescope control, plate solving, focusing aids, and a host of other functions. Apologies if this post was long winded and went over stuff you already know.... but it might also help others who are daunted by what's involved in setting up an imaging rig