Recently installed libindi1.1.0 on a Slackware 14.1 box. I am trying to get our brand new Oculus Starlight Express camera running for our observatory. The camera will work under Windows 10. However when I try and get it going at a very basic level under Indi it fails.
When I run sx_ccd_test I get the attached output. Any ideas where I may have gone wrong?

Hmm, it seems, that sxGetBuildNumber still doesn't work for all cameras Are you able to compile the driver from source code? If yes, can you comment out lines 78-79 from sxccdtest.cpp? Peter

Ok, I have done that and recompiled. I am telecommuting today, and if I can get someone to switch the camera connector to my linux box I will report the results. Otherwise it will get tested Tuesday morning.

Thanks for the reply! Ted

Ok, that worked very well! I got a support person to connect the camera up and now it succeeds, output attached. Now to get it reading!

Thanks again! Ted

Ted, did you tried it also with INDI driver? sx_ccd_test is testing just interface library, not INDI wrapper itself. Peter

I have been using indi 0.9x for a couple years with our oculus camera. I haven't plugged it into a recent build for some time, it's sitting in a spot where it's difficult to reach the computer it's plugged into. One of the items on my 'to-do' list for today, is to test oculus with my latest greatest builds on a machine I have here.

I'll let folks know on this thread how it goes in a few hours, after I've done some moving of gear and plugged it in.

Ok! I now have it working with the INDI driver, after a bit of fiddling. I used the attached script which will probably be the bottom end of my sky camera. Gerryr! It was your posts on this camera that caused me to buy one, what you have been doing looks fine to me. If you have any further pointers or examples I am all ears....

Thanks all, I can probably move the camera to a more interesting location than looking at the ceiling in my dark office!

This will be in a linux box on a UPS with a wireless connection for lightning protection. It will also read a Boltwood cloud sensor, and I will put the info on our web site for use by all of our telescope. We have a nice home brewed sky camera on the summit, but it has been having a series of problems lately and I thought a commercial spare was in order. When I get things all done I will post back with the results.

Cheers from Mt Hopkins!

Hehe, interesting to hear folks buying stuff because of my work with it, in particular when I google 'mt hopkins' and realize where that is.

I have written a very crude program for the oculus, which I plan to clean up over the next few weeks. What it does is continually take exposures of 10 seconds, then stores them all as fits files. After each exposure, it also runs a script, which uses convert --normalize to create a jpeg, then that jpeg gets dumped onto the 'what our sky is now' page on an internal web server here at the house.

I did a quick kludge to the sx driver some couple of years ago, which never got committed into the svn because we had to take things down to move, and I lost the ability to continue testing for some time. The kludge was specifically for use in meteor detection, and I'll get it into the repositories soon. It takes advantage of the fact that occulus is an interline camera, and works like this.

Timestamp the end of each exposure when the data is latched into the readout registers. If the next exposure comes before 'exposure time' has elapsed since the last latch, do NOT flush the sensor, and consider 'last latch' as the start of exposure for this one. The net result is, successive images are back to back, with no exposure time lost due to the time taken to download data from the camera. It worked well for me, and after we got set up here and I got it running again, I've seen numerous times where we caught the beginning of a meteor streak on one frame, with the end on the next frame.

I did fuss with oculus a lot when I first started using it, and eventually settled on using 10 second exposures at night. At 30 seconds, you can see star trailing in the images. Mine was set up (still is) on a very slow wifi link, so using shorter exposures there isn't always enough time to get the images across to the storage computer before it's time to start the next exposure.

In the very near future our wiring project to the back field will be completed, and then it'll move back there onto a post. I will have gigabit fibre to the base of the post. Current plan is for oculus to be connected to a cubieboard, which has a wired link into the fiber network.

We are in the mode of 'rapid ramp up' on our astronomy hobby here again. I'll commit my oculus programs back into svn as an example program once I've done a little cleanup, and get everything up to 'latest / greatest' builds.

OK, thank you, Peter

Ok, tested. I just did an 'svn up' then rebuilt to make sure I had 'latest / greatest' code. Built from svn 2474.

It's installed on an atom based netbook, 32 bit, vivid install, and the oculus generated a frame as expected. As per normal, in bright sunlight, it blooms badly, but this camera has always done that in bright sunlight.

Gerry, I am always checking new hardware for linux support before I purchase. And when I Googled "Oculus sky camera linux", guess who I found!

Anyhow, once I get the camera on the sky I will determine if I need to set exposure times based on time of day and moon phase. And probably produce a contrast stretch. Then I plan on just banging away with an exposure around once a minute, 24/7. That exposure will get displayed on the web site, as current sky. Then there will also be a movie of the last night's exposures in case the users want a review after the fact.

Thanks again folks! I will post again when I have something of interest.

I only have a crude system running right now, but we do plan to do a LOT of enhancement over the winter.

a) Daytime exposures bloom but I found a work-around. Do very short exposures, then download only a half dozen scan lines. Seems most of the bloom actually occurs during the image download. It's possible to glue many of those small bits back together and create a reasonable daytime image.

b) Moonlit nights, yes, shorter exposures are needed. We have essentially ignored that here for now.

My longer term goal for occulus is a much grander system, where exposure time is adjusted on the fly to account for light conditions, and frames are analyzed on the fly to become inputs into other parts of the overall system, including things like detecting cloud cover etc.