Welcome to the toughest part of data capture... In the many years we have been doing this, this issue feels like the challenge that causes the highest amount of AP attrition.  If you can get through this, there are still plenty of challenges to face, but this one, to us is often the most frustrating.  Frustrating may be an understatement.  For the most part, gear and software are so complex that, as a user, you have very little control over their operation.  You just have to assume that because everyone is not complaining there must be some combination of things that will work.  Light three candles, walk backwards in a circle, then connect the camera. This can be debilitating in many ways... you're not actually fixing anything, you're just fiddling with stuff and hoping.  This may be thrilling for a tinker, but many folks have a WAY different mental image of AP and it doesn't end with throwing very expensive equipment against a wall.


Why that little ramble?  Well, in all honesty it's to let you know that we get it.  Sometimes it's terrible and frustration is high, but the truth is that a lot of time we just don't know the answer.  But, how can you not know what's going on?  Doesn't SGPro tell gear what to do? If my gear is misbehaving, then surely SGPro is telling it to do the wrong thing.  The answers here, in order are: "we kind of know what's going on", "Yes, we do tell gear what to do" and "It's unlikely that SGPro is telling your gear to do the wrong thing".  If you're interested in why these are the answers, read on.  If you just want to know our recommendations on how to get to a resolution in the fastest way possible, skip down to the last section.


While we don't dislike being in this position, being the software that users interact with directly also means we pick up the blame for most things that go wrong.  Like I said, we're fine with this and, in a lot of cases, the problems that folks experience with other software when used through SGPro are so common that we actually can help and do so very quickly (always ask!). In a lot of cases though, we only have a little more visibility to the root cause of the issue than you do.  SGPro will, via ASCOM, ask your gear to do a "thing" or report a "thing".  Sometimes this thing is simple like "give me a temperature reading", but sometimes this thing, is more complex like, "open the shutter, start integrating, do it a a binning of 2x2, but only collect data in a very specific sub frame and when done, use a fast download readout".  All of that, to SGPro, is a single command to the camera.  Yes, we define all of those characteristics before we as the gear to do a thing, but what happens when that one action fails?  To SGPro, we only know that action has failed.  We may know why.  A lot of manufacturers provide sturdy, robust, well-written drivers that give great insight into problems encountered in the driver.  In these cases, if you provide us with (or attempt to read) logs, you can get a bunch of really useful information.  Unfortunately, in a lot of cases, what we see is a very cryptic error that only means something to the author of the driver (maybe not even that).  In this case, we are effectively blind... Here's where we often need to refer you to the author of the drivers you are using (usually the manufacturer) and here is also where we are often accused of pointing the finger at others before taking a deep look inward.  Has this happened before?  Of course, but it's VERY rare and when it does happen we eat crow and move on.  In most cases, it's not SGPro and we can determine this pretty quickly based on the type of issue you are experiencing.  SGPro has a tendency to treat all classes of gear exactly in the same manner.  In other words, we typically don't care what kind or brand of camera you have... we only care that the camera abides by the ASCOM contract.  Once it does, it is just A camera to us and no longer a camera made by a specific brand.  When we assess the problem you are reporting, one of the very first things we do in order to triage the issue is determine if it falls within bounds of a specific class of equipment (like the camera-class).  If, you report that your camera fails to download data, there is almost no chance that an issue in SGPro has caused this issue?  Why?  Simple really... if SGPro were responsible, we would break A LOT of gear really fast and all at the sane time.  When we don't see that, we will tend to focus on the driver first.




Step by Step


Ok... so now nobody knows anything and everything is still broken.  In some sense this is true, but don't quit!  Even if we can't provide you the magical answer we can help you find one.  In this case though, you'll need to do a little legwork.  I wish we had the capacity to orchestrate complex support issues across multiple organizations, but we don't so we'll need you to help with this.  Before you reach out though, we can provide you with actual information or instructions on how to get information that the manufacturer will almost certainly request from you.  Having it from the start will help their developers to find and locate the issue MUCH faster.  What are we after?


  • A solid description of the issue:
    • A concise description. By concise, we don't mean that you shouldn't provide details.  They absolutely want details... they are often extremely important. What we mean here is this: The very first part of you communication should explain the observed problem in one or two sentences.  That's it.  Then... in a new paragraph add all the details required to supplement the description.  Please don't bury the problem you are seeing in a 1,000 lines of detail.
    • What version of their driver are you using?
    • What version of ASCOM do you currently have installed (See ASCOM diagnostics window below)
    • Is the issue repeatable? If so, is it consistent?
    • How does SGPro or you (or both) interact with the gear before the issue occurs?
  • Client logs.  That's us.  When talking to a manufacturer, apps like SGPro are referred to as "clients".  What they absolutely don't want is an entire SGPro log.  They just want the parts showing communication with their gear or, if repetitive in nature, a few examples will suffice.  In a lot of cases, their driver has given SGPro a very specific error.  We don't know what it means, but by giving it back to them here, they probably have a good chance of interpretation.  As much as we'd like to give very specific guidance here, it's often better to ask us which parts of the SGPro log are of interest... it may be several that are in very different areas of the log (for instance connection and then later, some action).  General steps:


AFTER recreating the issue, in SGPro, go to the "Help" menu and click "View Log"



Alternatively, you can click "Open Log Folder" to access previous logs.  The, using the "Date modified" column in File Explorer, determine which log file contains an example of the problematic behavior.


  • Equipment Logs: This is not always clear how to get or if they even exist.  Some manufacturers always write logs, some allow you to enable a logging option within their driver and some have no special logs at all.  We just can't remember the logging strategies from all manufacturers... you may need to ask or the first reply might have additional instructions.
  • ASCOM Trace Logs: Regardless of the logging strategy above, you can ALWAYS get ASCOM trace logs.  While they may want or need additional information, these logs will provide insight into almost any issue dealing with ASCOM gear.  It may not show the actual issue, but it may provide a series of steps leading to the issue or show that the driver has a concurrency issue, etc.  Here is how you can get those logs:


Open the ASCOM Diagnostics app (just hit the Windows key and type "ASCOM")



There are LOTS of different trace types and a manufacturer may ask you to enable others depending on the type and architecture of the gear.  Initially, the one we are interested in is called "DriverAccess Trace".  You can think of this category as all of the instructions passed from SGPro to the equipment's driver.



Note the log location for later.  When the trace log(s) are available, they can be found in the directory shown in the main window of the ASCOM Diagnostics app:



Click the "Exit" button


  • Now, with SGPro do what you need to do to recreate the issue
  • Then, using file explorer, navigate to the ASCOM Diagnostics log folder and locate the trace logs for the problematic equipment.  In most cases, the file you want will  be named as ASCOM.[EquipmentName].[time].txt.  For example, a Trace Log for the ASCOM Focuser Simulator might be named: ASCOM.FocusSimulator.1147.296380.txt



  • Using whatever method you prefer, make this file available to the manufacturer.
  • REMEMBER! Turn the Trace Logging back off! (Use steps above)