I just pushed some changes to fix the temperature conversion. With the latest dump, I was able to get it figured out. It ends up being a perfect linear fit so I'm pretty sure that it's correct. I'm hoping this is it for the cooling.

Looking good at room temperatures Ben.  Sensor ambient was around 26.  I compared OCS with Indi, setting the CCD temperature to 20 then 15 and got comparable results. For example at 20 OCS was fluctuating 20.5 ~ 20.3 at 34% and Indi 19.87 ~ 20.03.  With a target of 15 OCS got to 15.5~15.7 at 100% and Indi 15.88 ~ 16.03.  Seems like the cooler can manage about 10 degrees below ambient. I will test outside on a cooler night to see if comparison holds.  I did wonder if temperature reading from camera was in degrees Fahrenheit but its probably not that easy.
Having the power reading is useful as it shows how well the cooler is coping.
Restarting the camera driver from the EKOS camera TAB simply shuts down KStars and nothing restarts.

I just pushed a change to add cooling power. I'm not sure that I have the conversion correct, but I think it's a reasonable guess based on the usb dumps that you've sent. I'm curious if you ever see odd cooling power percentages reported by OCS? In any case, it would be helpful if you could test it out. I'm thinking that you might set a setpoint 2 or 3 degC below ambient, let it cool, and note the steady state cooling power percentage. If you decrease the setpoint temp and follow that same procedure a few times, I'm hoping you see that cooling power shows 100% at the point that the camera can no longer reach the set point.

Yep. Power % reads as you would expect. As the target temperature is decreased power consumption goes up. When you get to around 10 deg c below ambient it reaches 100% and stops cooling further. Increase the target temperature and % power drops off until target is reached. In the study here 20 deg C at around 70%.
I did spot OCS reported a % power out of 140% momentarily. Your code indicates a more steady power%, fluctuates less.
Thanks for that. I now need to figure out the best way of capturing the ST4 commands. Reading up on the OCS manual ....

Hi Ben, Connected to camera using PHD2 and ascom driver on laptop.  Sent 3 pulses for North, South, West and East.  Captured in individual direction files and all 4 directions as well.  Pushing the buttons using the manual guide isn't very positive so may not have been 3. Does this capture help?    

Thanks, Dave...that was exactly what I needed. I just pushed some changes to implement the ST4 port.

Hi Ben. Where do we go from here? When I get an opportunity (clear night) I plan to to use the camera to take some images and swap it over as the guide scope.
I am not familiar with the Indy development process and how to get drivers added to the official library? I would like to get a better understanding on how best to set up a PC or PI to develop code. I have only got as far as looking at source code using the Geany editor on the PI.
Is anyone developing live stacking? Is it possible to have a chat?

Hey Dave, I think the driver is done enough to submit it for inclusion in the INDI project. This is done by opening a pull request on github. I have to clean just a few things up and can probably do tonight.

There are a few things that will be annoying for SSG3 users, but I think these are not related to the driver:
1. As far as I can tell, there's almost no support for demosaicking CYMG sensors on linux. I know kfitsviewer doesn't support it for sure.
2. The strange fits corruption that you saw when saving a fits file. Again, I'm pretty sure this isn't related to the driver.

I don't know anything about live stacking, but it sounds like Siril might be able to do that. I would be happy to chat, I'll see about setting something up.

From reading various threads in forums and trying out a few of the popular photo editing applications, it is not easy to create a colour image from the G3 raw fits image. The best way I have discovered so far is to open it in OCS and convert it to RGB. After I have captured some astro images with Indi in raw format, post processing is the next area I need to explore.
According to the CCD technical data sheet , pixels are cyan, yellow, green and magenta. Then it talks about a mathematical combination of these pixels to give a Y signal and chroma signal. Its not clear to me if this combination is done on the chip or has to be done by the capture software. In other words is it the individual pixel values stored in the FITS file or Y and chroma? I do wonder how the FITS viewer is able to show a recognisable mono image if it doesn't understand the pixel colours?
Live stacking would be great for public viewing of deep sky objects and also for amateur observers. If the individual frames are saved as well for later stacking using the observers favourite application, even better.

I just joined today. I have an Orion Starshoot G4 Color and I cannot get it to connect to INDI. Keep getting message that the driver is crashing. I have a Raspberry PI4 with Stellarmate OS on it and it was just installed last week. The updates are current. I'm not a complete noob to Linux (but Stellarmate is new to me, thought it looks like it runs on Debian so that's not a big deal) INDI however is completely new to me as is astrphotography. INDI finds my EQMOD mount and my QHY Polemaster, it appears to see my Starshoot G4 but won't connect to it. From the way it looks you got your G3 to work. I've skimmed through here but I'm working and can't read the whole 9-10 pages. Can you point me in the right direction so I can get my G4 working? Thanks.

Hi Steven. It's possible that the Starshoot G4 is similar enough to the G3 that this driver could work, but i really have no idea. It would help if you could post the output of "lsusb -vv" from the stellarmate with the G4 connected.

Thanks for the reply Ben. The requested output is below/. I believe it is very similar to the G3.

Bus 001 Device 008: ID 07ee:0502 Torex Retail (formerly Logware)
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x07ee Torex Retail (formerly Logware)
idProduct 0x0502
bcdDevice 11.02
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 100