So I recently purchased an Orion StarShoot G3 CCD (the monochrome version) and was hoping to get it working under linux. I tried loading the indi QHY server and then accessing the camera from kstars but the indi control panel that comes up when I 'run service' for the QHY CCD it just pops up a blank window. I am assuming this means my camera is not recognized, which doesn't surprise me too much since googling before I bought the camera didn't turn up anything regarding linux support (nothing saying it won't work but also nothing saying it will).

I would really like to get the camera working under linux, and might consider writing the support for indi to do that, but I would need some pointers to getting started and possibly a fair bit of handholding through the process. I am good with C and C++ and know a fair bit about hardware drivers as general theory, but the actual practice of writing one is something I have never attempted.

So my main question is two parts, first is there existing support for the G3 that I am just not properly making use of? and if not, is there someone or some guide as to how to go about writing the support code myself to run the camera through indi? Also, if there is anyone who has written drivers before and could write one for me, I would be willing to compensate you for the effort as well as try to make arrangements for access to the hardware either through setting you up with an account on my machine here or something similar for testing purposes. Currently I am just trying to explore all the possible options, and am looking forward to hearing back regarding any of these possibilities.

Just adding a quick update as to the status here. I have read through the INDI developers guide and it looks like developing the INDI code to talk to the scope is a fairly simple task, but the underlying driver is where most of the work will be. Looking at the INDI code for the QHY cameras, it seems like the INDI code is basically just a wrapper around calls to libqhy which does the complicated hardware stuff. I guess when I think about it, this makes sense and it is likely that other cameras are done in a similar fashion.

Regarding using the camera, I have a windows XP laptop that I have got set up so the camera is at least useable, but running it under linux would not only be preferable but would allow much better integration with other software for data reduction, etc. So I definitely still want to try to get it working there. I know there is software that will let you basically 'packet sniff' the USB connection to see how the wire protocol between the computer and camera goes, so in theory it shouldn't be too difficult to reproduce that in a linux driver but the exact details are still unknown to me.

Yes you pretty much have to reverse-engineer it, unless another Linux camera with same/similar chip is out there with USB protocol already figured out.

Do you know if there are similar chips that are already supported? Kind of wondering how best to even go about this, basically, where to start.

Hi Andrew,
My guess is the Orion SSG3 uses a Cypress FX2 chip as it's brain. This seems to be the most common design in the cheap astro cameras. You could crack the camera open and look to verify, but you could probably figure this out from lsusb output.

To reverse engineer the camera, you'll need a windows box. You can use a VM (virtual box works well for this). If it does have a Cypress chip, then you'll almost certainly have to load a firmware for the camera to do anything useful. Plug your camera into your machine and do an "lsusb" before giving control of the device to the windows VM. Then give the windows VM access to it. Windows should automatically load the firmware assuming you have installed the drivers. Then, you can pass control back to linux and do an lsusb again. You'll likely see a different device id for your camera which indicates the firmware has been loaded. Next, you can dump the firmware to a file so that we can load it under linux. You can use code from the meade DSI sourceforge project (sourceforge.net/projects/linuxdsi/ see src/dumper.cc) to help extract the firmware. You'll use the fx2load utility to load the firmware from linux once you've extracted it.

Once the firmware situation is dealt with (if necessary), then I would suggest taking pictures through windows while dumping the USB traffic from linux. You can use wireshark to do the snooping. You'll probably want to start out by taking pictures of all black, gray, or white scenes so that it's clear where the image data begins and ends in the raw dumps. The sensor that the StarShoot G3 uses is an ICX419. It's a field readout so you'll probably see the even and odd rows come over separately.

There'll be a lot of trial and error but it's certainly doable! If you can provide raw dumps I would be more than happy to help with this.

Thanks,
Ben

Just a quick add on to what ben said. Lots of stuff based on the fx2 relies on the host loading firmware, but that's not always the case. The Starlight Xpress cameras have the fx firmware on board already, and dont rely on the host loading any firmware.

The way the fx2 works, when it starts, it reads the first few bytes out of the eeprom, and checks one of them, dont remember which offhand, to see if there is firmware on board. If so, it continues loading from the eeprom, puts it into memory and executes. If it's not there, then it presents the vid/pid contained in the eeprom to the host computer, and essentially sits waiting for the host to use fx2 calls to load firmware.

If you want to poke around inside the fx2 a little, get fx2lib and sdcc set up, then you can put simple little things onto the fx2 chip to poke at sensor registers etc and figure things out if necessary.

Thank you both for the replies. I will look into trying to snoop on the protocol to see how it behaves. Regarding whether the firmware is sent by the driver, the Orion Camera Studio does have a menu option to load a new firmware onto the device, not sure if this is an indication that the firmware is actually left on the camera between usages, or if maybe that menu option is for other cameras, or maybe if that just updates what the driver sends to the camera when plugged in. Running the firmware update menu option requires java to be installed, which I did, but then it just pops up a dialog asking what firmware file to load and I couldn't find any online so that was basically a dead end. In any case it doesn't really tell us much about what the camera is actually doing until we see the actual USB traffic.

-AndrewBuck

Hi Andrew,
Based on your description, I think Gerry might be right about the firmware being stored in the camera. If so, that would make things a bit easier (you wouldn't even have to consider the firmware aspect). I assumed the firmware wasn't stored on the camera because flash costs money and it's a simple cost cutting measure for cheaper cameras (it's not surprising that Starlight Xpress cameras have a flash chip).

Thanks,
Ben

For an fx2 it's not flash, it's an eeprom. They are cheap, come in small and larger sizes. I'm always surprised at how so many of the camera vendors end up cutting of thier nose to save a few cents in that area. For the cost of handling ONE support call dealing with driver / firmware load problems, you can pay for the eeprom on a hundred cameras when buying in typical production run quantities. At production time, the eeprom must be programmed, even if it's just to put in the vid/pid in a small one. The time delta between programming a few bytes, and a few kbytes, is lost in the noise when you account for the time it takes to hook it up, and then unhook from the equipment. Over the years I've read so much about folks having issues with drivers etc, and firmare versions, yadda yadda. If you look at something like a qhy5, the total production cost increase to put it all on board would be on the order of a buck, possibly less.

It's a mindset that spills over from high volume consumer manufacturing, cut every penny out of the production cost where possible, but, imho it's a mistake for high value items in low production volumes.

The other thing that kinda surprised me a few years ago, when I started looking into the issue in a bit of detail. If you haul out the datasheet for the fx2, and any given sensor inside the camera, there really is only one way they can be wired together. The example I was looking at then was the qhy5, and when you look at the data sheet for the Mt9M sensor, and the fx2, you quickly come to the conclusion that there are only a couple questions to be answered. Is the data path wired up with only 8 bits between sensor and fx2, or, did they wire up all 10 bits as a 16 bit shift into the fx2 usb buffers ? the other questions, which gpio are used for the autoguider ports ? If one answers those two questions, then it's not a terribly difficult project to write a firmware for the fx2 that makes the unit functional. for higher end cameras, there would be a few more questions to answer, regarding how the cooling is implemented. But again, it's one function to read a temperature somewhere, then one of the digital io pins that turns the cooler off and on.

When I started really digging into it, I was quite surprised to realize, all of our astro related cameras are an fx2 with a sensor. That's the SBIG ST-10 we got as part of a package deal when we bought an observatory lock stock and moat, as well as our SX cameras we had prior to that, and the qhy cameras we had for guiders. And as it turns out, the Meade DSI is 'yet another', altho I didn't realize it at the time.

If I had enough spare time (which I dont these days), I think it would be a fun project to start from first principles and data sheets, then work up some firmware for the various cameras. If one takes the approach of the qhy firmware, just a set of function calls that allow a program on the host to set registers etc, it's quite realistic to come up with one firmware that will work with any fx2 based cameras, and all the camera specific smarts reside on the host computer, where it's much easier to work with things.

Maybe some day, when I have more spare time, i'll start fiddling with that idea. I have more than enough fx2 based cameras here to get a long ways into that kind of a project.

Hello, I am amateur astronomer from Finland. Few weeks ago I lost firmware from Orion Starshoot G3 mono ccd camera. I tried update firmware command and now camera is dead. I have tried to get firmware without succees. PC drivers can be found from web but not camera firmware. It would be nice if someone could send this camera firmware to me.

Hi,
I own a Brightstar Mammut Lyuba L429 which ressembles very much the Starshoot G3 from ORION, and is also based on the AVR32 UC3 chip from AMTEL. I'm looking for an INDI driver for this camera since I can only use it on windows for the time being (ASCOM driver works fine), and I would like to move to Linux (Rapbian).
Did you manage to build you driver eventually ? That would be the last chance I have to make ma camera work on linux
Enjoy the stars,
Emmanuel

No, I'm afraid I didn't end up doing anything towards getting the linux driver going. I was able to get a windows xp virtual machine set up and have just been using that for the camera control. It's not ideal and INDI control would be a lot nicer, but just ended up going the "hacky" windows route.