×

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

Bi-monthly release with minor bug fixes and improvements

sx_ccd_test version 1.8 fails with LIBUSB_ERROR

  • Posts: 10
  • Thank you received: 0
Ok, the change I mentioned did remove the space as Peter mentioned. And thanks for the great input Gerry! I have the device mounted now where I want it. Gerry, from what you have mentioned earlier I guess there is no control of the heater in the camera software? I had though it might be in there but had not looked yet.

So far in the Arizona sunshine it is very unhappy during the day. There is only maybe a patch of 100x200 pixels that are not saturated. While I do not really have to have daylight exposures they would be nice, I may poke around more on that.

Is it true that the minimum exposure length is 0.01? It did not seem to work under that. anyway to clear the ccd prior to readout by shifting the charge into the bit bucket?
Thanks again all! Ted
8 years 5 months ago #5298

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

  • Posts: 193
  • Thank you received: 46
Using my older drivers installed on the one outside, I just did a grab with exposure time set down to 0.0001, which probably translates to zero once it's inside the camera, ie it will flush, latch, then download with no delays. This is what came out, it's sitting in full sun.

File Attachment:


As you can see, the sun causes terrific blooms, as do a couple of the brighter reflections.

When I was experimenting a couple years ago, I did try grabbing just a few scanlines at a time with that setup, and I was able to get them without much blooming, except for the sun itself being totally wiped out. At the time, my thoughts were, a smart program can look at the exposure, see it's way overexposed and bloomed, then switch to a mode that builds individual frames by doing zero length exposures and just grabbing a few scanlines at a time, then glue them all together into a single frame.

It's on my to-do list, but, it'll be at least a couple weeks before I get that far down into that list.
Last edit: 8 years 5 months ago by Gerry Rozema.
8 years 5 months ago #5299

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

  • Posts: 193
  • Thank you received: 46

It is an interline ccd, and yes, it is possible to flush the latches prior to latching the data from the light sensative half. My experience tho, in bright sunlight, it still blooms and bleeds over into the latches during the time it's being read out, unless you only do a very small portion of the chip at any given time.

I haven't looked at the current implementation, but, when I originally wrote the first sx driver, the process went like this.

Flush at the start of exposure.
For long exposures, flush the latches a very shot period before latching data, to clear the latches one more time. This process takes a finite amount of time, and for short exposures you cannot do it, hence the need to flush prior to exposing.
Latch data and start readout

For very short exposures, use the on camera timer, and for longer exposures, use the pc for timing of the latch / readout cycle.

Still working on getting my base load functional for my cubieboard, once that's done, I'll be re-visiting the driver for oculus to get one thing in that I want for meteor detection.

Hehe, this conversation may inspire me to visit daytime exposures sooner rather than later....
8 years 5 months ago #5300

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

  • Posts: 10
  • Thank you received: 0
Ok, I have the camera on the sky this evening, and things are generally working. I do not think the current driver will go below 0.001 exposure time, not that I think that will help me much in the daylight. I poked around a bit but did not find any gain control.

Clearly I will need to drop exposures some for moon rise and phase, which is not happening tonight! I will have the images to make a movie in the morning, it is taking 30 second images rough;y one per minute. But the moon will look bad with what I have tonight. Images are quite nice under ds9 with -histequ while the moon is down though. Probably should not have got the 180 lens.

The remote computer seems to be working just fine with the wireless link back to another computer for file storage. I have my script do a mv on the images after they are stored locally. I'm running a vncserver on the box that is doing fine also. Not bad for night #1!
8 years 5 months ago #5301

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

  • Posts: 193
  • Thank you received: 46

It was true, but it isn't anymore. I found how that ended up the case, and added one code line into the sxccd.cpp to change that. It'll now accept up to 4 digits, ie, 0.001, which is shorter than the hardware can do, so that will break down to a zero length fed into the camera for exposure time.

I did manage to commit this change back too, seems my old account on sf still works.

It gives a much more useable daytime image than I was getting before. Driver code has changes substantially, it'll be a little while before I get to seeing if I can improve it any more than this. I've still got two more mounts to get running properly in the next few days.
8 years 5 months ago #5332

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

Time to create page: 0.935 seconds