×

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
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
The following user(s) said Thank You: Ben Gilsrud
11 months 5 days ago #76890

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

  • Posts: 22
  • Thank you received: 5
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.
11 months 4 days ago #76925
Attachments:

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

  • Posts: 22
  • Thank you received: 5
Just a real quick post on the temperature stuff before I head to work (will do more detailed testing later).  The temperature controls seem to work as expected with one slight oddity.  At least in my initial testing it appears that the fan speed is exactly inverse of what you would expect.  The fan seems to idle down when the temperature is dropping (i.e. the peltier cooler is engaged at full power) and the fan speeds up to full power when the cooler is turned off.

I think there were some other control channel id numbers that you thought were related to the temp controls.  I am wondering if the peltier power and the fan speed are set as two separate things.  If that is the case I also wonder if there isn't a second temperature sensor on the "hot" side of the peltier in addition to the one on the ccd which you are already reading.  If that is the case it might be possible to run the peltier and still keep the fan speed fairly low until the peltier itself starts heating up at which point the fan can be sped up as needed.  Of course all of this is just speculation.  As mentioned I hope to do some more detailed work on the temp control testing, but wanted to give you these initial results right away in case you had any ideas, etc.

The other thing for future work as a "nice to have" is that right now, the cooler seems to flip between 100% power and 0% power.  A better way would be setting the power based on how far away we are above the desired temp.  A formula something like

10% + 10%*x

where x is the temp (in C) that the ccd is above the setpoint.  Basically if its above it runs at at least 10 percent power, but ramps up the farther away it is.  This way as it comes down to temperature the cooler idles back so you don't "overcool" the sensor.  That should make the temp much more stable instead of "hunting" around for the correct value.
11 months 4 days ago #76926

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

  • Posts: 148
  • Thank you received: 24
I'm glad that you were able to get some images out off it!

I started to implement binning and then put that on hold. I just double checked and see that the driver is still advertising binning support, which was not what I intended. Binning could be added without a lot of effort, but I wondered how valuable that would actually be given that the sensor is small and the pixels are already pretty large. But, someone who's motivated could do it :) Subframing is also not supported by the driver, but we understand enough of the camera control protocol that it could be.

I believe that the cooling is a setpoint-style interface. That is, the driver tells the camera the desired temperature and the camera is responsible for adjusting peltier power and fan speed to achieve the desired set point. The G3 hardware can only cool down to ~10c below ambient. If you set the cooling to something like 5C below ambient I would expect that you would see the power spike and then decrease as it reaches the setpoint and maybe settle somewhere around 50% (+/- 20%). You could also try experimenting with cooling in the orion capture studio and see if you see the same power/fan behavior. I suspect that the fan is controlled by the uC on the camera rather than through the driver. At least, that's what I would do if I designed the camera. Also, I don't think there were any write commands whose function wasn't figured out.

I would love to see what you were able to image with the camera!
11 months 4 days ago #76929

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

  • 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 2 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 1 day 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 1 day ago by Andrew Buck.
11 months 1 day 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 1 day 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 3 weeks ago by Andrew Buck.
10 months 3 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 1 week 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 1 week 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 1 week ago #77724

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

Time to create page: 0.830 seconds