I did a bit of testing:
No issue with the compile or run. I did have the issue with it not finding the camera in localhost mode with the indiserver running locally, but it operated properly when I switched to remote and left localhost as the machine name, as it did with Christian.
Operating the camera from the indi control panel in kstars, I had no issue taking images. However, due to weather I was not able to connect to the scope. I did verify a dark and a flat. In both cases the image was displayed in the FITS viewer. The flat looked OK, but the dark was all noise and seemed over-gain. I did play with the gain setting, and it made no impact on the dark, though it worked as expected with the flat. I could not reproduce the crash Christian reported, though the difference could be using the Indi panel rather than Ekos.

I may try and image via Ekos tomorrow night if I can get the scope outside. Could be just pictures of clouds, though.

This was running on a x86_64 under Ubuntu 20.04 and the latest kstars-bleeding.

I did a bit of testing with Ekos instead of Indi Control Panel. Flats still seem to work. No lights yet (due to weather). Darks still look over-gain, but apparently that is something to do with the Kstars viewer. I saved the Darks fits file and opened it in GIMP and it was a perfectly acceptable dark image.

No crashes. Live view is apparently disabled.

Hello Blaise,

good new ! the drivers work fine for me now. I had a problem with cfitsio. I removed the last cfitio from my /usr/local/lib for use the "official" package.

if you need help for coding or others things, i'm ready for help.

Christian

Hi Jon,

Thanks a lot for your help !

You're right, live view isn't implemented yet.
Happy to see that most of the features work.

I did some darks test also, after your message. I think you're right, it's due to the fits viewer. It stretchs the frame's pixel values at display.
Darks only have noise, so, it amplifies the noise. I get the same noisy pictures as you, but if you look at the picture's histogram, "mean" and
"median" pixel values are very low.

Just pushed some new commits :

- a bit of code cleaning
- subframe buffer optimization
- sometime got junk frames after gain change : fixed

I also added a libreoffice calc file to record all test feedbacks

Missing features at his time :

- binning
- live view

Thanks again, and have a nice day (or night )

Blaise

Hi Christian !

Thanks ! Great news !

So, the driver works for three of us.

If you want some coding work, I have troubles using the native SDK ROI (subframe) and binning features.
Every time I change the resolution, it fails. I have to do it by software.

Do you already have the SDK documentation ?

At this time, my code is a bit dirty. Code reviews would be nice

Thanks for your help.

Best regards,

Blaise

Blaise,

No problem. Thank YOU for the coding!

With regard to the feature set, and excuse my ignorance of Ekos standard feature set, but I was never able to use it as Ekos has only recently begun to support my hardware: Will there be support for filetypes other than FITS, and specifically, .AVI video? Also, I am used to doing rough color balance, contrast, brightness and saturation prior to image commit (in a liveview environment) or is the plan to capture raw video and do all the adjustments in post processing? I suppose I could see how the V4L module works, but it seems just as easy to ask. And for the record, I am already jumping up and down happy with having it work, so kindly ignore the question if it smacks too much of scope creep.

And yes, I came to the same conclusion about the FITS viewer's motives after viewing the darks image in GIMP. I suppose it makes sense, in a more or less not very useful way. One day, I really must read the instructions.

Oh, and I can help with the code review! Just looked at it...yep...not Java. There...done.

Hi Blaise,

I have a the API documentation. Very poor but she has the credit to exist.
I will try to work on the ROI implementation.
I seen your code and seriously he is clean.
Also, Do you think it's a good idea to propose all behavior of the camera that are "forced" to be programming by users ?

Regards

Hi Jon,

I'm pretty new to Ekos too
Some years ago, I used my own software (qastrocam-g2).
Then, I had a break with astronomy. But I'm back now !

Ekos records video streaming as ".SER" files.

I started to work on the "live view" today.
Hope I will be finished soon.

Thanks for your code review ! LOL

Best regards !

Blaise

PS : 3 years ago, I was in charge of our JEE Application servers. I didn't code a lot in Java, but I did a lot of troubleshooting in production

Hi Christian,

Thanks for you review.

Concerning the hard coded settings, the main reasons are :

- I wanted the driver to be available in a short time
- Some settings are inappropriate for astronomy, especially with INDI.
- In my mind, the SDK has been developed for standard cameras, and then patched for astronomy. Some "GetCapabilities" results are wrong, we can't trust it.

But I'm open to work on these features for the next version.

Best regards !

Blaise

Hi,

Sorry, I forgot to say : binning done (software binning)

Best regards,

Blaise

Hi,

Just pushed the first "stream enabled" version.

I think I will soon ask for a pull request.

There is a lot of possible improvements, but in my mind this first version is usable.

Feel free to send me any comments about my code.

Best regards,

Blaise

Blaise,

I checked binning yesterday. Seemed good. I'll check "stream enabled" today.

I did look at the v4l2 driver using my SV105 as a test. The indi control panel does have a significant image control (hue, saturation, et al) screen. That said, I'm not certain that it isn't a bit buggy, though I didn't take time to do a thorough test of v4l2.

*JC*