Getting Help - Up Front
- Keep in mind that "ASCOM", "Alpaca", and the "ASCOM Platform" are a set of specifications, documentation, tools, and libraries used by many developers for apps, devices, and drivers. If you have a problem with an app or a device that uses ASCOM or Alpaca, the first place to go for help is the app or device maker.
- With the above in mind, feel free to communicate with us on the ASCOM Talk Help Forum.
- Use the detailed links in the orange box on the left of this page to get help on your specific type of problem.
- The problems we see most commonly are with devices, and are most often caused by flaky cables, bad USB connectors, bad power supplies for devices, or other hardware and driver related issues. The device maker, driver author, and people here who try to help need a way to make the problem happen reproduceably. Divide and conquer is another concept to consider.
- An anti-malware program may incorrectly detect and quarantine a component. We test with all major AV programs however, it's a moving target. So turn off your AV and try again. If it still quarantines, use the AV tools to declare the component as safe.
- There are no gremlins living in computers and devices. The causes of problems can virtually always be explained logically. Give the developers and others who want to help a chance to focus on the problem and solve it.
How to Avoid Frustration
If you find yourself not understanding and not getting help from device manufacturer or the app developer, it's easy to get into the "If all you have is a hammer, everything looks like a nail" mode. When you find yourself there, beware, you're likely to do something that makes things worse and/or obscures the real problem. Here are some common frustrating scenarios to be aware of and avoid:
- Uninstall/Reinstall cycles. This virtually never helps, and often makes things worse.
- Trying to back-rev by uninstalling and reinstalling an older version. This can make things really bad because an upgrade may have changed the format or layout of data, components may have been replaced by newer versions and back revving may not downgrade them ("DLL-hell"). It's a very bad idea.
- Running things on Windows "as Administrator". Running "as Administrator" puts apps or drivers into a separate high-privilege execution environment where they cannot communicate or interact with apps or drivers not running "as Administrator". All sorts of inscrutable problems can arise. You may find yourself deciding to run first one app or driver "as Administrator" then that makes it necessary to run another that way, and so on until everything is running "as Administrator! Apps see different areas of the registry, your settings may change. It's ugly.
- Blaming "ASCOM" for some problem in a program or driver. "ASCOM" and the "ASCOM Platform" is a set of documentation, tools, and libraries used by many developers. It is not a "program" that is causing your problem.
- Blaming Windows Updates for changes in behavior or failures of your apps or drivers. An extreme example is the person who blamed a Windows Update for a change in the slew limits on a mount. This is simply ridiculous.
- Asking for help on some forum or Facebook group before first contacting the program author or device manufacturer for help. Your chances of getting useful help from old Uncle Festus are not as good as would be if you asked the author or maker.
There is no end to the Old Wives' Tales out there relating to fixing software and hardware problems.
General Advice - If You Ask Us for Help
Communicate with us on the ASCOM Talk Help Forum. Remember that we aren't looking over your shoulder; we can't see things that are totally obvious to you. We need to know:
- What brand of device (e.g. telescope and mount) you are
using.
- What driver you have selected, including its version. Are you running the latest version?
- What application you are using. Is it up to date?
- What operating system you are using, including the release number etc. Is it up to date?
- Exactly what you did, what worked and what did not.
- An exact reproduction of any error messages, with what was done just before the error happened.
- Ideally an exact sequence of actions that will generate the error (repro scenario).
- Any log files produced by the application and/or the driver. You might look at them first.
