malc-c

A "smart" socket was also thrown up in the search - with two USB ports - and in black !

details here

something like this which offers charging and network ports 

Amazon search listed a 4 port USB3 plate - but not sure if its a hub or just sockets here and best read the reviews though.

Failing that, contact any local AV media installation company as this is the sort of thing that would do on a daily basis and could point you in the right direction

The clue is in the title - EQmod is expecting the mount to be an equatorial mount.  An EQ mount set into ALT/AZ mode wont perform correctly when using EQMOD as a mount controller.  If you have to set up the mount each time you wish to use it then you need to clear all the previous saved sync points as they will be incorrect as the mount has since been moved.  

Also check if you have the DEC axis set correctly - if the dovetail is 180 degrees out then that could be another factor as to why the issue is with the DEC axis and not the RA which returns to the correct home position.

On a serious note.. part of the problem is that of the 12 useable channels, nearly everything defaults to channel 1, so there could be several devices all chatting on the same channel.  Turning off the router leaves just the wi-fi dongle as an access point so the app on the phone should connect without the need for a tin foil hat.... unless of course there is a flying saucer hovering over the house 

I set my finder / guider up so that the same subject is central in the viewpoint.  The main scope was centred on a bright star, then using sharpcap the same star was centred in the finder/guiders view.  The 9x50 scope provides enough field of view for PHD to pick a star and guide without any real issues.  Having the two scopes pointing at the same section of sky makes more logical sense to me.

Best advice would be to look at the requirements stated by the software manufactures.   These days with even entry level computers have multiple cores and threads, with16GB being the standard RAM, and both laptops and desktop system supporting Nvme drives so should be more than capable.  What tends to happen is that most software still uses older core code that isn't written to take advantage of the processing power.  In fact these days its the GPU's Cuda cores that dictates the power of a system, more so in the gaming side of things, as more and more applications can be more easily modified to use  the GPUs processor than to make it a multi core or threaded application to use the CPUs clout.

I have a first gen Ryzen 5 based machine, with 16GB DDR4 vengance RAM,  1Tb  and 250Gb Samsun Nvme drives, 2TB SSD and a 3Tb mechanical drive for archival storage.  Yet when I need to convert a small  STL file into a solid in FreeCAD it still sits there for several minutes whilst it does the math as it can't make use of the 4 cores and 8 threads all turbo'd to 3.7 Ghz !!

Mind you,  having said that Deep Sky Stacker does make use of multi core / treads and it's quite impressive watching it stack a shed load of subs on a modern day machine in a couple of minutes.  Prior to building this machine I had an old AMD FX processor based machine and it was often a case of setting the stacking off and then going off to mow the lawns or run the vacuum around the house and then still have to wait a few more minutes before it finished !!

If you want something simple that offers a wifi based controller that supports the Skywatcher protocol making a direct alternative to the synscan board have a look at the Open Synscan project  which will allow you to use any application compliant with Synscan protocol to manage the telescope mount over WIFI network connection

Why re-invent the wheel - Can't vouch for it, but here is a typical example of an open source Arduino based, standalone (use an app on your phone) goto system 

And another system, but this links to a PC

Wait, there's more 

Details here

Just google "arduino telsecope control"

Its dem dere ay-lee-uns.....  their cosmic rays can't get through tin foil hats    (sorry couldn't resist - but thanks for sharing)

It would not be possible to take the control board and steppers from an EQ5 and use them in the EQ6.  Aside from the physical differences, the firmware (the code inside the microcontrolers) has all the gear ratios etc for the mount they control, and as the two mounts use different worm  and gear ratios it would never slew to the correct place if  you did manage to replace the steppers with the correct ones (the microstepping of the motors used is also different, so you would need the correct spec motors as well).  And before you download the firmware updater application and try uploading the EQ6 firmware to the EQ5 board, it won't work, and the application will report the file is not correct for the board being updated.  You would need to reprogram the controllers directly with an edited version of the code.  One major factor is that the EQ5 synscan boards of that age use a single controller, where as the EQ6 uses two (one for each axis), with each one requiring a copy of the code burnt into them.

There are open source alternatives to the synscan units, based around Arduinos... that may be an alternative.  But using the existing controller won't work.  Oh and good luck sourcing the steppers.  The boards used in HEQ5 and EQ6 boost the 12v to around 30v to run the steppers due to the increased payloads.  Lets say for argument sake the motors physically fitted, the internal coils would not handle the increased current draw the larger mount would need, so they would run hot or possibly burn out.

Unfortunately  being skint and having an interest in telescopes is not a great combination.  A replacement EQ6 control board is circa £160.  You could ask FLO (sponsors of the forum) if replacement steppers are available, and how much they would cost, but I doubt you would get much change out of £100 for the set.  The only good news is that the synscan handset you use with the EQ5 will work with the EQ6 as the the controllers in the handset interrogate the mount to ID which mount its being used on.

I did have a few EQ6 boards that I repaired a few months ago. but these went quite quickly.  I normally offer a repair on an exchange basis, but a lot of kind SGL members who had already gone out and bought new boards kindly sent their old damaged boards to me for repair, so I had a few surplus.  If I get any more faulty ones that can be repaired I'll let you know, but don't hold your breath :-) 

Googling LX90 PC control provides a lot of information.  It seems that you can use a serial cable between the handset and a PC, with the handset connected to the mount so it relays the commands.  As most modern PCs won't have a true serial port you will need a USB to true RS232 serial adapter.  On some of the links to other forums there was suggestion of a 505 cable, which might be a propriety cable with the adapter built in.  As the cable is using standard serial it can be long enough to have the scope outside and control it from the comfort of your lounge.  However the problem you will run into is with other equipment such as cameras, which will all be USB and anything over 3m ideally requires an active cable to boost the signals.  Personally I would not advise using anything over 5m..  Most remotely operated  setups tend to keep everything local to the mount, including a computer of some kind.  Then you simply use wi-fi or a long cat5/6 cable between the two PCs and remote desktop into the PC at the scope.

8 hours ago, Zermelo said:

 

But I believe that the Star Adventurer doesn't have FreedomFind in any case.

Nothing is mentioned in the features on FLO's website.. But I did find a reverence to servo motors and encoders on one website, but it just mentioned GTi mount ?

21 minutes ago, Louis D said:

I thought the Sky Watcher Freedom Find mounts use encoders to keep track of alignment regardless of the clutches.

Some mounts are fitted with encoders, which mean drive clutches can be released and the scope manually moved without the handset loosing positioning.  However these will need calibrating from a known starting point first time used 

3 hours ago, crush said:

One of the many things that is confusing me is that if using the USB to serial through the handset (with the handset in PC mode) to update the drivers it can read and wright so is communicating.

Before the update I could control the mount using Synscan pro but not after, the only thing that should of changed was the software in the controllers so does this not point to the mount being the fault at least with this way of connecting?  

The fact that when using the USB to serial adapter to connect to the mount via the handset in PC Mode the updater application could interrogate the mount for its current firmware version which it received and displayed, and then you successfully updated the firmware would rule out the USB port on the laptop, the adapter to translate the packets into strings, the MAX232 chip in the handset to shift the RS232 to 5vTTL serial, and the EUARTs in the microcontroller(s) to read the strings and respond (with the reverse happening when the mount sends the data back).   This IMO points to the EQDIR cable as being the most likely culprit, and hopefully FLO will be able confirm that.

As you have established communications via the handset, I'm guessing if you open up EQMOD or repeat the TOOLBOX option described above and select the com port for the USB to Serial adapter the mount can be controlled by clicking on the NSWE buttons.  If so then again, this rules out all those components mentioned and points to the EQDIR cable once more.  If the laptop had faulty USB ports then anything else like mice / memory sticks or cameras would also no work and you've not mentioned anything to suggest that's the case.

I've not used Synscan Pro, so can't comment if this has any part in the issue.  I'm old school and have used an home made EQDIR (FTDI cable ) cable, EQMOD and CdC to control my HEQ5 for the past 12 years... I've noticed that the manual says it needs full permissions to the folders and the server service it starts can cause the windows firewall to prevent communications of the synscan pro app talking to the mount, maybe the settings within the application need checking and resetting ??

Excellent detailed reply.

The fact that when using the usb/serial adapter, serial cable to handset and with the handset connected to the mount was able to successfully communicate to the mount and update the firmware confirms the the motorbord is perfectly fine and there is nothing damaged inside the microcontrollers. 

This points to either the EQDIR cable as being faulty, or something strange is happening software wise.  There is a way to test the EQDIR cable, but you would need to be careful when doing this and I accept no responsibility should things do tits up.  It won't affect your mount, but could damage the chip in the cable.

Search and download Termite serial monitor here and then short together pins 5 and 6 on the RJ45 plug or pins 9 and 6 if the mount has a D9 serial connector.  Plug the EQDIR cable into the computer and launch Termite.  Under the settings point to the comm port allocated and set it to 9600 baud.  When connected click "clear" so nothing should be displayed in the main window.  In the bottom window, type in anything from the keyboard and hit send.  The main window should display those characters in blue and then it should echo back straight underneath in green.

If you don't get the echo back then this suggests that the FTDI chip is faulty and should be returned for replacement.  The chip could be running and provides windows with the descriptor and the USB side is fully functional, but the TTL serial side is not functioning by either not sending the string, or sends it but the RX side is faulty and doesn't read and relay it.

The alternative is to try a different laptop / computer with the EQDIR cable and mount to see if that works - if it does then the issue is with the original PC (again, assuming these are direct connections and not via any hubs etc.  If the above test works then it proves the EQDIR cable is working fine and the issue has to be with the laptop/PC.  The fact the cached ports have been cleared would suggest that its not an allocation issue.

The alternative is to just purchase a wifi dongle as suggested and see if connecting to it from your phone / or from a laptop.  I have a strong feeling that will work, but then you will never know if the issue is with the EQDIR cable, or if it is with the USB controllers on the computer, what other issues you may encounter when connecting a USB device. 

What a fantastic reply...  so well structured and full of detail 

This is pointing towards the PC as being the cause, either hardware or more probable, software.  If you can run the firmware updater application and it can see and communicate with the mount (sends the e:1 and e:2 commands to the mount which makes the mount respond with the firmware version as two strings of numbers), so communications are OK.   You could try removing the serial cable/adapter and have just the EQDIR cable installed and see if the firmware updater application gets the same response, which again will confirm the hardware is fine.

Open Device Manager and under the "view" action at the top menu enable the option to show hidden devices.  Open up Ports (COM & LPT) and you will see all the com port assignments greyed out. Right click all the entries and select uninstall device (unless your computer has a physical D9 pin serial port you should be able to remove them all).  Now this will mean any ports for cameras etc will also be removed.  with all other devices unplugged plug the FTDI EQDIR cable into the mount, and into a USB port and power up the mount.  Windows should detect the EQDIR cable, install the driver and allocate the first available com port.  You can check the properties to confirm its set to 9600 baud.

If you have EQMOD installed as the means of mount control, then open up the Toolbox application from the EQMOD folder.  Under the set up section, select eqmod.exe in the dropdown list, and click driver setup.  In the ASCOM set up  select the port and speed and then hit OK.  Once back at the Toolbox click on ASCOM Connect and this should launch EQMOD and connect to the mount.  Hopefully by setting the slew rate to 4 and click and hold the NSEW buttons the mount will move.  If it cant establish a connection it will close and try again, close and try again in a loop.  

See how that goes for now

Does your mount suffer from any of the issues that the new firmware addresses ?   Unless the mount isn't performing as it should then there is no real need to update the firmware.

Glad to hear you resolved the issue - the binary file is uploaded via the PC application as you found out. 

There is always a trade off... Increase the magnification and the brightness, and thus resolution is reduced.  The way to overcome that is aperture.  Unfortunately unlike a camera's lens we are stuck with whatever the fixed aperture of the telescope being used.  When you see those lovely images of Jupiter, with high detail in the cloud bands and swirls around the red spot are often taken through long focal length telescopes of 12, 14 or more inches in diameter.  The problem comes when people expect to see the same visually and often through a scope of small aperture.

The scope is supplied with  10mm and 25mm eyepieces and no barlow.  This is probably as the 65x magnification is the highest practical magnification for that scope.  Add in a barlow, or eyepieces in single digit magnification and the resulting images are dull and hard to focus as the sweet spot with short focal lengths eyepieces are quite small.   Factor in the turbulent atmosphere, and you may never be able to achieve focus with a 3 or 5mm eyepeice.  

If the mount works perfectly with the handset, then no damage has been done to the controllers on the mount PCB.

As Geoff has mentioned, unless you are experiencing a particular issue that an updated firmware addresses then it's best to leave things as they are.  The problem you seem to be experiencing is a lack of communications when using an EQDIR cable directly between the mount and the PC, or when using the serial cable between the handset and PC, presumably via an USB to RS232 serial adapter. Please do not try and insert the RJ11 plug of the serial cable into the handset port on the mount... that will blow the controllers !

Without communication between the PC and mount it's going to be hard to re-flash the older firmware unless you are able to locate a cashed copy of the Skywatcher website, or already have older firmware binary files.  Even then, unless you can establish comms between the PC and mount the updater application won't work.

If the mount has a USB type B port then it uses the newer ARM based board which has a prolific 2303 chipset on board.  The driver for this chipset needs to be downloaded as it's not included with windows.  The resulting virtual com port needs to be set to 115200 baud (all other settings left as default).  If there is no USB port, and you are using an EQDIR cable,  then there is no need to change form the default 9600 baud speed.  Depending on the chipset used, the drivers may get automatically installed when the cable is connected to the PC.

The HEQ5 will run fine on 14v DC.   You could connect any other device to the same power supply provided there is no risk of reverse polarity.  You could use a suitably rated diode to give some protection against reverse polarity, but as the HEQ5 motor board has a power diode across the input, which offers some protection, but if that blows the board wont function (it's like they use the diode as a sacrificial fuse).  Naturally the higher the current draw the less time the batteries will last.

My gut feeling is that if the load is increasing to twice what it should be then the first thing I would look at is if there is any binding in the mount to increase the load on the motors.  The next area would be to check for condensation inside the mount where the motor boards is.  If dampness is providing a path between contacts then a partial short circuit could be increasing the current draw.   It does amuse me that when companies perform all these tuning services, they don't conformal coat the motorboard (s) to prevent moisture / dampness causing issues, especially if the mount is to be used in an observatory. 

8 hours ago, GTom said:

The Ugreen USB to serial cable might be a good, though a bit pricier solution: https://www.amazon.co.uk/UGREEN-20210-Converter-Connecting-Controller-grey/product-reviews/B00QUZY4UG/ref=cm_cr_arp_d_viewopt_kywd?ie=UTF8&reviewerType=all_reviews&pageNumber=1&filterByKeyword=guiding

The one thing missing from the review is the model of Skywatcher scope.  The ONLY mount that has a DB9 connector for the handset is the older EQ6.  In theory this cable could be used between the EQ6 and a USB port on a PC.  For all other mounts that uses an RJ11 plug for handset connections an EQDIR cable or the wi-fi/BT dongles would be the ideal way forward.

The device on Amazon uses the Prolific 2303 chipset, and in the past Prolific drivers can be problematical.  They are not part of windows installations by default and need to be sourced form the manufactures website

6 hours ago, GTom said:

Phew, was definitely worth to ask😅, thank you. I have updated the firmware of my old EQ3-2 in the past using a usb to serial cable connected to Skywatcher's RJ45 cable, obviously that one didn't push all the 24V on the handset :D. But I'll check thoroughly if I use that cable again. Besides the EQdir, I'll take a look how reliable the wireless solutions are. One cable is better than two, but no cables should be the best - IF...

The handset has a MAX232 chip inside which is designed to work at standard serial spec.  Most Skywatcher goto mounts came with a long D9 to JR11 grey cable which can connect direct to a PC serial port and handset to update the firmware if required, or, when placed in PC-DIRECT mode act as a pass through to allow PC control of the mount.  The MAX232 chip takes the +/- 12v serial signals and converts them to TTL serial (5v) before passing them on to the Microcontrollers EUART port.  If this cable was detached and inserted where the curly handset cable is normally connected, the 24v levels get connected directly to the boards controllers and the next time you connect the handset you get the "No response both axis" message.

Most of the branded (Skywatcher) wifi or bluetooth adaptors will work if you didn't want to use an EQDIR cable.  These often through up other issues, which tend to mainly be related to software / driver or access point connectivity issues.  Use the search option to read through posts on wifi connectivity issues to help make you decide what method suits you.

12 hours ago, GTom said:

 I was wondering can I just grab ANY decent RJ45 to RS232 modem cable to operate and guide the mount from the laptop? Saving a usb to serial converter from the equation I suspect that a direct serial connection could be faster and more reliable.

NOOO !!  - you'll blow your motor board in the mount.  The mount operates at 5V TTL levels, the serial port on your laptop will be running at true RS232 levels which will have a potential of 24 volts !!

If the laptop lacks any USB ports (which I doubt) then use a Serial to USB adaptor and get a proper EQDIR cable here

On 08/03/2024 at 15:46, TiffsAndAstro said:

Also I've noticed that before polar alignment I set my lat bolts so the mount dial shows 52.3 (ish), but if I check it  after polar alignment it's about 1.5(ish) degrees higher.

 

Does this suggest tripod issues  or maybe the mount dial is only roughly accurate? Or something else?

I did notice the dial pointer isnt quite perpendicular to the scale itself.

You have to understand that these are mass produced commercial telescopes and as such lack precision.  The scales and indicators are to get you close within the limits of the design (thickness of the lines on the dial, or indicator).

If you want absolute precise PA then plate solving is the only way to eliminate any errors and get the mount aligned to the best of its abilities.  Again, it's horses for courses, you will get more accuracy with more expensive mounts as they are produced to a higher degree of precision and tighter tolerances.

Looking at your nebula image, its a bit difficult to see given the 1200 x 800 resolution, but it seems the slight "unroundness" seems to be in one direction, which could quite simply be the fact that Alignment is good, but the tracking is struggling.  This could be a multitude of reasons, from the scope not being balanced correctly, or balanced to well without any bias to remove backlash in the gearing. We've certainly seen far worse first attempts so don't be too downhearted.

One thing to remember is you don't need to expose for long periods to get data.  Sometimes it's easier to take 100 x 10, 15 or 20 second exposures and then stack them and let the post processing do the work to bring out the details, than to try and take 50 x 1 or 2 minute exposures that end up spoilt by tracking or alignment issues.