×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Support for Orion StarShoot G3 CCD

  • Posts: 22
  • Thank you received: 5
I've had the camera out a few nights now for various lengths of time and have made a few more observations about it.  I wanted to post here to give a bit more feedback on the performance of the driver and also to share a picture that I am reasonably proud of (I won't post many more pictures to this thread since that is straying off topic but this one does fit I think).

Overall, the performance of the driver has been excellent.  I have now taken something like 1000 exposures with the driver and the only lockups I have seen were the ones mentioned above where two expose commands were sent before the first was finished.  The other source of lockups is in taking bias frames.  I was trying to do 0.001 to 0.02 second exposures, and both seem to have resulted in lockups.  Further investigation reveals that it is safe and reliable to shoot very short exposures, however they must be commanded one at a time with a manual wait of something like a few seconds between frames.  I can't say for sure whether this is just Ekos trying to shoot a second frame before the first is fully downloaded, or if there is just something in the camera that is still being reset, even though it is technically "done" with the first frame and the driver therefore thinks it is safe to proceed.  Either way, the problem is not a huge deal, once you know how to handle it, but it is a source of potential lockups which require and unplug/replug that would be a pain on a remote telescope.

On a more fun note, here is the stacked image I mentioned which shows the results of the camera.  This was taken last night using an ETX-90 OTA (a little 4 inch scope) on an equatorial mount.  I have no guide camera so I can only take about 10 second exposures and even then I lose about half of them.  I took a total of 640 10 second exposures.  I have processed 300 of them and 127 were good enough to plate solve and didn't have serious star trails (again, no guide camera -- something which I hope to rectify soon).

P.S. comparing the results to the UCAC4 catalog shows that there are easily identifiable stars down to a bit better than 16.5 magnitude.  Not too bad for about an hour of integration time on a 4 inch scope where more than half of the time is lost to periodic error in the mount and/or wind shaking the tripod.

 
The following user(s) said Thank You: Ben Gilsrud
Last edit: 2 years 4 months ago by Andrew Buck.
2 years 4 months ago #77270
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 0
Dear Ben, I finally found a bit of time to try and use my Brightstar Mammut Lyuba Monochrome camera (deemed very similar to the Orion Starshoot G3) through the INDI / Astroberry platform  on a RPI.
I installed the new indi_orion_ssg3_ccd driver from the package manager, and connected the device. The INDI client loads a Orion StarShoot G3/G4 driver dashboard ("version 0.1 / Interface 6 / Driver Info name: Orion StarShoot  G3 mono 0", which sounds great), but I cannot connect the camera successfully. I get the following error message:
[ERROR]: unable to connect to Orion StarShoot G3/G4: operation not permitted.
The VID / PID of the Mammut Camera is the following (output of lsusb command). I e-mailed these detailed to you some time ago but not sure you got them
Bus 004 Device 003: ID 07ee:0501 Torex Retail (formerly Logware) AVR32 UC3 USB DEVICE
This may be quite straightforward to fix, but I must confess I never came accross such issue. Other (more mainstream) cameras I use through INDI / EKOS are plug & play.
I would greatly appreciate it if you could share some clues.
Thanks a lot !
Emmanuel



 
2 years 4 months ago #77704

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
Hi Emmanuel,
I would start by double checking that the usb device file has the correct permissions. The driver comes with a udev file that should take care of this, but maybe it's not working correctly?

Do:
ls -alh /dev/bus/usb/${BUS}/${DEVICE}

where BUS and DEVICE are determined by the lsusb output (004 and 003 in your output above).
2 years 4 months ago #77723

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
Cool shot, Andrew! It's really neat to see the noise at the edges and see how it gets cleaned up as more images overlap toward the center.

Sorry, I've been a little distracted lately, but I'll get to the changes that we mentioned in the next day or so. The issues you mentioned with the short exposures could be related to timing of the download code. Unless the camera has some external memory, the little microcontroller in the camera can't buffer a full frame so it's possible that it needs the host to be ready (ie, have requested a bulk transfer) before the exposure is done. It's possible that the driver isn't meeting that timing for super short exposures. I think this would be difficult to fix without changing things too much. It would be a lot simpler to limit short exposures to a value that we know works. Any thoughts?

Thanks,
Ben
2 years 4 months ago #77724

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 0
You were just right ! Access rights related to the above file were rw-rw-r.
I added write access to all (file owner and group is root), so I changed file access properties to rw-rw-rw. The camera is now connected, and giving regular pictures with EKOS either as main CCD or autoguider. Cooling is also ok. It's just so great to have this almost unknown camera back to business !
Only trouble is that if I disconnect the USB cable and connect it back again, the device number is updated, and I have to chmod 666 again the BUS/DEVICE file. There may be a way to avoid this little pain.
2 years 4 months ago #77746

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
I'm glad to hear it works!

How did you install the driver? It should come with a udev file (99-orionssg3.rules) to automatically set the permissions, so I'm not sure why that's not working.
2 years 4 months ago #77749

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 0
I installed it through the package manager under the raspbian / astroberry environment, searching for INDI, and locating the orion g3. No git, no .deb execution, no compilations...
I'm really not a linux expert, sorry about this. Where is the file you mention supposed to be located ?
2 years 4 months ago #77750

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
I finally got around to implementing binning and subframing. To try it out, do:
git clone github.com/bgilsrud/indi-3rdparty.git
cd indi-3rdparty
git checkout ssg3_updates

Then you can build the drive like you normally would. I don't have one of these cameras, so I can only simulate how I think it should behave and I was able to see the USB sequences that I was expecting. I think the most useful test would be to take a recognizable image with binning enabled...there's a good chance that the frame will be reassembled incorrectly. The code will still attempt to deinterlace the downloaded image, which I'm thinking is not correct when binning is enabled.
 
2 years 3 months ago #78151

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
I think the file should be at /usr/lib/udev/rules.d/99-orionssg3.rules. Do you still see this problem after rebooting?
2 years 3 months ago #78152

Please Log in or Create an account to join the conversation.

  • Posts: 22
  • Thank you received: 5
I got your code cloned and built.  I am trying to shoot some recognizable images with it but since it is mid-day here I need to do short exposures to avoid maxing out the pixel counts.  This means that the issue with short exposures that I mentioned before is rearing its ugly head.  I will try to get some properly exposed subframed and 2x2 binned images and/or captures tonight and let you know how that part of the code is working.  In the meantime though here is a packet capture of the problematic 0.25 second exposures.  I took a first exposure, which seemed to download just fine, then waited a few seconds and tried a second one.  The second one downloaded but it paused for a really long time during the download. Hopefully this capture has what you need to figure out why this is happening.  In any case though I will investigate the subframing/binning code tonight when it is a bit darker.
2 years 3 months ago #78167
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 153
  • Thank you received: 29
I pushed another branch called bin_no_deinterlace. This has the same changes as the other branch and an additional change to not deinterlace the frame if y-binning is enabled. I think this will work better, but I it would be nice if you could test both and find out for sure.
2 years 3 months ago #78170

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 0
I Ben, I copied this file from the web repository into the above folder and everything seems to be working now. Great !
2 years 3 months ago #78324

Please Log in or Create an account to join the conversation.

Time to create page: 0.814 seconds