No, I just wanted to know if it would live stream on the off cahnce I want to use it to just view objects rather than photograph. I sometimes do that and wondered if it would be possible remotely in the comfort of my home. I access the equipment remotely using VNC. Just curious is all.

Hey everyone.  I am the one who originally started this thread years ago.  I am amazed to see the work that has been done in the meantime on getting the G3 supported and wanted to say thank you to everyone who has contributed.

I have set up a build environment on my laptop and built both INDI from source as well as the 3rd party driver collection from source as well (building the drivers requires INDI to be built from source right now because the libindi-dev package is apparently missing a bunch of headers which were refactored recently).  The code compiles and loads correctly, however I am getting some bugs with the camera (the one you have been developing against is the G3 color model, mine is the G3 monochrome).  The camera operates well enough to capture a few frames, but every 3 or so frames the camera locks up and needs to be unplugged and plugged back in again.  Also, in the downloaded images every other line is reading a zero value for every pixel.  So half the lines are correct and the other half are zero (like an interlaced frame with one subframe dropped).  This doesn't actually surprise me all that much because the images I have taken in the past have all appeared "interlaced" where the camera is clearly reading half the lines, and then going back and reading the other half so every other line is a bit brighter than the ones on either side of it.

I think both the camera lockups and the zero lines are both from the same issue, and I suspect it is an easy one to solve.  My suspicion is it is just due to the color version having more pixels to read even though the resolution is the same due the the 2x2 bayer matrix.  I am going to try poking around in the code a bit, but wanted to post here with a description of the issue just so others with more knowledge can have a look in case it is obvious where to start.  Ideally I would get some usb captures from a windows box, as has been done for the color camera, but all my computers are linux only.  I have a friend with a windows machine so I might try to get usb packet dumps from that but going to bash at the code a bit first and see if I can just fix it directly.

Thank you again to all of you -- this thread is a beautiful example of open source development and showing how people can do things for themselves, rather than just waiting for the company to support it (which it looks like Orion doesn't plan to).  I will post an update later today with what I have learned (maybe not much since I haven't done driver work before) and will keep an eye on the thread here if anyone has questions/suggestions.

So I have started poking around in the code and right off the bat I see a couple things.  First is that you have the CCD pixel size as 8.6x8.4 microns.  This disagrees with what is online, both the color and the monochrome list as 8.6x8.3 microns.  Just a minor issue, and not going to crash the camera but it should be changed unless the info online is wrong.

On a more technical note in the orion_ssg3_model struct you declare a 2 element array one for the color and one for mono.  You have 0x7ee:0x502 for the color and 0x7ee:0x501 for the mono with a comment indicating the 501 is a guess.  Unfortunately it looks like this guess (which was perfectly reasonable) does not turn out to be correct.  I will paste a lsusb -vv below.  From what I can understand my monochrome also reports 0x502, meaning we can't differentiate color/mono based on that number.  I don't really know much about the USB protocol descriptors, so hopefully there is something else in there that can distinguish the two.

Here is lsusb -vv for my camera.


Bus 003 Device 007: ID 07ee:0502 Torex Retail (formerly Logware) AVR32 UC3 USB DEVICE
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x07ee Torex Retail (formerly Logware)
  idProduct          0x0502
  bcdDevice           11.02
  iManufacturer           1 ATMEL
  iProduct                2 AVR32 UC3 USB DEVICE
  iSerial                 3 1.0.0.0.0.0.A
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             100
Device Status:     0x0001
  Self Powered

Ok, so a bit more exploring and unfortunately the lsusb information that Bob posted looks pretty much identical to mine (after ignoring the whitespace differences.  As far as I can tell distinguishing the difference between the two camera will require actually asking the camera something and looking at the response.

I'm going to try to set up the windows machine with the driver and get some packet dumps.  I was hoping I would be able to figure out in the code but the obvious things I wanted to try have been tried and now I am at the limits of what I can do.  Will post the packet dumps when I get them.  Is there a recommended way to record the dumps?  Wireshark was my first guess, I know this works on linux but not sure if the windows version supports USB.

Ok, I think this dump should help.  I got the camera running under windows and used wireshark for the capture.  The "connect" from orion camera studio happens a bit after the 5 second mark.  A 1 second exposure starts around 11.37 seconds and data starts coming back at around 12.25

I poked around in the packet dumps a bit.  Again take all this with a grain of salt, since I don't know a ton about USB but in the color packet dumps I see a bRequest=20 packet going out and then a control response data of 02 comes back.  On the mono camera (mine) I see 20 go out and 01 comes back in.  The bRequest=20 is SSG3_CMD_UNKNOWN_STATUS1 in your driver.  So that might be the distinguishing feature between the cameras.  Hope this helps, but don't put too much faith in it since like I said I am totally new to this.

Hi Andrew. Have you communicated with Ben Gilsrud. He has done an excellent job of getting the driver as far as it's got.
I have a color version and used it with Indi and done some testing to help Ben debug. I would like to know the issues you see and can confirm if I see them too.0

I haven't spoken to Ben, just made the post here in the thread.  I am guessing he will see it since he is probably following the thread.  The issues are the ones I mentioned in the post this morning (about 4 posts back now).  The camera seems to work ok, just gives every other line and crashes after a few images.  I think it is due to something like a memory out of bounds error, as it is probably trying to read pixels that are in the color version but aren't in the monochrome.

Thanks for the info and the dump, Andrew!

I believe that the G3 color and mono use the ICX419AKL and ICX419ALL, respectively. They have the sample pixel layout since they're the same chip (just one has a color filter array on it).

I'm assuming that you're able to capture an image in orion capture studio and it looks fine, right? Any chance you could get a wireshark dump while using the indi driver?

I've compared the wireshark dump for the mono and color G3 cameras and don't see any obvious differences in the image download. I think you might be right about command 20 being the way to distinguish color vs mono. As it turns out, VID/PID 0x07ee/0x0501 is the identifier for the Mammut Lyuba L429 camera, so I can fix my guess. You're also right about the geometry of the pixels being of by 1nm. That wouldn't cause the crash, but it should still be fixed.

It might also be helpful if you could get a backtrace as described in section 3 of this guide .

Ok, so this is the weirdest thing...

I installed wireshark on my linux laptop and added myself to the wireshark group so I could do packet captures.  I then restarted the computer and tried doing a packet capture of a frame and... it worked just fine.  No weird blank lines, no crashing, no problems at all as far as I can see.  I have spent the last 20 minutes or so in ekos capturing images and after aproximately 100 frames it hasn't crashed or had any problems at all.  I have no idea why it suddenly started working, other than that restarting may have reset something, but in any case everything seems to be working just fine now.  I did one frame with wireshark running and the rest with wireshark still open but not capturing.

So other than changing the pixel size to 8.3 on the Y axis, it doesn't look like there are any changes to make at this time.  (Oh, probably should remove the "guess" on the USB id so it doesn't cause problems for users of that other camera, but that's unrelated to the issues I had).

I'm going to try to get it outside tonight and take some pictures with the telescope, but as of right now it seems to be working just fine.  Thanks for all of your work on the driver, Ben.  I will try to post a couple pictures and an update after tonight if I get a "second first light" from this camera running on fully open source code. 

-Andrew Buck

Success! 

The weather was not great last night, it was a bit hazy with some thin clouds, so the pictures were absolute garbage, but I got a few images of Vega, well enough to focus the telescope and demonstrate that the camera is reading actual data, not just noise or something but nothing worth posting here.  Binning 1x1 works perfectly, however 2x2 binning gives some weird results.  It takes about a minute to try to read out the data.  What comes back at the end seems like it could potentially be reasonable (just testing inside on the table with the 2x2 binning) but I can't say for sure.  In any case though it obviously should not take a full minute to read a 2x2 binned image (a 1x1 bin should take about 2 seconds to read, which it does, and a 2x2 should be about 0.5 seconds to read).

I have attached a packet dump of a 1 second exposure 2x2 bin image followed by a 1 second 1x1 bin image in the same file.  I am also hoping to play around with the cooler a bit today but I can't guarantee when I will have time to do it (might be tomorrow or later this week before I can do any serious testing on that, but I expect that already works anyway since it is the same as the color version).

One other thing I haven't yet tried is taking subframe images.  The options to set the subframe are ghosted out in ekos, so I haven't done anything with that.  Presumably the camera driver is not advertising this capability to indi, but I don't know for sure.  I can't remember if your code supported subframes or not.