Returning to this topic after some time just reverting to my windows-based workflow. I'm really interested to get the PI-based workflow running. Before I set it down I did figure out some details about RAW capture and what settings I should apply.
There are still a couple issues I need to understand better:
- presumably most folks can run image capture, calibration, etc just fine in kstars with the 32bit astroberry server, and I wonder why in my case I'm running out of memory. Should I just pare down my index files to the bare minimum? Are there other things I should disable in kstars to keep the memory usage down? Alternatively, should I just proxy everything through the PI and run kstars on a 64 bit laptop? Any pointers on how to do this?
- should I accept that I need more than 4GB address space and try to find/create a 64 bit build of astroberry server? You mention that you're running a 64bit OS so presumably you've had some success finding an image and getting it set up- are there any pointers available to get started?
Read More...
Thanks, yes I understand. Just to clarify the situation: in the INDI control panel the driver is configured to use "native" transport, and when I capture a preview image in the Ekos CCD tab it successfully downloads an image and loads it in the FITS previewer. However, when I switch over to the plate solving tab and click capture and solve, for some reason the driver is ignoring the native setting and attempting to use FITS transport. I can generate the same failure to open /tmp/indi_*** error if I switch the transport to FITS in the control panel and then try to capture a preview in the CCD tab. I'm not sure why the setting is missed, will try to debug this flow.Yes, happy to share once I verify I can get an image. I do see that if I switch to my ZWO camera and just snap some images indoors then the solver is running (but triggering the mmap failures). If I take the scope outside and snap some frames, do you expect that the solver will run ok even if some index files fail to load?
Read More...
I attached gdb to kstars and set a breakpoint at the failed mmap error message- when it fails, the process size has reached 3.1GB, which sounds close to the limit, (4GB - 1GB reserved address space, according to this post: stackoverflow.com/questions/37409250/why...bit-armv7l-succeeded). I verified that the option to load all files at once is unchecked. I'll trim my indexes down to the minimal set that I need and hopefully I won't hit this limit.
I'm still digging on the FITS issue.
Read More...
Thanks for the detailed response.
As I understand it, the "Canon DSLR" driver is just a wrapper for the gphoto driver, and judging from the code you pointed to, even though I have configured the setting to capture native frames, when StellarSolver invokes the capture it's taking the FITS pathway (the /tmp file is only generated when FITS is selected for transport). I'm using the internal solver, so in principle it should just be receiving the raw image buffer. I will see if I can dig more to figure out why the wrong setting is used by the driver.
My device is armv7l which is 32 bit. I don't think I'm getting close to 4GB of allocated RAM, but I'll disable the parallel load and see if that fixes the issue. I'm a bit confused, though, about why a 32 bit pi would ship with 8GB of RAM on board- does the limit only apply to the address space of individual processes?
Thanks again, will follow up shortly.
Read More...
Here are some more details from stderr:
1. Canon driver configured with FITS transfer. Probably not an issue for regular light/dark capture, since native works fine, but this is a clue about what might be going wrong with StellarSolver capture- exactly the same error message appears (with a different tmp file).
org.kde.kstars.indi: Canon DSLR EOS M50 : "[INFO] Starting 1 seconds exposure. "
org.kde.kstars.indi: Canon DSLR EOS M50 : "[ERROR] Cannot open /tmp/indi_2DMHET: Unsupported file format or not RAW file "
org.kde.kstars.indi: Canon DSLR EOS M50 : "[ERROR] Exposure failed to parse raw image. "Switching to my ZWO guide camera and attempting to plate solve, I see dozens of failed mmap messages like this:
org.kde.kstars.ekos.align: "Capturing image..."
Found one coordinate representation.
org.kde.kstars.ekos.align: "Image received."
system: Cannot allocate memory
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/util/fitsbin.c:541:read_chunk: Couldn't mmap file "/home/astroberry/.local/share/kstars/astrometry/index-4204-04.fits"
system: Cannot allocate memory
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/util/fitsbin.c:541:read_chunk: Couldn't mmap file "/home/astroberry/.local/share/kstars/astrometry/index-4204-03.fits"
system: Cannot allocate memory
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/util/fitsbin.c:541:read_chunk: Couldn't mmap file "/home/astroberry/.local/share/kstars/astrometry/index-4204-03.fits"
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/util/quadfile.c:135:my_open: Failed to open quads file
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/util/index.c:417:index_reload: Failed to read quads from /home/astroberry/.local/share/kstars/astrometry/index-4204-03.fits
/home/astroberry/Projects/stellarsolver/stellarsolver/astrometry/blind/engine.c:204:engine_add_index: Failed to load index from path /home/astroberry/.local/share/kstars/astrometry/index-4204-03.fits
system: Cannot allocate memoryRead More...
Hi,
I'm running a kstars build from the most recent github source, so I could get the latest libraw with support for CR3 format and I've been bumping into a number of issues.
I'm connecting to a Canon M50 camera. I can launch the profile and preview images in the FITS viewer. However, capture only works in native transport format, not FITS. Not a big issue for regular capture, but it seems StellarSolver recently had a change that broke loading from native format, and so it fails to load the captured image from /tmp (it was loading fine a few days ago, before my most recent git pull- is there a preferred place to report these kinds of bugs?)
In addition to this issue, if I switch to my guide camera for plate solving, I successfully capture images, but kstars hits some memory limit and prints a stream of failed mmap calls to the console while loading the index files (as if no further memory can be allocated). My process image is only about 1.1GB, running on a raspberry pi 4 with almost 8GB ram. I'm not sure why this operation is failing or if I need to increase some OS limit to enable the process image to grow larger.
Feel free to point me to a better forum if this isn't the place to raise kstars bugs.
Read More...
Same issue for me. I thought I had mucked up a camera profile but kstars crashes even after deleting all profiles and creating a test profile.
Running kstars from a terminal, when I start ekos, kstars crashes with this message:
malloc(): smallbin double linked list corruptedRead More...