Thanks Hy,
So plot is the reported stats from the linux FREE command as can be seen in the script (assuing you've looked at it as you mention "drop_caches"
I also attach here the output from the text file, which shows all the data that is plotted:

Total number of lines in the file (approx 1 line per second or so) is around 30k.
So the first drop_caches occurs at line ~1930, and how I've recorded this is by outputting string "Iteration %d; Cache memory greater than 75% threshold ( 76.0%). Cleaning memory in system." (search for "iteration" in the text file and we can see 15 occurrances of this - each time we get to a drop_cache, there is a drop in the CACHE memory and rise is the FREE memory - the command in the script does what I needed.
Prior to this addition, Swap would eventually get used until no resources were left and KStars/EKOS would crash, stopping imaging session - the original topic of this discussion.
With the plot, sure enough, we see 15 'jumps' where the cache used is cleared up (cache shown by purple line) - it rises continuously, until cleared.
The yellow FREE plot (again these terms seen in the legend) are the % returned from the "free -w" command in bash) drops until a "drop_caches" when the FREE available jumps up again.

Available swap (unchanged from the OS install) noted at top of the attached file as 99MB. Again, throughout previous tests, swap was used (which from my understanding and eg searching isn't 'ideal', but not disasterous). This latest test requires 0% swap used throughout.
Unfortunately, I've not done any real editing of the graph colours - "SWAP usage" and "FREE memory" are both yellow, but the SWAP stays at 0% usage throughout (look along the Y=0% line).

The HDD is the available space on the µSD which (no surprise) drops constantly from about 82% free to 50% free as the simulation files are written at regular intervals ("exposures" of 2.5 sec)
Not sure what else to comment here - the astroberry OS is a clean install, add on Conky and Anydesk, then running KStars for many imaging sessions etc. When I became adventurous and left the rig overnight and went to bed, I'd get up and things had crashed so I've gone down this debug route.

Prior to the addition of the "drop_caches" syntax, the cache would get used up (see previous posts), I would expect the yellow line would continue to decrease, swap would rise, and things would appear to 'stabilise' here for a period, before yes, KStars would crash.
I'm going to run another test to prove this as I'd updated several times throughout this testing. Essentially it'll be the same output. I'll just comment the "drop_caches" line in the script... Watch this space then!

RE SSD - certainly not against the idea! I did look at SSD, although just at the moment, I've done 3D prints which hold all the RPi, cables, etc, on the mount, so just at this point would rather keep things tidier. But yes, I would still consider SSD! I've also considered moving from astroberry OS to stellarmate OS (stellarmate running on the RPi), and thought that the latter would be the best way to get around this issue, although having discovered the memory issue, feel I can run at least for now with my 'hack'.

Does this help?
I guess I don't want to get bogged down with terms and techy stuff, just that I think I've found an issue that causes my system to crash if not kept in check - are others seeing this? Is this a hardware issue (RPi defective? µSD causing this issue? Older DSLR with latest software? Power instability in the cold? etc!) or software (KStars clashing with Conky/Anydesk? ETC ETC?) What's the root cause is where I'm aiming!

On a last note about the plot - the USED memory (bottom red/pink plot) starts low, then jumps up as KStars/EKOS/Indi is started and the imaging session is started, then stays fairly constant throughout the process, before jumping up a bit more at the end as I start looking at the files and thinking about getting data off for analysis.

Read More...