Alright, I've updated the code to hopefully solve the issue with the capture. I took a look at some wireshark captures that Bob had previously provided when he was using orion camera studio and I see the the firmware also returns an error when starting a capture...so it must be normal? In any case, I updated the code to ignore this particular error for the "start capture" command. It would be great if you could get a wireshark capture with the update.

Thanks,
Ben

Hi Ben. I have done git fetch then a git diff and a large number of changes reported mostly about other indi drivers etc.  git merge fails with conflicts in CMakeLists.txt. So thought it would be simpler to uninstall and do a clone from fresh but of course there is no uninstall script. I am a bit rusty with git so could you please advise how to be sure I get your latest code installed.   It seems you already have this but ran Wireshark on windows with Orion Camera Studio to capture a 30 second exposure.  Thanks David 

If you're on the orion_ssg3_driver branch, you can just do "git pull" (which is essentially just a fetch/merge). There won't be that many changes. At least as far as this branch is concerned, you don't have to worry about uninstalling anything. You can just install over what was previously installed.

Thanks for the additional capture. I think we're getting close to getting a successful image.

Progress Ben! It now attempts to take an image and Fits viewer comes up to display image. Rushing out for a while but will take some logs tonight. Looking at the image I see a bright narrow line across the top of the image but the rest is black. With a 30 sec exposure and camera pointed at monitor I would have expected a very white image so suspect it's only capturing the first line or not registering new lines. The LED is off in the back of the camera after imaging and errors when a second image is attempted so I can only assume its not being reset properly?

Hi Ben. Here's the wireshark and indi logs. Did a 30 sec exposure then a 20 second.

OK, it looks like the data wasn't actually available for download. I just pushed an update to more closely mimic what OCS is doing when it starts an exposure. Could you run it again and grab the same wireshark capture and log? Thanks!

Looks the same Ben. Did a 30sec followed by a 15sec exposure. 

Does libusb_bulk_transfer only get one line?  Should we loop for each line and call it? 

A single call should be enough. I see an issue where the camera is not responding to the control requests that we're making to start the exposure. I think this probably explains why the exposure isn't actually occurring (which would explain why there's not data available when we attempt to do the bulk read).

An example of this is the "set binning command" (bRequest == 13). In the captures with our driver, we see the camera responds with an error (-ENOENT), but this is successful when using OCS. I've compared the commands and they're identical, which leads me to believe that there's some additional setup that we're missing.

It might be helpful if you could get a wireshark capture of the following sequence.
1. unplug camera
2. start wireshark
3. plug in camera
4. open OCS
5. Take a 10s image

Thanks!
-Ben

Here's the wireshark log for the sequence as requested. Is it coincidence that the number of bytes got is exactly one line?

Hi Ben, I notice in the ocstest log I just sent from line 224 to 1386, there are 582 URB_BULK in. That's of course the number of pixel rows in the y? Each URB_BULK_IN  is 1531 bytes and the actual data length is 1504 bytes which equates to 582 pixels per line in x. 
I assume libusb_bulk_transfer only needs to be called once and doesn't return until all the requested bytes have been returned by the camera in multiple URB_BULK_IN transfers. I am confused about the role of the requested data length of 875328 bytes because surely the camera knows that? A subframe will be less of course.
The data bytes returned in the latter half are all ff which is strange because I would have expected all pixels to be overexposed.  Maybe the camera doesn't simply return the raw pixel count although I would expect it would to be scientifically useful. I will take a focused image through the scope tomorrow that is properly exposed and check it out in wireshark.

Yes, it certainly makes sense that the firmware would send the data a line at a time. The micro doesn't have enough RAM to buffer an entire frame and chunking it line-by-line seems like an obvious choice. I'm pretty sure that we only need to call libusb_bulk_transfer once and that it will either return after the timeout or after it's read the number of bytes that we want...regardless of how the bytes were chunked up. That's the point of the "needed" variable (875328) for the libusb_bulk_transfer call.

I actually think that the firmware doesn't know much about the sensor. The driver needs to tell it the geometry of what we want it to read out of the sensor. It's possible that this same exact firmware can support other cameras (maybe like the StarShoot Pro V2) by pushing all of the sensor knowledge up to the driver.

In the frame that was captured in your OCS dump, it appears to me that all of the pixels are, more-or-less, saturated.

I pushed a change that I'm hoping will be the key to making this work. I noticed in your OCS dump that there's a USB SET_CONFIGURATION command that we aren't explicitly doing (I'm not sure if linux would've automatically done this). It's very possible that the firmware takes this as a cue to initialize. This could explain why the commands that we were sending were failing.

When you test this, could you follow the sequence that you did above (unplug, start wireshark, ...) but using Ekos (or whatever INDI client you are using) rather than OCS?

Thanks!
Ben