Ok, so a bit more exploring and unfortunately the lsusb information that Bob posted looks pretty much identical to mine (after ignoring the whitespace differences. As far as I can tell distinguishing the difference between the two camera will require actually asking the camera something and looking at the response.
I'm going to try to set up the windows machine with the driver and get some packet dumps. I was hoping I would be able to figure out in the code but the obvious things I wanted to try have been tried and now I am at the limits of what I can do. Will post the packet dumps when I get them. Is there a recommended way to record the dumps? Wireshark was my first guess, I know this works on linux but not sure if the windows version supports USB.
Ok, I think this dump should help. I got the camera running under windows and used wireshark for the capture. The "connect" from orion camera studio happens a bit after the 5 second mark. A 1 second exposure starts around 11.37 seconds and data starts coming back at around 12.25
I poked around in the packet dumps a bit. Again take all this with a grain of salt, since I don't know a ton about USB but in the color packet dumps I see a bRequest=20 packet going out and then a control response data of 02 comes back. On the mono camera (mine) I see 20 go out and 01 comes back in. The bRequest=20 is SSG3_CMD_UNKNOWN_STATUS1 in your driver. So that might be the distinguishing feature between the cameras. Hope this helps, but don't put too much faith in it since like I said I am totally new to this.
Hi Andrew. Have you communicated with Ben Gilsrud. He has done an excellent job of getting the driver as far as it's got.
I have a color version and used it with Indi and done some testing to help Ben debug. I would like to know the issues you see and can confirm if I see them too.0
I haven't spoken to Ben, just made the post here in the thread. I am guessing he will see it since he is probably following the thread. The issues are the ones I mentioned in the post this morning (about 4 posts back now). The camera seems to work ok, just gives every other line and crashes after a few images. I think it is due to something like a memory out of bounds error, as it is probably trying to read pixels that are in the color version but aren't in the monochrome.
I believe that the G3 color and mono use the ICX419AKL and ICX419ALL, respectively. They have the sample pixel layout since they're the same chip (just one has a color filter array on it).
I'm assuming that you're able to capture an image in orion capture studio and it looks fine, right? Any chance you could get a wireshark dump while using the indi driver?
I've compared the wireshark dump for the mono and color G3 cameras and don't see any obvious differences in the image download. I think you might be right about command 20 being the way to distinguish color vs mono. As it turns out, VID/PID 0x07ee/0x0501 is the identifier for the Mammut Lyuba L429 camera, so I can fix my guess. You're also right about the geometry of the pixels being of by 1nm. That wouldn't cause the crash, but it should still be fixed.
It might also be helpful if you could get a backtrace as described in section 3 of
I installed wireshark on my linux laptop and added myself to the wireshark group so I could do packet captures. I then restarted the computer and tried doing a packet capture of a frame and... it worked just fine. No weird blank lines, no crashing, no problems at all as far as I can see. I have spent the last 20 minutes or so in ekos capturing images and after aproximately 100 frames it hasn't crashed or had any problems at all. I have no idea why it suddenly started working, other than that restarting may have reset something, but in any case everything seems to be working just fine now. I did one frame with wireshark running and the rest with wireshark still open but not capturing.
So other than changing the pixel size to 8.3 on the Y axis, it doesn't look like there are any changes to make at this time. (Oh, probably should remove the "guess" on the USB id so it doesn't cause problems for users of that other camera, but that's unrelated to the issues I had).
I'm going to try to get it outside tonight and take some pictures with the telescope, but as of right now it seems to be working just fine. Thanks for all of your work on the driver, Ben. I will try to post a couple pictures and an update after tonight if I get a "second first light" from this camera running on fully open source code.
The weather was not great last night, it was a bit hazy with some thin clouds, so the pictures were absolute garbage, but I got a few images of Vega, well enough to focus the telescope and demonstrate that the camera is reading actual data, not just noise or something but nothing worth posting here. Binning 1x1 works perfectly, however 2x2 binning gives some weird results. It takes about a minute to try to read out the data. What comes back at the end seems like it could potentially be reasonable (just testing inside on the table with the 2x2 binning) but I can't say for sure. In any case though it obviously should not take a full minute to read a 2x2 binned image (a 1x1 bin should take about 2 seconds to read, which it does, and a 2x2 should be about 0.5 seconds to read).
I have attached a packet dump of a 1 second exposure 2x2 bin image followed by a 1 second 1x1 bin image in the same file. I am also hoping to play around with the cooler a bit today but I can't guarantee when I will have time to do it (might be tomorrow or later this week before I can do any serious testing on that, but I expect that already works anyway since it is the same as the color version).
One other thing I haven't yet tried is taking subframe images. The options to set the subframe are ghosted out in ekos, so I haven't done anything with that. Presumably the camera driver is not advertising this capability to indi, but I don't know for sure. I can't remember if your code supported subframes or not.
Just a real quick post on the temperature stuff before I head to work (will do more detailed testing later). The temperature controls seem to work as expected with one slight oddity. At least in my initial testing it appears that the fan speed is exactly inverse of what you would expect. The fan seems to idle down when the temperature is dropping (i.e. the peltier cooler is engaged at full power) and the fan speeds up to full power when the cooler is turned off.
I think there were some other control channel id numbers that you thought were related to the temp controls. I am wondering if the peltier power and the fan speed are set as two separate things. If that is the case I also wonder if there isn't a second temperature sensor on the "hot" side of the peltier in addition to the one on the ccd which you are already reading. If that is the case it might be possible to run the peltier and still keep the fan speed fairly low until the peltier itself starts heating up at which point the fan can be sped up as needed. Of course all of this is just speculation. As mentioned I hope to do some more detailed work on the temp control testing, but wanted to give you these initial results right away in case you had any ideas, etc.
The other thing for future work as a "nice to have" is that right now, the cooler seems to flip between 100% power and 0% power. A better way would be setting the power based on how far away we are above the desired temp. A formula something like
10% + 10%*x
where x is the temp (in C) that the ccd is above the setpoint. Basically if its above it runs at at least 10 percent power, but ramps up the farther away it is. This way as it comes down to temperature the cooler idles back so you don't "overcool" the sensor. That should make the temp much more stable instead of "hunting" around for the correct value.
I'm glad that you were able to get some images out off it!
I started to implement binning and then put that on hold. I just double checked and see that the driver is still advertising binning support, which was not what I intended. Binning could be added without a lot of effort, but I wondered how valuable that would actually be given that the sensor is small and the pixels are already pretty large. But, someone who's motivated could do it Subframing is also not supported by the driver, but we understand enough of the camera control protocol that it could be.
I believe that the cooling is a setpoint-style interface. That is, the driver tells the camera the desired temperature and the camera is responsible for adjusting peltier power and fan speed to achieve the desired set point. The G3 hardware can only cool down to ~10c below ambient. If you set the cooling to something like 5C below ambient I would expect that you would see the power spike and then decrease as it reaches the setpoint and maybe settle somewhere around 50% (+/- 20%). You could also try experimenting with cooling in the orion capture studio and see if you see the same power/fan behavior. I suspect that the fan is controlled by the uC on the camera rather than through the driver. At least, that's what I would do if I designed the camera. Also, I don't think there were any write commands whose function wasn't figured out.
I would love to see what you were able to image with the camera!
I'm going to bring the scope out tonight again and the weather looks a lot better. Hopefully will get some images that are worth posting (not just a single white dot on a black frame like the other night.
The binning is defnitely worth adding. Due to the way the interleaving of the lines work, in 1x1 mode you get every other line looking brighter than the others. Also, the camera would work well as a guide camera since it has the st4 port and is quite sensitive, and in a field with faint stars the binning really ups the SNR (also cuts the 2 second readout to 0.5 seconds which makes the response time a lot better in guiding applications. If its not too much trouble to add I would really appreciate you taking the time to do it. I am not completely sure how to go about implementing it. I know its not terribly hard, but it would take me a lot of time to figure it all out.
Subframing would also be nice for the guiding reasons mentioned above. If you stick in 1x1 binning mode, reading just the portion of the frame where your guide stars are really helps the readout speed.
I'll try to keep an eye on the fan tonight and see how it operates in a real setting with the cooler actually running in a real environment. I expect you are right about the cooling being micromanaged by the onboard uc, however I did notice that odd fan behaviour the other day and that is what made me doubt this a bit. I don't seem to remember it running that way in orion camera studio.