Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Orion SSAG firmware reset.

  • Please log in to reply
14 replies to this topic

#1 kag

kag

    Lift Off

  • *****
  • topic starter
  • Posts: 12
  • Joined: 10 Apr 2009

Posted 03 February 2013 - 09:03 PM

Hi,

My Orion SSAG recently went belly up. It was working just fine one day, and the next day that little red light would not come on. The computer would not recognize the camera, and the Device Manager showed it in yellow as an Unknown Device. Attempts to reload or update the drivers were futile. I thought all was lost until I ran across a thread on CN that addressed the very issue I was having. Further research revealed other articles. From all of this information, I was eventually able to rectify the problem, and I now have my autoguider back.

The problem was the camera had somehow changed its VID and PID values, and these needed to be reset (see below). Come to find out, others have had this same issue, so apparently it is something that can happen, but fortunately it does not appear to be ultra common. But if this does happen to you, I have written a nice concise work-around that should have you up and running in a jiffy. Please note, I am using Windows XP, so I do know it works with this OS.

The first thing you need to be sure of is that you have a file called ssag.inf. If your drivers came from the PHD disc, you probably do not have this file. I had to go to the Orion Telescopes link below to download the SSAG driver setup in order to get that ssag.inf file.

http://www.telescope...keyword=drivers

Once downloaded, install this program on your computer, and the ssag.inf file will be located in the C/Program Files.Orion/ SSAG_Drivers/Driver folder.

Now, follow the procedure below, and you should have your SSAG running good as new.

1. Check the Device Manager to see if there is an Unknown Device in yellow. If so, click on this item and then click the Details tab.
2. Check the Device Instance id. It should read USB\VID_1856&PID_0012\5&26712E48&0&2
3. Check the Hardware ID. It should read USB\Vid_1856&Pid_0012&Rev_0000 USB\Vid_1856&Pid_0012
4. My VID and PID read USB\VID_04B4&PID_8613\5&26712E48&0&4. Yours may read this, but I do not know if there are any other possibilities. If yours reads something else, I can only assume this procedure will still work. Now go to C/Program Files.Orion/ SSAG_Drivers/Driver/ssag.inf and open the ssag.inf file in Notepad.
5. Look for the lines:
[ORION.NTx86]
"Orion StarShoot Autoguider Driver (Base)"=BASE_Install,USB\VID_1856&PID_0011 "Orion StarShoot Autoguider Driver (IO)"=USB_Install,USB\VID_1856&PID_0012

[ORION.NTamd64]
"Orion StarShoot Autoguider Driver (Base)"=BASE_Install,USB\VID_1856&PID_0011 "Orion StarShoot Autoguider Driver (IO)"=USB_Install,USB\VID_1856&PID_0012

BEFORE DOING ANYTHING, FURTHER save this file as ssag2.inf. You will need to change this back to ssaf,inf when done.

6. Change the VID (1846) and the PID (0011 and 0012) to the values shown in the Details tab. Save this file as “ssag.inf”. You will need to save the File Type as All Files, not Text, because you do not want to save it as a text file.
7. Plug in the camera and follow the driver setup.
8. When done with the setup, check the Device Manager/Details tab. You should see that the VID and PID numbers are now set to the 1856 and _0011 & 0012 values. Your firmware has now been reset.
9. You can now delete the new ssag.inf file created and rename the ssag2.inf back to ssag.inf.

This is what worked for me. Hopefully it will work for you as well, but I am not responsible if it does not. You make these changes at your own risk.

Cheers,

Keith Graham
  • JoseBorrero likes this

#2 Dan Crowson

Dan Crowson

    Vanguard

  • *****
  • Moderators
  • Posts: 2143
  • Joined: 08 Oct 2010
  • Loc: Dardenne Prairie, MO

Posted 03 February 2013 - 10:23 PM

Keith,

thanks for the post. I know I've dealt with this before but mine was still under a warranty to I was able to ship it back.

Just being a perfectionist, you might edit your post and change the driver paths. They should be C:\Program Files\Orion\SSAG_Drivers\Driver\ssag.inf or C:\Program Files (x86) for Windows 7 64bit.

Dan

#3 kag

kag

    Lift Off

  • *****
  • topic starter
  • Posts: 12
  • Joined: 10 Apr 2009

Posted 03 February 2013 - 11:32 PM

Thanks for that correction, Dan. And especially for the Windows 7 addition.
Cheers,

Keith

#4 SL63 AMG

SL63 AMG

    Viking 1

  • *****
  • Posts: 922
  • Joined: 21 Dec 2009
  • Loc: Williamson, Arizona

Posted 04 February 2013 - 12:04 AM

That's an interesting procedure, but it seems like a lof of work to fix a driver issue.

I am interested to know why you think this procedure "resets" the firmware on the SSAG?

Wouldn't it be easier to simply uninstall the device from device manager?

If the driver was installed on an external hub port and won't uninstall properly from device manager, you can always uninstall the computers root hub from device manager which will drop the external hub altogether and all of the devices attached to the external hub. Then you can simply restart the computer and the root hub will auto install.

When you plug the external hub back into the computer along with each device, each device will also auto install from the drivers already on the computer.

This corrects any corruption that may be in the windows registry which is likely where the issue lies with the SSAG as opposed to it's firmware which doesn't change.

#5 kag

kag

    Lift Off

  • *****
  • topic starter
  • Posts: 12
  • Joined: 10 Apr 2009

Posted 04 February 2013 - 11:46 AM

Hi Dave,

I say it is resetting the firmware because that is what I had read in other posts on this topic. The procedure I listed is based on what others have posted here and elsewhere. When I followed the procedures on those posts, I met with success (the SSAG now works). I then tried to condense and simplify all of those instructions into one that could be easily followed. Actually, I had never heard of VID and PID before this, so it was a learning process for me.

As far as uninstalling and reinstalling the drivers, the drivers were just fine. I ran another SSAG on this same computer and it worked fine. The VID (1896) and PID (0011 and 0012) on that ssag were as they should be. The one that did not work had the wrong VID and PID info. How that happened I have no idea, but others have reported this same issue. Something (who knows what) had caused those numbers to change, so they were no longer matching the values in the ssag.inf file. So I do not believe this was a driver issue since my other SSAG worked. When I plugged the "good" camera into the computer, it installed properly. When I plugged the "bad" ssag into the computer and tried to install the drivers, it said there were no drivers for this device.

All I can say is this process worked - I now have a working SSAG. And actually, the process is not a lot of work. Once I knew what to do, it was done in a matter of minutes.

Cheers,

Keith

#6 SL63 AMG

SL63 AMG

    Viking 1

  • *****
  • Posts: 922
  • Joined: 21 Dec 2009
  • Loc: Williamson, Arizona

Posted 04 February 2013 - 12:41 PM

Hi Dave,

The one that did not work had the wrong VID and PID info.


I think this is the key point. I don't believe you are resetting the VID & PID in firmware. It is more likely you are resetting the USB driver bindings in Windows.

It may be that VID is virtual ID and PID is physical ID. This is my best guess.

In any case, I think your PID nad VID were likely corrupted at the USB to driver binding level not the firmware level. It is possible that the firmware assigns these numbers randomly and once Windows got confused with the driver binding and flagged the device as "unknown", they were set to new values when the device tried to install.

In any case, I am quite confident the issue is a USB driver binding malfunction on the USB hub. This is quite common with Windows when many devices are being plugged and replugged, particularly when chaining USB hubs.

Keep in mind there is a "root" USB hub in your computer. That controls your USB ports. When you plug a USB hub into one of your computers USB ports, you are in effect daisy chaining USB hubs, of which I believe there is a maximum of three before Windows complains to you.

When you plug your device into a USB port Windows binds the driver to the port and adds it to the registry. Then when you tear down your equipment and set it up another day, if you aren't plugging the same devices into the same ports, Windows has to bind the drivers to the new port.

This is where Windows tends to get confused after a number of driver bindings.

I highly recommend labeling your USB cables for each device, then labeling each USB port for the device that is plugged into it and always plug the same devices with the same cables into the same ports.

I had the same problem with my mount. Windows lost the binding and the mount was listed as "unknown" every time I plugged it in. No amount of uninstalling and reinstalling of the mount software and drivers would fix the problem. I couldn't even plug it into another port on the hub. Windows simply said the device was not recognized and flagged it "unknown".

When I uninstalled the "root hub" of my computer and restarted Windows, the root hub was reinstalled automatically. I then plugged in the external hub and it was recognized as a new device along with all of my devices, camera, filter wheel, focuser, rotator, mount and joystick.

#7 D_talley

D_talley

    Gemini

  • *****
  • Posts: 3262
  • Joined: 07 Jul 2005
  • Loc: Albuquerque, New Mexico

Posted 04 February 2013 - 03:25 PM

This is a known problem with the Qhy5 (SSAG) series of guiders. I had the same problem with mine, laptop would not load the drivers when pluggin it in. I went to the developers web site forum and they had a step by step list of what to do and software to reprogram the bios.

Also listed on the page is a diagram to show you how to write protect the EEPROM so that the VID does not change again. Look under the entry by QiuHY.

SSAG QHY5 FIX

#8 kag

kag

    Lift Off

  • *****
  • topic starter
  • Posts: 12
  • Joined: 10 Apr 2009

Posted 04 February 2013 - 03:52 PM

Hi Dave,

Actually, this was all very new to me, and I was learning as I was going. I simply took the word of those whose posts I read that the firmware was being reset.

Also, this camera is on a permanent mount, so the usb port was never changed. I just went out one day and the ssag was dead. That is when I did some Googling to see what I would come up with. Whatever this process does, it worked and I am happy for that.

Also, I tried the camera on 2 different computers and it did not work on either one. The other ssag worked fine on both computers. That is why I lean towards the problem being in the camera and not with the drivers or with Windows. But, then again, whatever this process did to fix it, I am not an expert that can determine why. I just know that I now have a working camera, and that is all that matters to me:).

Cheers,
Keith

#9 SL63 AMG

SL63 AMG

    Viking 1

  • *****
  • Posts: 922
  • Joined: 21 Dec 2009
  • Loc: Williamson, Arizona

Posted 04 February 2013 - 07:21 PM

I find it odd that a camera can simply quit after the EEPROM gets updated by a ghost.

Sounds like bad software to me.

The EEPROM should be write protected from the factory, not the user.

#10 SL63 AMG

SL63 AMG

    Viking 1

  • *****
  • Posts: 922
  • Joined: 21 Dec 2009
  • Loc: Williamson, Arizona

Posted 04 February 2013 - 07:31 PM

So I read the thread you provided.

Mads0100 writes: "Unfortunately, I'm doing this with Windows 7. Do these rules even work with Windows 7?"

To which QuiHY replies: "No, You must to use XP to do that. Because the temp driver is XP only."

JoeRam then replies: "Time to sell the SSAG and get a QHY5! Anyone want to buy a SSAG?"

This problem alone would turn me off from buying QHY cameras.

But alas, QuiHY finally states: "And in recently production we locked the EEPROM. to avoid the EEPROM information lost."

At least they learn from their mistakes. Can anyone say "Product Recall"?

Anyway, all that stuff I wrote about USB driver bindings still applies if you happen to have a device that suddenly becomes an "unknown device" in Windows 7.

#11 cystokid

cystokid

    Lift Off

  • *****
  • Posts: 15
  • Joined: 29 Oct 2011
  • Loc: northern MI

Posted 06 January 2014 - 10:54 AM

Hi Keith! Although this is almost a year since first posted, your walkthrough in how to fix the .inf file got me up and going. Thank you SO much!
Bryan

#12 JoseBorrero

JoseBorrero

    Soyuz

  • *****
  • Posts: 3695
  • Joined: 04 Sep 2009
  • Loc: Puerto Rico Island

Posted 17 February 2015 - 06:49 AM

Thanks to this post my friend could fix this SSAG  :waytogo:  keep this thread!  :waytogo:



#13 fxxm747

fxxm747

    Viking 1

  • *****
  • Posts: 700
  • Joined: 26 May 2004
  • Loc: Milwaukie, Oregon

Posted 11 June 2015 - 04:17 AM

I have two of these that are now "bricked". Last one happened tonight....argh! I cannot locate the .inf file anywhere in the SSAG driver folder??



#14 Dan Crowson

Dan Crowson

    Vanguard

  • *****
  • Moderators
  • Posts: 2143
  • Joined: 08 Oct 2010
  • Loc: Dardenne Prairie, MO

Posted 12 June 2015 - 11:17 AM

I have two of these that are now "bricked". Last one happened tonight....argh! I cannot locate the .inf file anywhere in the SSAG driver folder??

 

Make sure you're viewing all files. In Windows 7 it is Folder and search options under Organize. On Windows 8.1, I think it is view and options. Uncheck Hide protected operation system files (and Hide extensions for known file types).

Dan



#15 Tyro

Tyro

    Lift Off

  • -----
  • Posts: 20
  • Joined: 04 Dec 2007

Posted 16 December 2015 - 07:28 PM

Hi everyone.  A couple of days ago I ran into this issue.  So I have a Mac mini running parallels desktop for mac.  I just upgraded from win7 to win10.  My SSAG worked for one night, then the next night, boom-unknown device.   So I plugged the ssag into a clean regular old windows XP machine and performed the driver trick from above.  Boom it worked on the XP machine no problem.   The camera light came back on to full and PHD on xp worked. 

 

Now unfortunatly when I plugged the camera into the Mac (actually tried fresh new mac as well),  the camera still reads as USB\VID_04B4&PID_8613 (shows up as a device called Cypress Semiconductor).  So I plugged the camera back into the xp machine and it works fine and is displayed as VID_1856&PID_0012. So I don't think there is actually any writing of the eeprom going on here. 

Either way, anyone have any other thoughts on how to fix this on mac?

 

Thanks

 

Tim.

 

UPDATE:  Success!!!!  Ok everything is working now.  At least on the Windows 10 Virtual Machine.   I basically repeated the steps from above, except i did not change the VID/PID back to the original values.  I left the modified versions.    Now this works for Win10, but PHD2 doesn't work on the mac but that's ok as i'm using a VM anyways.  


Edited by Tyro, 16 December 2015 - 09:36 PM.



CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics