×

INDI Library v1.9.8 Released (29 Sep 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Support for Orion StarShoot G3 CCD

  • Posts: 22
  • Thank you received: 5
I'm going to bring the scope out tonight again and the weather looks a lot better.  Hopefully will get some images that are worth posting (not just a single white dot on a black frame like the other night.  :)

The binning is defnitely worth adding.  Due to the way the interleaving of the lines work, in 1x1 mode you get every other line looking brighter than the others.  Also, the camera would work well as a guide camera since it has the st4 port and is quite sensitive, and in a field with faint stars the binning really ups the SNR (also cuts the 2 second readout to 0.5 seconds which makes the response time a lot better in guiding applications.  If its not too much trouble to add I would really appreciate you taking the time to do it.  I am not completely sure how to go about implementing it.  I know its not terribly hard, but it would take me a lot of time to figure it all out.

Subframing would also be nice for the guiding reasons mentioned above.  If you stick in 1x1 binning mode, reading just the portion of the frame where your guide stars are really helps the readout speed.

I'll try to keep an eye on the fan tonight and see how it operates in a real setting with the cooler actually running in a real environment.  I expect you are right about the cooling being micromanaged by the onboard uc, however I did notice that odd fan behaviour the other day and that is what made me doubt this a bit.  I don't seem to remember it running that way in orion camera studio.
11 months 6 days ago #77028

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

  • Posts: 148
  • Thank you received: 24
I'll take a look at implementing some of this over the weekend. I think the illumination differences between the even and odd field would only occur with short exposures since the readout time would become insignificant at longer exposures. I don't have this camera, but I do have a Meade DSI I which also has an interlaced sensor and see this same thing. I do agree with your point regarding the readout time. 2s is crazy for a sensor that small and would make it almost useless for a guide cam.
The following user(s) said Thank You: Andrew Buck
11 months 5 days ago #77046

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

  • Posts: 22
  • Thank you received: 5
Well, I got some pictures.  :)

They aren't super nice because my mount is not great at tracking and I don't have a guide scope/camera so I am limited to about 10 second exposures.  All that being said though, the camera (thanks to Ben's hard work on the driver) is working nearly flawlessly.  The only issues I really had during the night were a couple camera lockups when ekos told it to take a preview frame while the target scheduler was still active (so the camera got told to take a picture while it was in the middle of an exposure).  The driver could be made to handle this, but honestly that feels more like something indi should be handling (return with an error code "hardware already busy" or something like that to the calling routine).

As promised though, here are some pictures.  The first image is a single, uncalibrated 5 second frame and the second is 15 frames that were caibrated with a master flat from last night but dark and bias frames from 5 years ago (because I forgot to take new dark/bias frames last night -- shame on me).  The stacking was done by astropy, with the frontend to astropy being a website I am developing to store and process astronomy stuff.  The website is not online yet but it is running locally on my laptop while I develop code for it.  So these images were take using open source control software (kstars/ekos/indi), using an open source camera driver (provided by Ben), stacked using the open source astropy with stacking controlled by an open source web interface written by me.  That's a lot of open source goodness.  :)

Anyway, here are the images.  I am looking forward to getting back out again tonight to do a bit more experimenting with my setup (I forgot to try any temperature control stuff last night, was too busy working out the rest of the stuff and learning to use ekos more efficiently).

 

 
The following user(s) said Thank You: Ben Gilsrud
Last edit: 11 months 5 days ago by Andrew Buck.
11 months 5 days ago #77047
Attachments:

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

  • Posts: 147
  • Thank you received: 10
Hi Andrew. Good to see your getting some images. I had a lockup the other night when using a QSI camera. I was continuously running the camera using the loop function and tried to use the plate solve at the same time so 2 simultaneous demands on the camera. I would have thought Indi or Ekos (not sure which is best placed) would have a generic check to stop this. "Sorry, can't plate solve camera already in use". Needs a further test because I am sure I have seen a warning in the past.
11 months 5 days ago #77048

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

  • 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: 10 months 4 weeks ago by Andrew Buck.
10 months 4 weeks 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



 
10 months 2 weeks ago #77704

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

  • Posts: 148
  • Thank you received: 24
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).
10 months 2 weeks ago #77723

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

  • Posts: 148
  • Thank you received: 24
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
10 months 2 weeks 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.
10 months 2 weeks ago #77746

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

  • Posts: 148
  • Thank you received: 24
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.
10 months 2 weeks 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 ?
10 months 2 weeks ago #77750

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

  • Posts: 148
  • Thank you received: 24
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.
 
10 months 6 days ago #78151

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

Time to create page: 1.012 seconds