It's been about a month since SVBONY's new cooled CMOS camera SV405CC was released.
The camera driver made by SVBONY has also been renewed, and it seems that all the problems that were initially worried about have been solved and everyone is starting to use it.

On the other hand, the Stellar Mate that I usually use for astrophotography is not compatible with SV405CC, so I can't start shooting immediately.
That's why I made SV405CC compatible with the INDI CCD driver used in Stellar Mate.

Many have written feature reviews for the SV405CC.
Here I will write about his SV405CC support for his INDI CCD driver using the SVBONY Camera SDK.
When asked if the driver development was a review of the SV405CC ...

But how many years have you been writing a blog? I feel like I haven't written it for more than 10 years.

As of July 8, 2023, the initial code has already been merged into the indi-3rdparty repository. It is available if you can build it yourself.
Additional code has been pulled to his GitHub, but it doesn't seem to go smoothly because it overlaps with the version upgrade of INDI itself.
Please wait a moment now.

environment

First is my shooting environment.

I mainly shoot on the balcony, and I shoot warmly in winter and cool in summer by connecting remotely from KStars on my PC to INDI of Raspberry Pi.
Below is a software diagram of my environment. The left side is the environment of Raspberry Pi, and the two places where SVBONY Driver is written are the INDI drivers supported this time.

KStars is a planetarium software, and EKOS is an astrophotography control program built into KStars, which has a GUI.
INDI is a program that does not have a GUI for operating devices.

Building a development environment

The INDI source code is available on GitHub.
Drivers for SVBONY astronomical cameras are included in the INDI 3rd party driver repository by volunteers rather than the mainstream of INDI. First, fork the repository of the indi 3rd party driver on GitHub and create a clone on the Raspberry Pi.
Then proceed as described in README.md on GitHub.
All you need to build is libsv305 and indi-sv305.
No need to build the entire indi-3rdparty.

Code editing, building, debugging, etc. can be done by introducing the Remote Development extension to Visual Studio Code on your PC and connecting remotely from your PC to the Raspberry Pi.
Other Visual Studio Code extensions introduced are Git and C ++.
Rasp pie native Visual Studio Code is not used. It's very heavy for Raspberry Pi.

Development content

Since there is already an indi-sv305 driver that supports SV305 series and SV905C, we will support SV405CC for this driver.
Our policy is to keep the original source code policy unchanged as much as possible.
There are only two source codes to modify.

indi-3rdparty/indi-sv305/sv305_ccd.cpp  

indi-3rdparty/indi-sv305/sv305_ccd.h  

Modify the Sv305CCD class that you declare / define in these source codes.

Model judgment

bool Sv305CCD::initProperties()Add the code to the member function that determines the model . Information such as the product name and serial number of the individual SVBONY camera connected by the
SDK function is obtained in the constructor . If the product name is SV405CC, set the following two as camera attributes. SVBGetCameraInfo
cameraInfo.FriendlyName

I've included this code in the original source code, initProperties()but I'm a little skeptical about this method. It may be better to call the Sv305CCD::Connect()Camera SVBGetCameraPropertySDK 's ya with a function that connects to the camera and set the camera's attributes. This is because if the settings are made based on the attributes acquired from the camera in this way, there is a high possibility that if the functions are the same, there will be no need to determine the model and it will not be necessary to work on new products in the future.　　SVBGetCameraProperty

As a matter of fact, if the SV405CC is connected before the model judgment of the SV405CC is entered, the information as a color camera is not set because the model is not judged, and it is processed as a monochrome camera.

cooling

Cooling works by turning on the cooler and setting the desired temperature with the Control type in the SVBSetControlValueSVBONY .SVB_COOLER_ENABLESVB_TARGET_TEMPERATURE

I didn't understand the relationship between the GUI operation of EKOS and INDI and the driver at all, so I responded by looking at the source code of the sample driver that came with indi-3rdpary.
It might have been a little easier if you read the INDI documentation carefully and then reach out.
I implemented it while checking the operation of the UI and the behavior on the code with the debugger without reading these.
Links to the documentation are at the end. I will omit the setting of INDI parameters here.

Temperature setting

When the cooling temperature is set on the EKOS screen, the driver member function int Sv305CCD::SetTemperature(double temperature)is called.

Since the temperature is passed as an argument, call the following SDK function to turn on the cooler and set the target temperature.

• Cooler on:SVBSetControlValue(cameraID, SVB_COOLER_ENABLE, 1, SVB_FALSE);
• Target temperature setting:SVBSetControlValue(cameraID, SVB_TARGET_TEMPERATURE, (long)(temperature*10), SVB_FALSE);

Switching the cooler on / off

bool Sv305CCD::ISNewSwitch(const char *dev, const char *name, ISState *states, char *names[ ], int n)The member function is called when the cooler is turned on / off on the EKOS or INDI screen .

This member function is not limited to on / off switching using the EKOS UI, but is called when a parameter that takes a switch-type binary value is updated. Set on or off with the following SDK function when a cooler is specified as an
argument .name
SVBSetControlValue(cameraID, SVB_COOLER_ENABLE, 1, SVB_FALSE);

Display of current cooling temperature

void Sv305CCD::TimerHit()The current cooling temperature is acquired by a member function called at regular intervals .
This function is used not only for cooling temperature but also for image data acquisition after shooting.

TimerHitIs a function that is called according to the set timer value. In this function, call the SDK SVBGetControlValue(cameraID, SVB_CURRENT_TEMPERATURE, &lValue, &bAuto)function to get the current cooling temperature.

TimerHitSeems to be called by looking at the timer value in the main loop.
In other words, it does not work with interrupts or another thread.
This means that there are no processing interrupts inside standard INDI functionality TimerHit.
TimerHitEven if you change the parameters in EKOS or operate some function on / off button during the processing of, it only recognizes that EKOS has been operated, and the corresponding operation TimerHitchanges the value or status after exiting. Will occur.
This can TimerHitbe seen as a phenomenon that even if you press the shooting stop button while acquiring image data, it does not stop immediately.
However, if the driver creator creates his own thread, it is possible to execute another process at the same time.

With the implementation so far, you can use the cooling function of SV405CC.

Other improvements, etc.

The following are other improvements / corrections made from the original source code.

Instance levelmutex

If I could determine the model of the SV405CC and cool it, I thought it would be okay because the shooting was done with the original driver ...

I encountered a symptom that it did not work well even if I tried to disconnect and reconnect the camera with EKOS. ..

If you read the original source code carefully, it does not work as expected when you connect multiple cameras, such as SV405CC and SV905C, at the same time, which is defined by mutexdriver level variables and has instance level exclusive control . Is a solution by changing to a member of the Sv305CCD class. The SV905C is a prize for the contest held last winter. Without the SV905C, I would have missed this problem. staticmutex
mutex

Image format

This is a big problem and I think it will be the main feature of this fix.
When shooting with the finished driver, the color hierarchy is not smooth.
Looking at the histogram, there was level 0 data at regular intervals, and at first I thought it was a bug in his SVBONY Camera SDK that others had found.

Twitter points out that the SV405CC's ADC is 14bit, but it may be left at 12bit in the SV305 source code.
If you check it, it is certainly the code to get the data in RAW12.
But the problem wasn't what he was doing with RAW 12.
Regardless of the number of bits in the camera's ADC, the SVBONY Camera SDK had to get it in RAW16.
When RAW16 was specified, the image became smooth and the histogram became a gentle mountain.
This problem didn't seem strange to anyone two years after the indi-sv305 driver was released, even though he should have had it on all his CMOS cameras on his SVBONY since the SV305. Is a mysterious place.

Left: Data acquired by RAW16, Right: Data acquired by RAW14

OFFSET compatible

Fixed the problem that OFFSET cannot be set on the shooting screen of EKOS.
This was because the standard properties of INDI were not used to specify OFFSET.

other

In addition, some type errors and mutex lock / unlock correspondence are fixed.

The remaining challenges

The following are issues that we plan to improve over time.

Freeze of SVBONY Camera SDK 1.7.3

In my environment, it freezes in the SDK function when CameraOpen or Format is specified for some reason.
Even if I create a simple test program, it will be reproduced, so I don't think it's a problem with the indi driver.
The contents confirmed by the debugger are as follows.

• The SVBONY Camera SDK uses some threads internally.
• Two threads are waiting for each other.

At the moment, we are waiting for SVBONY to respond.
That's why the INDI driver uses SDK 1.6.5.

Stop shooting (improvement of INDI driver for SV305)

The current INDI driver for sv305 does not have a shooting stop function.
Not being able to stop shooting significantly reduces the usability.
It's already implemented in my private code. Basically, just set the shooting flag to false.
This will eventually issue a Pull Request.

Conflict between Video Streaming and still image shooting (improvement of INDI driver for SV305)

INDI's Video Streaming is running in a separate thread, and if you execute Video Streming and still image shooting at the same time, one camera can control only one shooting at the same time, which causes conflict.
The original code puts mutex before and after the SDK call to prevent SDK conflicts. However, in the first place, mutex is to ensure the consistency of processing by exclusive control of a certain block of code that needs to be an atom.
Exclusive control of only SDK calls cannot protect the consistency of processing and cause unnecessary waits.
The current INDI driver for SV305 is in a strange state when using Video Streaming and still image shooting, and strange waits occur and parameter settings that overlap between Video Streaming and still image shooting become chaotic.
I personally think that still image shooting should be prioritized over Video Streaming. In other words, he needs to perform functional level exclusion regardless of mutex, such as rejecting the operation of Video Streaming while shooting still images, stopping Video Streaming when starting still image shooting during Video Streaming, and so on.

TimerHitReading shooting data during processing (improvement of INDI driver for SV305)

There is a loop process until you can get the image data. Due to this loop processing, interrupt operations such as stopping shooting TimerHitcannot be performed until the end.
Especially in his SVBGetVideoData of SDK, his SV905C etc. may have a data acquisition waiting time almost equal to the exposure time, and it is assumed that he can not get out of the loop for a long time. This seems unlikely to occur with the SV405CC. I don't have SV305, so I don't know.
SVBGetVideoDataIf TIMEOUT occurs in, set a retry timer without using a loop TimerHitso that the process can be exited once, and this problem will be alleviated.
It's already implemented in my private code.
This will eventually issue a Pull Request.

Lamping (implementation in INDI driver for SV305)

It is a function to slow down / rise the temperature by the cooler.
Specify the temperature that goes up and down per minute, and adjust the temperature drop / rise.
At the moment, cooling is working with the INDI driver, and the SDK doesn't have such a feature, so I haven't implemented it.
However, when I actually took a picture, the sensor condensed when it was cooled to -10 degrees. In that case, I raised the temperature once, lowered the cooling temperature by 10 degrees from the temperature, and cooled it again after a certain period of time to prevent condensation.
It's a hassle to do this manually, so I think we need a mechanism to automatically set the target temperature at a specified time.

Acknowledgments

Last but not least, I would like to thank thx8411, the author of the original code, for supporting this implementation.
Thank you for your cooperation while my work and family are busy.

Reference link

• SVBONY Camera SDK
• INDI 3rd party Driver repository* As of July 8, 2022, some Pull Requests have been reflected.

INDI related documents

• INDI Developer's Manual
• INDI Technical Documentation
• Instrument Neutral Distributed Interface INDI

(Here is original content of compatible with SV405CC INDI driver)

Welcome to comment.