You might want to take a look at this: indilib.org/support/tutorials/159-indi-on-multiple-devices.html

Support for the HQ camera is in development and I'm not sure if using multiple HQ cameras is supported with that method.

Read More...

Yeah. That one had me stumped for a while. Seems that raspistill will go through several frames (around 7 of them) before it presents the final frame to the user. Each frame is the length of the exposure time that has been set. That is the very reason for implementing raspiraw in my driver after attempting to use raspistill.

Read More...

It should be 16 bit pixel format. The raw image may be packed 5 bytes for every 4 pixels (10 bit ADC). They have to be converted to 2 bytes per pixel. Is there any way that you could post one of your raw files?

Read More...

It sounds like you are making pretty good progress.

As I understand it, the image is returned to the client as FITS when ExposureComplete(&PrimaryCCD) is used. The image buffer to write your image to is set with the uint8_t *image = PrimaryCCD.getFrameBuffer() line in the generic_ccd example. Then write your image data to the frame buffer ('image' in this case). If the parameters such as height and width are set correctly, a conversion to FITS is performed and the image is sent to the client.

Read More...

Support was added to raspiraw for the Sony IMX477 in the last few days, but I have not updated my fork that is on my github page. Since my driver is hard-coded from the V2 camera, if the V2 specific constants were changed, it may work with the HQ. These are RAWBLOCKSIZE, ROWSIZE, HPIXELS, VPIXELS. Also, the mode that is requested in the raspiraw command.

I have a HQ camera ordered and cannot test until it arrives. My goal is to have the driver use both the V2 and HQ.

If you have a link to what you have worked on, I would be interested in seeing it.

Read More...

I apologize, I just noticed how old this thread is and what I think your actual question is. If you are trying to unpack a raw file, take a look at
github.com/jdhill-repo/indi-picamera/blo...er/indi_picamera.cpp lines 870 to 900. I can't remember exactly where I got the format. Hope this helps.

Read More...

A couple of things to keep in mind that I discovered when I wrote my driver is that there is a 1 second limitation when using V4L2. Also, the response from Raspistill will seem slow because the first few frames are always dropped by design. This results in a 1 second exposure actually needing 7 or 8 seconds to complete.

Read More...

As mentioned here

www.indilib.org/forum/ccds-dslrs/2718-ra...-teammate/34231.html

I have been using an experimental driver with a Raspi camera for quite a while. It was written for the V2 camera and uses Raspiraw to generate a low-level raw image that I use for guiding. It works just like any standard camera with EKOS, with the exception of video support.

In the past week, the HQ camera support has been added to Raspiraw and I plan on updating the driver when I get a HQ camera and time to add and test it.

Another option on the horizon that I will eventually be looking into is the recently developed libcamera support for Raspi which or may not be a better option.

Read More...

Thanks. This is a feature that I have needed for some time. Looking forward to trying it out.

Read More...

The source for wiringPi was pulled from the public domain several months ago. That is why you are running into the link errors. Try this link to get and install the .deb file for the Pi 4: wiringpi.com/wiringpi-updated-to-2-52-for-the-raspberry-pi-4b/

Read More...

Sounds strange, but I can apparently duplicate the memory leak with those options disabled. Using Canon T6s, Astroberry over VNC. I duplicated with upload to client set. After a few images, I get the "Unsufficient Memory" errors.

I did some testing with the CCD Simulator (with the same frame size as the Canon) and did not notice a memory leak, even looping to the FITS viewer.

Read More...