I got your code cloned and built.  I am trying to shoot some recognizable images with it but since it is mid-day here I need to do short exposures to avoid maxing out the pixel counts.  This means that the issue with short exposures that I mentioned before is rearing its ugly head.  I will try to get some properly exposed subframed and 2x2 binned images and/or captures tonight and let you know how that part of the code is working.  In the meantime though here is a packet capture of the problematic 0.25 second exposures.  I took a first exposure, which seemed to download just fine, then waited a few seconds and tried a second one.  The second one downloaded but it paused for a really long time during the download. Hopefully this capture has what you need to figure out why this is happening.  In any case though I will investigate the subframing/binning code tonight when it is a bit darker.

Read More...

I've had the camera out a few nights now for various lengths of time and have made a few more observations about it.  I wanted to post here to give a bit more feedback on the performance of the driver and also to share a picture that I am reasonably proud of (I won't post many more pictures to this thread since that is straying off topic but this one does fit I think).

Overall, the performance of the driver has been excellent.  I have now taken something like 1000 exposures with the driver and the only lockups I have seen were the ones mentioned above where two expose commands were sent before the first was finished.  The other source of lockups is in taking bias frames.  I was trying to do 0.001 to 0.02 second exposures, and both seem to have resulted in lockups.  Further investigation reveals that it is safe and reliable to shoot very short exposures, however they must be commanded one at a time with a manual wait of something like a few seconds between frames.  I can't say for sure whether this is just Ekos trying to shoot a second frame before the first is fully downloaded, or if there is just something in the camera that is still being reset, even though it is technically "done" with the first frame and the driver therefore thinks it is safe to proceed.  Either way, the problem is not a huge deal, once you know how to handle it, but it is a source of potential lockups which require and unplug/replug that would be a pain on a remote telescope.

On a more fun note, here is the stacked image I mentioned which shows the results of the camera.  This was taken last night using an ETX-90 OTA (a little 4 inch scope) on an equatorial mount.  I have no guide camera so I can only take about 10 second exposures and even then I lose about half of them.  I took a total of 640 10 second exposures.  I have processed 300 of them and 127 were good enough to plate solve and didn't have serious star trails (again, no guide camera -- something which I hope to rectify soon).

 



Read More...

I went out with the telescope again tonight and in using ekos I did notice that the 'Independent window' option is working, just not exactly as I anticipated it would. I did notice tonight that when I tried to move the ekos control window to another desktop it did work as expected, so the button is having an effect after all. What got me confused and made me think that it wasn't working was the fact that for the indi control window, making it independent not only lets you move it to a separate desktop, but it also adds the minimize and maximize buttons to the top bar of the window. For the ekos control it does let you move it independently like indi does, but it does not add the minimize and maximize buttons to the top. When I didn't see the buttons get added I incorrectly assumed that the changes hadn't taken effect since I had already seen that behaviour on the indi window and was expecting both the behave the same. Sorry for the confusion on the matter, just a mixup on my part, although the behaviour of the UI is a bit inconsistent.

The lack of min/max buttons at the top is maybe a separate issue that could be added -- not really a bug, more of a feature request. In any case, I did get the window to behave as I wanted it to, even if it was not obvious UI wise that the behaviour was working correctly.

Read More...

I did restart the program a couple of times as I was tinkering with other stuff and the change does not appear to be taking effect.

Read More...

Sorry to bump such an old thread but I just wanted to point out that I am also getting the same odd collapsing behaviour on the log output text at the bottom.  Trying to resize it at all results in it being forced collapsed with no way to reopen it other than a kstars restart.

The main reason I am posting though is regarding the 'Independant window' option for ekos.  I have enabled this checkbox for both the indi window and ekos.  It works as expected for indi, but the ekos window remains as it was before -- bound to kstars and without the minimize or maximize buttons in the top bar.

Read More...

Well, I got some pictures.  :)

They aren't super nice because my mount is not great at tracking and I don't have a guide scope/camera so I am limited to about 10 second exposures.  All that being said though, the camera (thanks to Ben's hard work on the driver) is working nearly flawlessly.  The only issues I really had during the night were a couple camera lockups when ekos told it to take a preview frame while the target scheduler was still active (so the camera got told to take a picture while it was in the middle of an exposure).  The driver could be made to handle this, but honestly that feels more like something indi should be handling (return with an error code "hardware already busy" or something like that to the calling routine).

As promised though, here are some pictures.  The first image is a single, uncalibrated 5 second frame and the second is 15 frames that were caibrated with a master flat from last night but dark and bias frames from 5 years ago (because I forgot to take new dark/bias frames last night -- shame on me).  The stacking was done by astropy, with the frontend to astropy being a website I am developing to store and process astronomy stuff.  The website is not online yet but it is running locally on my laptop while I develop code for it.  So these images were take using open source control software (kstars/ekos/indi), using an open source camera driver (provided by Ben), stacked using the open source astropy with stacking controlled by an open source web interface written by me.  That's a lot of open source goodness.  :)

Anyway, here are the images.  I am looking forward to getting back out again tonight to do a bit more experimenting with my setup (I forgot to try any temperature control stuff last night, was too busy working out the rest of the stuff and learning to use ekos more efficiently).Well, I got some pictures.  :)

They aren't super nice because my mount is not great at tracking and I don't have a guide scope/camera so I am limited to about 10 second exposures.  All that being said though, the camera (thanks to Ben's hard work on the driver) is working nearly flawlessly.  The only issues I really had during the night were a couple camera lockups when ekos told it to take a preview frame while the target scheduler was still active (so the camera got told to take a picture while it was in the middle of an exposure).  The driver could be made to handle this, but honestly that feels more like something indi should be handling (return with an error code "hardware already busy" or something like that to the calling routine).

As promised though, here are some pictures.  The first image is a single, uncalibrated 5 second frame and the second is 15 frames that were caibrated with a master flat from last night but dark and bias frames from 5 years ago (because I forgot to take new dark/bias frames last night -- shame on me).  The stacking was done by astropy, with the frontend to astropy being a website I am developing to store and process astronomy stuff.  The website is not online yet but it is running locally on my laptop while I develop code for it.  So these images were take using open source control software (kstars/ekos/indi), using an open source camera driver (provided by Ben), stacked using the open source astropy with stacking controlled by an open source web interface written by me.  That's a lot of open source goodness.  :)

Anyway, here are the images.  I am looking forward to getting back out again tonight to do a bit more experimenting with my setup (I forgot to try any temperature control stuff last night, was too busy working out the rest of the stuff and learning to use ekos more efficiently). 

 



 

Read More...

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.

Read More...

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.

Read More...

Success!  :)

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.

Read More...

Ok, so this is the weirdest thing...

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.  :)

-Andrew Buck

Read More...

Andrew Buck is friends with Ben Gilsrud