• With camera unplugged started wireshark
• Plugged camera in
• Started EKOS
• Took 1 second exposure
• stopped wireshark

Same result as before. [Error] Starting exposure.  As before Fits viewer shows blank image with one white line across top of frame.  Fails on taking a further exposure.
I opened a FITS image captured with Orion Studio in the EKOS FITS viewer and it looked good.  When we capture an image at least I know it views OK.

Thanks, David! Well, even though we didn't capture a good image things are looking much better. All of the commands that we are sending are now successful.

It does look like we even got a full line in the download (timestamp of 50.505164). I guess we still need to figure out why we're not getting it all. I'm thinking that it may be a timing issue. I notice in the OCS capture that a request for bulk data is sent well before the exposure actually completes. That might be a signal to the firmware that it should send the data over USB. Otherwise, maybe it thinks nobody is listening and just discards the data? In the capture that you provided, we sent the 1s exposure request at 49.44 and the bulk request (for the download) at 50.50. 60ms is significant in microcontroller time

I just pushed a quick change that I'm hoping will fix the issue with the download. I basically modified the driver so that it should start the download earlier (up to a second earlier) than it previously did. This isn't a great solution and is really just an experiment. If it works, I think it might be better to use libusb's asynchronous IO interface.

Ben, I did a fetch and got 4 objects, compiled but not sure if anything much changed. /usr/bin/indi_orion_ssg3_ccd still has yesterdays date. What's the best way to check I am running your latest change? I could of course delete everything and do a clone but would like to use tools like fetch to keep my install up to date.
Asychronous may be the way to go. I notice wireshark log for OCS says something like "left over data" when a line of data is transferred from the camera. Is this text coming from the firmware or generated by the snooping software?
I have written a note to Orion to ask for a technical spec. for the older camera firmware interface. I don't hold up much hope of getting anything but if such a document exists it would take the guesswork out of the equation.

... Orion camera Studio package installs an ASCOM driver and this works with Sharp Cap. Can this help with writing the INDI driver?

Hi Ben, To be sure I cleared out repository and did a clone. Ran the same sequence. Logs attached.  Looks the same as before., just one line an the error starting exposure.

Thanks for the capture! It looks to me like we did submit the bulk request before the exposure completed, which was the intent of my latest change...but it still didn't help a whole lot. I went and looked at one of the OCS dumps and notice a pattern.

When using OCS, there is a single bulk request made immediately after the exposure has begun (even for the 100s exposure that I'm looking at). The camera will respond in 2 seconds saying it doesn't have any data (URB status says -ENOENT) and then OCS will immediately send out another (single) bulk request again. This repeats until the capture has completed, at which point OCS will continue to submit bulk in requests and the camera will send the data.

The capture of our driver shows us sending 54 bulk in requests starting 29.2s after the 30s exposure has started. We (libusb) doesn't wait for a response before sending the next request. We get the first response from the camera 0.8s after we sent the first bulk in request. This is in line with the 2s request/response that is observed in OCS. The first response contains image data! But, the URB also shows -EREMOTEIO. I think this is a message that the USB layer thinks it's received all of the data that it's going to.

While writing this, I think I've figured out what's happened. libusb is submitted 54 bulk in requests because we told it we want 875328 bytes. Our URB size is 16k (I don't know what controls this yet), so it would take 53.4 urbs to store the data...which means 54. Instead of telling libusb to download all of the data at once, it seems we should do individual requests for each line. If only someone had mentioned that earlier  ... 

I just pushed some code that implements this. 
 

Unfortunately, the ASCOM driver is likely only useful as a means for reverse engineering. It might give us the ability to do things that aren't possible in OCS using some other tool (like ST-4 control??).

Step 1 probably should've been asking the vendor for documentation. I sometimes forget that step because I've not had good luck with it in the past. Thanks for doing that.

As far as how to be sure that you're using the latest code, you could probably use the following sequence:
cd indi-3rdparty
git pull
cd /path/to/your/build/dir
make clean
sudo rm $(which indi_orion_ssg3_ccd)
make
sudo make install

So far, all of the dumps that you have provided have appeared to have shown the changes that I was hoping to see.

Here's logs with latest change.  Sadly still only one line or at lease thats how it looks.  

Well, I think I jinxed it because that log doesn't show the latest changes. And I just realized because I forgot to push them. They're there now...and I'm optimistic about this!

Hi Ben.  Yes almost there.  I now get exactly half an image! I have attached the logs and the image which should be an over exposed image taken with a semi transparent plastic cap over the camera nosepiece. The top half looks like what you would expect but the bottom half is black. I haven't had time to study the code in detail but I notice line 487 loops for ssg3->y_count/2.   

I have to say you are extremely good and as quick as I could expect in responding to this development.  I am away for a few days and back on Tuesday to continue testing if you are available then. Will try to find time to dip into the forum. Nice work. Cheers Dave

Thanks, Dave! Yes, this seems to be working well. I see the bug, which is annoying because I fixed it a few days ago...but I must've clobbered those changes somehow.

There's plenty of cleanup to do on the driver side so I have plenty to keep myself occupied Enjoy your time away.