I've been wrestling this more and there is indeed a memory leak. I don't yet know how or why, but it doesn't happen always but most of the time on my tests.

Happened after the last episode:
1. I installed a fresh Raspbian Buster and manually installed indi-full using the official repository
2. I ran the first tests and found out that it was working properly. I ran a few test runs with 100 frames and it worked just fine for at least three times. Also my FITS frames were now working (at least a few times when I tested). The memory consumption stayed near 60M.
3. Took the whole setup outdoors and controlled it from indoors. Same hardware, same network, same everything. The only thing changing was that I took the tracker outdoors. So a bit worse network and quite a bit colder. This time it always crashed after the Raspberry memory was full. Tried restarting everything a couple of times but no luck.
4. Back indoors a few days later: tested a few runs by restarting things and trying again. A few times everything just worked.
5. Next session outdoors and nothing works. Even tried changing the Raspberry power to a more powerful 3A one. No changes, reserves memory until the driver gets killed by OOM killer.
6. Got annoyed and pulled a huge USB-cable from the carage outdoors and connected everything with wires. No Raspberry in between. This time I managed to get around 400 frames during the night with a single sequence. BUT: when I checked the computer after the sequence, the driver was reserving over 4G of memory. It just didn't crash because my 16G RAM was enough for it. So it was evident that it's leaking memory also on Ubuntu laptop. I posted a screenshot of that.

I still have no idea what is causing the crashes or the randomness with memory leaks. If I can share some logs or something, please tell. I can try another Canon EOS a bit later when I get one on my hands.

Also about the FITS frames: for some reason I usually only get some random grayness on the FITS frames I take. It looks like a bug as well and it's really annoying since it prevents me from using all the flashy tools in KStars.

Read More...

I'm always using NATIVE because FITS frames are all gray and broken for me. Another bug or something weird on my setup(?)

I upgraded INDI on the raspberry from 1.9.2 to 1.9.7 and witnessed the same exact behaviour: indi_canon_ccd memory usage grows until the raspberry memory hits the limit (872M + 100M swap). I could try 2.0.0 but Astroberry is currently using its own repository and I'm not sure if the official INDI repository works for ARM.

I also tried to alter the indiserver startup parameters since there was this -m 1000 parameters I didn't understand, but didn't affect anything. Maybe it has got something to do with Astroberry rather than the driver itself. It's the driver process that's eating around 700M RAM after 30 frames. Cannot understand.

Read More...

I found that indi web server on Astroberry logs into `/tmp/indiserver.log`. (Why on earth put logs under /tmp???)

There's this line on the log when the crash happens on the client.
`Child process 2670 died`

After further investigation, that process belongs to indi_canon_ccd. When I followed the memory usage, it looks like it's reserving more and more memory until the process crashes.

```bash
astroberry@astroberry:~ $ while true; do ps -p 2670 -o rss=; sleep 2; done;
19604
19604
19604
19864
19864
28032
...
644088
676428
676704
678112
<no more values because the process is dead>
```

Read More...

Also saving the subs "locally" on the raspberry didn't make the bug disappear. So it looks like the bug is not related to the file transfer between Astroberry and local Kstars. But since it doesn't work also with KStars on the RPi, it's not about the camera connection either.

Read More...

I tested this without having Astroberry between the camera and KStars and the issue is gone. So it looks like KStars works correctly and the camera as well. So there's something weird going on with Astroberry.

Any idea how to debug this further? Some logs in Astroberry I should be aware of?

Read More...

I've been having a strange issue since I started learning KStars with OAT. For some reason the imaging sequence crashes after a somewhat fixed amount of images. It's not always 32 photos, but today I tried three sequences with 30s, 60s and 120s exposures and every sequence crashed after exactly 32 photos. Sometimes longer exposures have made it up to 60 photos or smth, but 30s exposures rarely much over 30.

When the certain number of photos is reached, the sequence freezes for a bit and then the INDI control panel (the one that shows the mount and DSLR configuration) shows up. Based on the logs the camera connection gets "destroyed" and then found again, which opens the control panel. After that has happened, if I touch the sequence controls, like stop and start it again, KStars crashes totally.

These lines can be found on the log

org.kde.kstars.indi] - Removing device "Canon DSLR EOS 60D"
org.kde.kstars.indi] - INDIListener: Removing device "Canon DSLR EOS 60D"
org.kde.kstars.ekos] - "Canon DSLR EOS 60D is offline."
org.kde.kstars.indi] - Received new device Canon DSLR EOS 60D
org.kde.kstars.indi] - INDIListener: New device "Canon DSLR EOS 60D"

I found it from
My details -> Profile information and scroll all the way down

Read More...

This is a repost from OAT discord, because this is maybe more related to ekos than OAT.

Tonight I had massive problems with GOTO and tracking.
I previously managed to shoot around 60 frames of C 2022 E3 comet with good results. Back then I took only 20s exposures but with 300mm there should have been considerable light trails if the tracking wouldn't had worked properly. Also the GOTO feature worked on the second try. I think I back then had to solve one image manually and sync the mount on KStars to make the goto find the comet. But again, with 300mm lens, it wasn't propably a coincidence that it found the comet.

Tonight I went outside and started setting up stuff. After a somewhat proper polar alignment, I tried to drive the camera towards Andromeda. Then what happened was that the mount turned in a completely random looking direction, which was below the horizon and more towards W than NW where it should have been. Then after another try with first homing the mount physically and then with the python script, the goto feature towards Andromeda ended up pretty much straight towards South and again below the horizon.

Also after I manually drove the mount towards NW, a 10s exposure had major star trails as if the tracking speed would have been way too fast.

I checked the calibration instructions and rising RA by +1h the ring turns counterclockwise pretty much exactly from one mark to other. And when decreasing DEC angle by 45deg, the camera raises from one DEC ring pole to next one.

Then I connected my OAT cable to my windows desktop and tried to slew to manually given coordinates using OATControl and to me it looked just fine! So it strongly suggests that the mount is configured just fine and the problem is somewhere between my OAT and the user, so in Astroberry - INDI/Ekos/KStars pipeline.

Here's a visual bug report I built: youtu.be/vcjDnKqGJzk

Read More...

I just learned that my problem #1 with Optical Trains dropdown being disabled has something to do with the camera connection. If I get some log rows on the INDI Control Panel saying something about the camera, everything is fine. However if the log stays empty, even though it says connected, the optical trains dropdown stays empty. Also nothing else works with the camera at that point. I can fix the state by clicking Disconnect and again Connect on the INDI Control Panel. Looks like there might be something wrong with the camera connection initialization or something.

Read More...

I have succesfully shot and stacked The Comet last month, so I have also some understanding already about Siril and how the FITS files should look like. Also I've managed to occasionally get valid FITS files from the camera as well. Sometimes just something breaks and the files break.

Good reminder that I forgot the versions and other details. I'll update on the original post.

Read More...

I'm a n00b on a quest towards astrophotography and I've been learning the whole stack for a few sessions now. I've been having random problems, some of which have been solved by the recent update and some because I realized my user errors. Yesterday however, I again ran into several random issues and I'm wondering if these are something that I could fix myself or if these are actual bugs in the software.

1. Optical Trains dropdown disabled
On random occasions the optical trains dropdown and the edit button is disabled/ususable. There's no default train selected so it's not possible to do anything else than restart KStars. Sometimes the restart fixes it, sometimes not. Previously I had the Snap version and it had no problems like this. Now I'm running the stable PPA. (Because the Snap version is not the latest)

2. FITS transfer format gets broken images
If the image transfer format is FITS (instead of Native), sometimes the frames are broken. Again, it's a random thing happening and sometimes it works. "Broken frames" here means that on the KStars FITS viewer it looks like gray noise without any signal. On Siril they looked all black. This is especially annoying since I think the Polar alignment/Solver tab automatically changes the transfer format back to FITS, even if I selected Native on the INDI control panel.

3. Sequencer frozen in the middle of a 30 frame sequence
I had a sequence running for 30 frames each having 60s. At some point I noticed that it was 10 minutes since the last frame and the sequence progress was 23/30 frames. After I clicked the stop button, whole KStars crashed.

It's going to be a clear sky here tonight, so if I could get any hints for these, I could try fixing already tonight. I'm a programmer myself so I can try to debug something if I get some instructions.

Also: Thanks everyone behind this software and forum. This stuff is golden!

Read More...