The problem here was the Chromebook.
Kstars/Ekos/INDI runs fine under a Linux chroot, Crouton, on a Chromebook.
My difficulty was that the INDI 3rd party "driver", asi-common, is really necessary to expose a full frame (but not necessary for a smaller region of interest). But asi-common will not work on Crouton installed on factory Chromebook.
Instead, because of the way systemd works, the asi-common rule must be installed in the Chrome root file system. Trouble is, this file system is mounted read-only in a factory Chromebook. For this Chromebook (Asus 523) this involved using a SuzyQable to remove the write protection from / and manually copying the asi-common rule file to /etc/udev/rules.d outside the chroot.
Just in case someone else encounters this problem.
I'm working with ZWO ASI cameras, 290 and 183. ZWO claims the 183 can run at 19 frames per second at full resolution.
It's a little embarrassing to ask since I guess that people using lucky imaging use the streaming video output. But if one wants to end up with fits files, they will need to burst the SER files and convert to fits.
OTOH the integer second base unit for delay seemed not to be tied to the hardware.
I wonder what the reason for this would be.
Wouldn't it be a desirable feature for lucky imaging, speckle, DIMM?
Is it possible to do the following?
set camera to take 5 exposures per second, each exposure 10 milliseconds long and each exposure recorded in a fits file?
Thank you. Yes, it's time to seek out another driver and get some parallax there!
Thank you for the idea.
I do have an "Amazon basics USB 2.0 4-Port Ultra Mini Hub" lying around although both chromebooks (Lenovo Flex 11 & Asus C523NA-IH24T) sport single USB 3.0 ports.
Unfortunately, connecting the ASI183MM through the 2.0 hub does not help. Exposures cycle through failure until aborted.
I am unable to capture images with new ZWO ASI183MM.
Under the INDI control panel, main control, expose "set" results in "Exposure failed after 3 attempts".
Logging doesn't uncover helpful information; only "ASIGetExpStatus failed. Restarting exposure".
However, a ZWO ASI290MM *does* seem to function correctly, so the problem seems specific to the 183 camera.
I tried this on 2 (closely related) systems with same result:
First in INDI v. 1.8.1 - Kstars - KDE - Buster Crouton chroot on Chromebook.
Second in INDI v. 1.2.0 - Kstars - Gnome - Stretch Crouton chroot on Chromebook.
I would be grateful for any suggestions how to diagnose or remedy.
It's helpful to know the ASI drivers compile for one of the processors. Thank you.
Trying to compile asi-indi.
Starts OK : indi_asi_wheel compiles
But asi_focuser.cpp fails. Messages to stderr below.
Actually, I only need indi_asi_ccd but I don't yet see how to take the focuser out of the loop.
File Attachment:File Name: error_log.txt
File Size: 5 KB
New information about problem with short exposures with the ZWO ASI290MM.
Two exposures of theta aurigae taken a few minutes apart in 8 bit mode.
Exposure #1 taken using Control Panel -> ZWO CCD ASI290MM -> Main Control -> Set. Exposure .2". Gain 0. Max pixel intensity 5. Fits data attached as th2l_t0.txt
Exposure #2 taken using Ekos CCD & Filter Wheel -> Start Sequence. Exposure .005". Gain 0. Max pixel intensity 255. Fits data attached as theta_aur_Light_002_t0.txt
There is something terribly wrong with Exposure #1 as all brighter pixels get truncated to 5. Nothing appears to be wrong with the camera since it produced both exposures. Something might be wrong with the driver or the operator (i.e. me) taking images from the control panel.
Does anyone know what might be going on?
Regarding the ZWO ASI driver.
Manual says "supports region of interest". Is this implemented by the "frame" settings in the control panel? No way to, say, select an area in a test photo as with the focusing module?
What is "rapid looping" in the control panel "options" settings? Is it related to the count/delay settings under the Ekos CCD tab?
So to take hundreds of exposures of a small object as economically as possible, one places it within the numerical coordinates entered in the frame settings (either in the driver control panel or Ekos CCD tab) and configures rapid looping in the control pattern or count/delay under the Ekos CCD tab?
Last night I tried to run plate solver from my DIY push-to telescope, but I was unsuccessful. Instead an alert popped up saying telescope aperture and focal length needed to be entered.
How does one do this?
I have found a place to enter aperture and focal length under "settings -> configure observation logging -> list your equipment" but this doesn't seem right, (and I cannot check until next observing session). The FAQ mentions a "profile page" but I can't seem to find that. Finally, when starting EKOS, there is a message in the logging window that a config file was looked for but not found.
What am I missing?
Still running version 2.6.0 from Debian stable, Stretch. (am willing to upgrade to testing)
My camera is a ZWO ASI290MM which should be producing 12 bit per pixel output. So, in analogy to DSLR output, I expected the FItS data to be an array of positive integers between 0 and 2^12-1 = 4095 with min and max nested between those extremes. But when I look at the data table of a photograph, FITS header attached, the values are all positive integers, *but* they are all even numbers and they top out at 5232. Min is around 160. Then the values for DATAMIN and DATAMAX are -898.34... and 5231.76.... I would like to understand how those numbers are obtained. It can't be a linear transformation a*x+b where a and b are scale and offset because any such number should be an integer if x is, so I guess there is some other algorithm.
Don't mean to be bothersome. Thanks.
I don't understand how DATAMIN and DATAMAX in the FITS header are derived from the data. When I look at the data table in FV, all the entries are positive integers, but the header entries for DATAMIN and DATAMAX are by definition double precision decimals. How to get from one to the other?
So far I have found the function getMinMax in indiccd.cpp which is simple enough routine for finding extreme values. So I guess the float values come from the function getFrameBuffer for which I have not yet seen the source but will look for. But until then, I'm wondering what could be the reason to use decimal fractions to represent extreme values of binary integers?