malc-c

My gut response was learn to walk before running :-) You would need the synscan goto option as a minimum. The motors in the synscan upgrade are more precise and the system permits connection to PC based software to handle target selection, tracking and camera control. Thats not to say that you couldn't connect or place a camera (even your phone's camera) at the eyepiece and take single shots of the moon with your current RA drive

If its just the basic motor drive kit and not the Synscan goto then yes. Its not a simple case of aligning the N on the tripod with North. You need to polar align the RA axis using the polar scope in the mount. Once aligned, release the clutches and move the scope to the target then lock the clutches and engage the drive. If your alignment is good then the object should stay within the field of view for visual observation.

Suggested workflow (sorry if it sounds patronising - that's not my intention) Boot the PC up in to windows. Connect the EQDIR cable - you should hear the "bing bong" signifying its been detected. Open up Device Manager, and confirm the presence of a new COM port under the "Ports (COM & LPT) section Ensure there is no warning or exclamation mark against the port that signifies it either can't be started or is missing the driver Most of the Lynx cables are FTDI based so the driver is automatically installed. If the EQDIR cable uses Prolific chip set then the driver will need to be located and installed. Assuming there are no issues or warnings, right click on the port assigned to the EQDIR cable and select properties Under the port setting tab confirm the bits per second is set to 9600. If it's any other value select 9600 from the dropdown list and then click OK Connect the EQDIR cable to the mount and power on the mount. Open up the firmware updating application, and uncheck the option to search for the com port Manually select the com port windows assigned to the EQDIR cable Click the "MC Version" button to make the application interrogate the mount If it can detect the mount then we can go one step further. Download EQMOD from here - Install it and then try the following From the windows start button navigate to All Programs > EQMOD > EQASCOM and run the toolbox utility Under the middle section called "set up" select EQMOD.EXE in the drop down, and click the "Driver Setup" button EQASCOM will now launch. To the left is a section "EQMOD port details". Where it says "port" click the drop down menu and select the port that the PC assigned to the EQDIR cable Above the port selection is "Baud". Select 9600 from the list of values in the drop down list. For now there is no need to fill in any other details, so click OK The EQASCOM window will close taking you back to the toolbox window. Click on ASCOM Connect. It will now do one of two things. It will connect to the mount and display a load of RA/DEC/ALT/AZ values which confirms the board in the mount is fine, or it will keep cycling with "Comm Error" or words to that effect which confirms the result you had with the firmware update application, and points to the control board in the mount as being defective Click ASCOM Disconnect button on the toolbox, and then close the Toolbox application. Power down the mount and disconnect the EQDIR cable from the Synscan unit If this failed to connect to the mount then this would confirm that the issue is with the SynScan board. As mentioned, if it's a new unit with a USB-B socket then it will be one of the newer SMT32 ARM based boards which I don't have the tools to remove and replace them. If is one of the older boards without a USB port then undo the screws holding the plastic housing in place and take a look at the PCB Ignore the circles in this image, but if your board has a single PIC chip, which has 16F886 written on it then this is indeed repairable, assuming its just the communications that is at fault. If so then drop me a PM (ideally with an image to confirm the board version as it may not look 100% identical to this image) and I'll give you details on how we can attempt a repair, which will be a lot less than the £130 for a brand new unit.

Makes you realise just how fast we are spinning

The weight of the 150p plus the camera, and the weights is really pushing the EQ3 to its limit. Read through any thread of similar description where people hope to get XXX scope and mount but want to image as well as visual and you'll see that the consensus is to upgrade the mount one step larger, ie a 150P / EQ3 is fine for visual, but a 150P / EQ5 is more capable as an entry level imaging rig. 200P is fine for visual on an EQ5, but again on an HEQ5 becomes a decent entry into imaging. If you really want to scope (no pun intended) for the future, then skip a mount, eg 150P on an HEQ5, 200P on an EQ6 which provides a very sturdy option. Its an old video, but this covers how to balance a scope in all three axis

Keep the thread updated. As mentioned it could be lots of reasons why the handset can't communicate with the control board. Once you have an EQDIR cable it should help identify if the issue is with the main board or handset. If you find the mount works fine with the EQDIR cable, but not with the handset (even when you've tried the alternative cable), then the choice is to either run the rig via a computer via the EQDIR cable, purchase a wifi dongle and use an app on your phone to control the mount, or replace the handset. As mentioned, I would need to confirm which version of mainboard is fitted before taking on the repair. If its PIC based (two 28 pin packages with 16F886 printed on them) then they can be replaced. If its a newer version with a USB - B type socket fitted then it will be an ARM based board which, as mentioned, I lack the tools to program and swap out the processor fitted to these newer boards.

I've cut and pasted most of the following from a reply I made to a similar thread a couple of days ago The "No Response XXX Axis" where XXX is RA / DEC or Both is because when the handset sent out the command e:1 to interrogate the control board it never received and reply. If it reported a single axis isn't responding then this would suggest that the handset, cable, and the control board is powered up correctly, and the issue is with the PIC that controls said axis, or its associated blocking diode in the serial traces. When it reports that both axis are not responding then it could be at any point in the communication path. The curly cable, the connection on the mount, both blocking diodes or both ports on the PICs. The handset tends to be fairly robust, so it is very rare for that to have a fault. The simple way to rule out external connections is to use an EQDIR cable with EQMOD or GSS running on a windows PC. If either of these two applications can't detect the mount then its pointing towards the control board in the mount, which could be anything from the RJ port where the handset plugs into or (and has been the case for the majority of the boards I've repaired) the serial ports of the two PICs being blown. One other possible cause is condensation. If the mount has been removed form a warm house to -3c outside the resulting change could cause moisture inside the mount or synscan box which again leads to the reported message if it shorts the serial connections. It's therefore worth trying again once the mount / synscan has been inside and thus at room temperature and completely dry. Unless you have been messing about with USB to serial convertors and some how shoved the wrong voltage into the board then the issue may well be juts a connection one. If the EQDIR cable works, but the handset doesn't, then try replacing the curly cable with a 2m Cat5 / Cat6 network patch cable to rule out the cable as being the issue. If the board does seem to be the cause, and if it's one that is based on the older PIC microcontrollers then all is not lost. The process of repairing the board by replacing the damaged PICs with new freshly programmed ones is covered in this thread - I can repair these boards, but if the board is one of the newer ARM based boards then regretfully I lack the tools to program and replace these processors. @LaurenceT I would suggest locating that EQDIR cable and see if the mount responds to commands from EQMOD / GSS. If this reports comms issues then it would be more likely a fault on the board, and if this is the case then drop me a PM and well look at attempting a repair.

What mount is the 8" scope sitting on...?? To me it looks like a collimation error

Well that's progress... well done

Sorry... I totally misread Dens original post, picked up on the "no response" thinking it was the message displayed on the handset. Based on the info which Den has just posted then this would seem to be a power related rather than a communications issue. The buzzing could well be a faulty H bridge chip (or chips) or possibly the buck convertor section that supplies the higher voltage (around 35v) to the H bridge drivers. The fact it still makes this sound without the handset connected suggests that the handset isn't the cause. The handset can be tested by powering the unconnected handset via a power source via either the power port jack or (if fitted) a USB - A - B cable. If the screen's back light comes on and no text such as the "No Response.." message mentioned above is displayed then this indeed would suggest that whatever it was that has caused the issue took out the handset as well.

The "No Response XXX Axis" where XXX is RA / DEC or Both is because when the handset sent out the command e:1 to interrogate the control board it never received and reply. If it reported a single axis isn't responding then this would prove that the handset, cable, and the control board is powered up correctly, and the issue is with the PIC or blocking diodes in the serial traces. When it reports that both axis are not responding then it could be at any point in the communication path. The curly cable, the connection on the mount, both blocking diodes or both ports on the PICs. The handset tends to be fairly robust, so it is very rare for that to have a fault. The simple way to rule out external connections is to use an EQDIR cable with EQMOD or GSS running on a windows PC. If either of these two applications can't detect the mount then its pointing towards the control board in the mount, which could be anything from the RJ port where the handset plugs into or (and has been the case for the majority of the boards I've repaired) the serial ports of the two PICs being blown, often due to the insertion of the wrong cable into the handset port. @Debo If you could detail how you are using the mount, visual observing using the handset, or imaging using the handset as a pass through it would help.

Den, This thread is worth a read. I'm guessing that if the mount is 8 years old that the two main microcontrollers will be PICs rather than an ARM processor that is now appearing on newer boards. If it looks like the images in Stewarts post, could you or Stewart let me know what's marked on the packages with the green dots- possibly 16F or 18F series. If the board is PIC based, and it's one that I can program with the hardware I have here then I'm willing to take a look and try and repair it for you. Can't guarantee a fix, but as you will see from that thread there is quite a good success rate.

Worth calling FLO to confirm, but I think you would be safe using that EQDIR cable with your scope. Other than the EQ6 the handset wiring should be the same for all Synscan goto mounts.

The speed setting is irrelevant. The tracking rate is set by that three position slider, so if targeting anything other than the Sun or moon it will be sidereal. The software will be watching the star's movement and will tell the camera how long the "hold the button" down in order to get the start repositioned. Basically you need a computer with USB port that can be a dedicated connection (as opposed to a hub) for the camera, the ST4 cable between the camera and the controller. Software wise, PHD2 is the go to choice. The ASCOM platform needs to be installed and some form of software to take the images with a main camera. APT is one such application. The good news is both APT and PHD2 are free.

Risky... Anything 3m and above should be an active cable to ensure signal voltage doesn't drop out

As Martin has stated we need a little more info. In addition to the points mentioned can you explain in detail how the mount is powered, and if you have access to a test meter to verify the voltage the mount is receiving. When you say HQMod are you referring to EQMOD software ?

As others have mentioned, yes this is perfectly normal. The weights should always be pointing downwards, and as Mike has show, such a move passed the meridian left the weights pointing upwards. So in these circumstances the mount "flips" from one side to the other.

As Peter mentions, you need to have a computer to run a 3rd party application to handle the tracking of a star. The guide camera is connected as Peter describes with the ST4 cable between camera and mount controller making the adjustments. It's not as simple as connecting the ST4 ports on the camera and controller and then expecting it to guide, its not that smart. The ST4 method of guiding is very basic. Unlike the Synscan system where commands are sent to the control unit, an ST4 is just wires that connect to the same inputs as the NSEW buttons on the handset and if the mount needs a small shove north, the camera closes the connection to the N wire for a short time which moves the mount a small nudge in that direction. Its like the old manual guiding system where you would watch the star on the cross hairs and make adjustments by pressing the NSEW direction buttons accordingly

Its a shame Synta went with Prolific chipsets in their equipment rather then FTDI - there would be none of this fuffing about ! Glad to hear you have had some progress in the right direction

This may or may not resolve the issue with the Prolific driver. I've attached an older driver that worked with a USB to Serial chipset under XP/ Win7 and win10 PL2303_64bit_Installer.zip

It was several years ago when I was researching this and I can't recall if the need for a thin OAG was required for the 200P before or after I swapped out the mirror for one of the same dimensions as the DS. But then again, I believe the secondary in a DS is mounted slightly closer to the primary to take advantage of the size ? Sorry I can't be much help here, memory isn't that good.

Thank you for a very detailed explanation. It's clear that the issue is software related and not a physical hardware related problem. I've not used the applications you mentioned, as for my set up EQMOD and then CDC for target selection. The fact that one application is not seeing any com ports is concerning. Irrespective if they are real or virtual com ports. You could try flushing the cache of stored (hidden) comports to see if that helps, or uninstall and re-install the applications testing functionality after each one to see which one is not releasing the port. Other than that I'm out of suggestions.

Remove the power form the mount and then remove the handset form the equation Plug in the USB cable to the mount and PC. Power up the mount and boot the PC. Check Device Manager to confirm the COM port still remains at 115200 baud. When you say "Ascom" are you referring to EQMOD or GSS? - If you don't have these installed then download and install EQMOD. Once installed open up the TOOLBOX application (from the start menu > all programms > EQMOD > EQASCOM ). In the window that opens up, under the central set up section click on the Driver Setup. A new window will appear. Left hand middle section EQMOD Port Details. Within that section you can select the port and speed. Select COM4 and set it to 115200 and click OK. The window will close, leaving the toolbox window open. Under the setup section, make sure eqmod.exe is selected, and then click ASCOM connect button. This should open EQMOD, connect to the mount and show it as parked. This confirms that the PC has connection with the mount. You can then unpark the mount, set the slew rate to 4 (dropdown between the RA and DEC sliders, and the clicking on the NSEW buttons should move the mount. Finally click on the ASCOM disconnect button and then close the Toolbox application. Now EQMOD can only be used when the mount is set in an EQ configuration. But we are only using it here to rule out both the hardware and / or the driver as being the cause of the issue. If you can connect to the mount without EQMOD constantly cycling with a time out error, then that means the hardware and drivers are fine and working correctly, and the issue is with the Synscan software I'm not familiar with this, other then messing about with a wi-fi dongle I fixed the other week and confirming the phone could connect to the dongle and the android app was happy to communicate with a mount. I've not heard of anyone trying to connect an app on the phone to a mount that is connected via USB to a PC. Both the PC and the phone would need to be on the same network, and some form of application running on the PC to relay commands between the mount and phone.

No question is stupid. Yes in order to make any movement via the fine slow motion controls, or to have software control the mount the axis have to be locked by the clamps. In fact, where a scope uses any goto feature the clamps should remain locked once the alignment has been completed. If the clutches / locks are released and the scope is free to rotate even the slightest amount, any further gotos will be off. Of course if the scope is not motorised, then targets are found by releasing the clutches / locks, manually slewing the scope until the target is centralised in the finder, then the clutches / locks are locked and final adjustments made using the hand controls

IMO yes, as it's quite surprising just how fast the Moon tracks across the field of view, especially with magnification. You could do as Vlaiv suggests, but ideally if you try and get as stable an image in the first place the better the end results, so tracking is the better option