malc-c

I installed the latest version last night and all I got was pop up stating "not supported" when I tried to connect to EQASCOM, or set up an INDI service under windows. If I follow this correctly, I need a Pi or a PC running Linux with INDI installed as a server. Then on the Windows PC with the Windows version of KStars installed I have to RDC into the Pi for it to do all the work and then send data back to the PC. IF that is the case then it's hardly an ideal solution. Does anyone know why the developers wrote / ported an application to run natively on a Windows platform, but not use the recognised ASCOM standard that was developed to do the same job INDI does on a Linux machine. I remember raising this point when KStars was in its infancy, and it was suggested that it was just a matter of time... but here we are years later and nothing has changed. IMO if a developer writes an application for one OS or another, then that program should work out of the box with any associated applications or equipment, and use the accepted standards such as ASCOM. For me its like having a new car delivered only to find it has no engine. All the lights and dials work but you can't go anywhere. Dave, I look forward to some detail instruction on how to run KStars on my Windows 10 PC and communicate with EQMOD without the need for additional hardware... and if you have any links to the reasons ASCOM is not supported under the Windows version of Kstars that would be great.

Dave, Can you explain in detail and in laymans terms how to get Kstars working with an HEQ5 (or any SW mount for that matter) on a windows platform (win10 64bit), ideally with links to whatever ASCOM alternative you hint at. I know often typing on forums the message can be misconstrued, this is a genuine question not being negative / nor should it be taken in an negative way, as I would like to try alternatives to the normal EQMOD / ASCOM / CdC option.

So that begs the question, does removing / overwriting the current version resolve the issue (presume it's no harder on Linux to uninstall than on the windows platform ??)

OK I'm a total newb when it comes to Linux, but I know that there are lots of flavours around. Would trying something different have any bearing on this or is it really a core issue and all these flavours of Linux are really just "skins" over the top, or is there more than one core kernel that could be tried. The strange thing is that the OP reported that the set up was fully working, but then mentions an update. Was that an update to the OS or was it an update to the INDI platform ? If it was the INDI platform, then can you roll back or install a previous version and not have any auto update in place. For example when I updated ASCOM to 6.5 as GSServer wanted that version to run, it screwed up my old QHY5 camera as 6.5 was too new for it. I therefore had no choice but to roll back the PC to how it was prior to installing 6.5 and GSServer.

Guys you are too kind.... I must admit I'm getting quite confident now at repairing these boards... 😉 I had no idea back in April 2020 when we fixed that first set of boards would it lead into what has now become a small time hobby I've lost count now, but we must be approaching repairs in to double figures by now. Mind you looking at these newer boards, even if the processors can be reprogrammed, the thought of trying to solder an ARM chip scares me 😟 I still have enough 16F886's for two more repairs, but have ordered a few more direct form Microchip to give me enough of a buffer given the current shortages. I do get a lot of enjoyment from fixing these faulty boards, not just the achievement in turning something from non-working to working again, but knowing that I've helped out fellow astronomers and members of this community. Your comments back that up and I'm really grateful for the support. As long as I can get the parts I'll try my best at fixing 'em

Over the past couple of months I've been in conversations with a fellow SGL member who was experiencing issues with his HEQ5, where the handset reported the classic "No response" message. The only problem was the global crisis of shortage of electronic chips caused me a big headache as my normal suppliers were backordering and the "assured" delivery date kept being shifted, and had to be cancelled when it went to October 2022 !! However I managed to source some more, at inflated prices but hey ho ! Well I received the kits this morning and started to do some checks before replacing the PICs. The first thing I noticed was the poor soldering of the wires form the interface board to the header that connects to the main board. These were removed and pads underneath inspected. Once cleaned it was noted that there was some corrosion around the pads and on one track, but testing continuity proved the track OK so the wires were remade and resoldered This time flush with the PCB. Other than a little oxidisation the original PICs looked fine and the board was clean. The electrolytic caps looked fine and didn't need replacing. The curly handset cable was tested for continuity which was fine, so the kit was put together and the fault confirmed Now it reported just one axis that had failed to respond, so I checked both blocking diodes and they were OK, so rather than mess about with replacing just the single PIC, as I have no idea if the DEC processor could fail at some stage I opted to program and replace both PIC to be sure. The old PICs were removed from the board and the pads cleaned - pleased to say that on this occasion no pads lifted. The new PICs were soldered in and the flux cleaned with IPA. The steppers were plugged in once more, and the interface board connected to the motor board. With the handset plugged in power was applied. A few more checks and then pressing the NSEW buttons at speed 9 and the motors spooled up nicely All that was to repack the kit and get it ready for returning when the post office opens on Monday Another success.

Not natively... There have been many attempts at a bridge between ASCOM and INDI over the years, but IMO its a clunky band aid fix to what really needed and that is a re-wright to use ASCOM natively. I did find this from 2017 which claims to bridge EKOS on windows.... never tried it, and can't confirm if it works Doh... should have tried the link --- the download gives a 404 error... !

I'm no expert, but I think he may be referring to this post (below) which if I follow it (and to be honest my linux experience can be written on the back of a postage stamp so could be way off) is removing an automated update to one that uses an older profile / driver / setting ??

You and me both mate... Now you know why I suggested windows 😟 I hope you manage to resolve this

Some of the new mounts with USB work at that speed, but most use 9600 as the default speed, and to be honest the data that is sent between the mount and handset / PC doesn't warrant 115K speed ! Glad its sorted

It is sad news.... but why not communicate that to their customers, or put a notice up on the website stating that the loss of their admin will result in delays. It takes 10 minutes to type up, and by keeping people informed are more likely to retain orders rather than face court action. People are sympathetic and far more likely to accept delays rather than not receive anything back to communications sent.

Switch to windows then - But then the windows version of Kstars doesn't (for some crazy reason) support ASCOM... I've been asking for years for them to do so.... That's surprising - I was betting that it would have been the other way around - PL 2303 drivers are not natively supported under windows... FTDI are and (which probably explains why it works so well under windows.

You should see properties as an option. Click that. This brings up a new properties window > click the Port Settings tab > then the baud rate (bits per second) value is displayed. If this is set to anything other than 9600 then change it by clicking the field and select 9600 form the list.

Forgot to add: When either the handset or EQMOD is first connected the handset or EQMOD sends :e1 and :e2 to the mount. This is basically "Send me your firmware version so I know what mount you are" The mount will respond with a string of digits. This is the firmware version which then confirms communications have been established The handset / EQMOD then sends further commands to establish the gear ratios, microstepping etc so it can then do the math when processing gotos etc. You could download any serial communication terminal app and manually send :e1 etc, or you could download and install the SW firmware updater application that does exactly the same to confirm communications. But it wouldn't prove anything as you've already stated the mount works perfectly under windows and when using the BT option...

This is my logic: Under windows and the ASCOM platform communications with the mount via EQMOD and any planetarium software etc work and the mount reports no time out errors. - Ergo there is noting physically wrong with the motor board on the mount. Under windows three EQDIR cables have been proven to work, again EQMOD doesn't time out or suggest any communication issues - Again suggesting that the hardware is fine Under Linux communication is established using the BT adapter - the mount control functions as expected - (you see where this is going) thus the hardware is fine. The supplied handset connects and controls the mount as expected - (do I need to repeat that the hardware is fine ) If under a flavour of Linux NINA established connection using all three EQDIR cables and the BT module then again this proves that communications are fine as is the mount If under Indi communications fail using the same hardware then the issue clearly is that platform. My guess is that as mentioned above, the chipset used in those EQDIR cables isn't supported, or any "driver" that Linux platform uses is not compatible or corrupts the data strings. The fact that it works via BT would suggest that the BT chipset is supported and the driver handles the communications just fine. As to why others have never reported the same issue is the $64000 question, but no two installations will be the same. I don't know enough about Linux to know if it's the build, or flavour of the underlying kernel. The bottom line is that you have alternatives that work. Maybe switching to one of those alternatives is the way forward rather than loosing sleep trying to get to the bottom of this, especially as the indi developer can't offer a solution.

With everything connected and powered up, go into device manager, navigate to the PORTs section and right click on the first port shown. Select the option to remove the entry but keep the driver. Repeat for any other ports. Then from the menu choose the option to scan for hardware changes, it should pick up any serial adapters / EQDIR cables etc and re-allocate the port numbers. It may re-allocate the same numbers as before. If the connection to the scope is the only port, then select this port and right click and select properties. Under port settings ensure the baud rate is set to 9600. If its anything else then change it and save / OK to exit. Open up Toolbox and select driver setup. Ensure the same port number is selected and the baud rate is also 9600. Ok to close and then with EQASCOM selected, click the test connection button to launch EQMOD. It should connect and allow you to move the mount. You can then close that down and close Toolbox application. I've not connected to a mount via sharpcap, but if it follows normal ASCOM protocol it should bring up a chooser box for mount and camera. Select the mount as set up in the toolbox driver and you should be good to go

Does it natively support ASCOM ? I really like Kstars as an application, but the fact the windows version doesn't (or didn't) support ASCOM and could thus work with EQMOD / GSServer for scope control really annoyed me. Years ago I did play abut with JINDI or whatever the wrapper was, but could never get it to work

If the mount works fine on windows then it can't be anything physically wrong with the mount. If the motorboard was faulty it wouldn't respond to commands under any platform or connection method, and would give a "no response" message when the handset is used. The fact that it also works fine with a BT module, and with the handset also confirms that the issue isn't IMO hardware related. Also as it fails on Indi with the same known working EQDIR cables, but works with the BT adapter, to me suggest its the way Indi handles the control of the COM ports, especially as you're tried the same platform on different hardware and get the same result. I can't help with suggestions as I use windows as the platform in the observatory PC. The fact that it works via BT on the Indi platform may be the fix for now... at least it gives you a working set up.

That's good news. I agree that if any repair works then leave it be. It doesn't have to look pretty. I presume you either re-flowed each solder joint, or did you swap any wires over. If it was a reflow then I would be seeking some redress from the tech guy as clearly he didn't do a decent job in the first place. However I suspect the main cause was the encoder. If the board can't read the encoder then it won't know its position and will report "I'm lost" back to the handset Well done

Well you should be able to get some decent images of the moon with the camera and your 200P dob to get you started. Connect the camera to a laptop via the USB cable and download SharpCap. This will give you the option to record short clips of the Moon. The current version of Sharpcap has a live stack feature, which I've not used myself as it's been a while since I did any video work. Basically it treats each individual frame of the video as a separate image and stacks them to make one detailed image. Your camera is also suited for planetary and DSO's, but that is going to be harder with a dobsonian IMO. Planetary work can be done on the same basis, but to get really decent planetary images you need magnification as well as aperture, and the dob falls slightly short in this area. Your biggest problem you will face at some point is the Earths motion, especially if you try increasing the magnification to get in closer to Jupiter for example. Now there are wedges that can be used to tilt a Dob, and adding a drive to what then becomes the RA axis makes things a fair bit easier. But if you really want to get into things seriously then at some point you'll need to move up and invest in an EQ mount. Now this is where things get interesting and controversial. For every post that recommends getting an HEQ5 or similar standard of mount there will be one that says it can be done on an EQ3. With imaging the key factor is the mount as stability and accuracy are the two main criteria. Yes you can image on an EQ3 with a 6" f5 scope... but it will struggle under some weather conditions, and will be subject to less precision as a larger mount. An HEQ5 will still do the same with a 8" f5, cameras and guide scope in the same conditions, but put the 6" on the HEQ5 and you can effectively cure that stability issue. Or if the 8" HEQ5 combo is housed in a sheltered spot (such and an observatory) then that removes the issue of wind impact. Then there's the choice of scope. Again that is going to bring lots of suggestions. Basically no one scope fits all. If you want to image DSO's you need a fast scope F4 to F6, and reasonable aperture. In order to image planets you need a long focal length and ideally large aperture. A 6" refractor that has a focal length of f9 or a 6" Mak at f10 will give you the magnification needed to get in close to those belts on Jupiter or Saturn's rings. But some of the best images that are often featured in the glossy magazines are taken with some serious kit... 14" f20 scopes on EQ8 or larger mounts. I guess its horses for courses... I could take an image of a church with a £200 basic camera and be happy with it, but someone who is seriously into photography who may have 10x or more the investment in his kit will a) take better resolution images, and b) see the shortfalls of the image taken with the cheap kit and naturally won't be happy. However the chances are that the guy with the professional kit started with same cheap kit at some point and then progressed as his ability and expectations grew. The same goes for imaging... Anyway, that's my take on thing...

Found another thread of similar nature here The fault was in the cabling

Pete, if replaced as a set (ie both the part that gets soldered to the PCB and the mating part that has the cables) then it wouldn't be an issue. Most connectors are made to one of two or three standard pitch types so it's easy enough to source something that fits. I agree that something is strange as normally if its a communication issue you wouldn't get the situation where the mount starts to move but then stops and reports an error. This could be more related to motor control such as FET that is in the process of braking down and when current flows gets hot and fails ??

To be honest I would have replaced the connector on the board and re-terminated the cables - If you paid 50 euros for a "professional" repair I think its fair, but it's not a professional job to cut off the connector and solder the wires direct. I've replied to your new thread - It might be worth locking this thread so as not to duplicate posts ... Edit - I've requested the moderators to merge your two threads as both are relevant and here we can follow the issues you've had and what's been done to fix it

Not had a lot to do with Mead, but when a Skywatcher handset reports "no response" to either a single or both axis it normally means the main processors have been damaged, often by plugging the wrong cable into the wrong port. Googling your issue it would seem based on old discussions of people experiencing the same issues that the same logic would apply and the problem is in the communications between the handset and the processor(s) on the motor board. Now I presume you have tried all the usual stuff of checking connections, cleaning contacts and making sure the mount is powered by a suitable supply ? If so then it could be the main motor board that has developed a fault. Most mounts have a process where the handset sends out a "hello, what mount are you and where you are pointing" message, and expects the mount to respond with "I'm a XXX mount and here's my current position". If it fails to receive that response it then halts its set up procedure and reports a problem. The exact cause for the motor board to report the error isn't clear and you may need to dismantle the mount to check for things that may be obvious. I don't think its an encoder or motor issue as apparently if one motor or its driver had failed, or the encoder wasn't readable the error message is different. Here is an old post where the user incorrectly connected the wrong handset (het had two Mead scopes) - but it's not conclusive if the issue was ever resolved through reflashing the firmware. In this post the problem was a broken wire.... Rather than fill up the thread with links to old forum posts, just google " LXD 75 motor unit fault " and see how you get on. In the past I've repaired around 8 Skywatcher motor boards by replacing the damaged processors with new ones programmed with the SW firmware. I'm not sure if that would be an option with the Mead as the firmware needs to be processed first and the Mead firmware may not allow that processing to happen. They do however seem to use a 16C268 Pic micros which are a one time program device, so a more modern flash alternative would be needed if the firmware could be cracked.

If the sysnscan box where the motor cables plug into is one of the newer units that has a USB type B port then you can use a standard USB A-B cable If the synscan box has just the power / handset / autoguide ports then an EQDIR cable (the second link in Peters post) can be used by removing the handset and plugging this cable in to the handset port. Windows should install the driver automatically An alternative (and expensive) way is to purchase a serial to USB cable like this and then purchase the cable Peter linked to first. This is connected to the HANDSET and the handset is left connected to the mount. You then set the handset to PC-DIRECT mode to allow pass through communications to the mount. Personally if the Synscan unit doesn't have a USB port I would opt for the second suggestion and use the LYNX Astro EQDIR cable.