That is neat! I wasn't aware og such thing. I think by default the watchdog covers what I'd like to implement.
My solution tho, wants to be something that works if any if kstars/indi goes down and as you said, I'd like to have some smart introspection to be able to restart the session from where it left. I think having a dedicated program instead of a bunch of scripts may help with a couple of things
Hi John! If you are thinking of a kernel watchdog, this, in this state is somewhat similar, but with the exception that restarting a service, for kstars, specifically, cannot fully recover from a crash.
My idea is to add a bunch of custom logic to this program with time so it will eventually fit everybody's need, and eventually, one day, being able to restore a sessione to a pre-crash state
I had some free time lately and I decided to start a small side project to solve one of the issue I face sometimes when using kstars, crashing.
To be clear, I don't recall having any crash on my PC (arch) but I get a lot of them on my raspberry pi and most of the time they seem to be random, this has caused me some issues in the past, the most dangerous IMO:
- scope hitting the tripod cause the mount continue tracking after
- sessions interrupted in half
So to the point, what I am providing?
Not much at the moment, for now I am just monitoring kstars every 15s and notify people via telegram if the process stops.
I have some other ideas for the next year like expanding to different notifications type (email, sms), restarting indi and do some recovery actions (parking) and other things that may be needed, but in the meanwhile, if you want to be notified if kstars crashes on your Linux/MacOS/raspberry you can try it
You can find the project here github.com/MattBlack85/astro_monitor should you have any issue installing please reach out
It is compiled so you don't need to install any dependency, the oneliner for installing works on my linux64 box and on my raspberry 32bit, haven't tried on aarch64 and MacOS!
Should you have any issue or ideas, please open an issue on github and I'll have a look!
that is impressive, thaknks for checking that out. I am gathering more data at the moment from my colleagues, different kstars version/raspberry versions and will report back soon maybe plotting more data.
In the meanwhile, what would be the suggested right thing to do for those who owns only a raspberry? using a single star SEP? PHD2?
yesterday while guiding with the internal guider, I started to notice a weird guiding, after inspecting the logs, it seems there are big gaps between acquisition of the guiding frame and sending back the pulse command, I was using a 2s exposure and as you see from logs, elapsed time for the procedure is between 3 and 5s.
I am not sure this is my issue, but is it normal that it takes for me 1-3s to check the drift and send back the command to the mount?
awesome, thanks so much Jasem, worked like a charm!
I just started to send and receive messages, I have some more questions about the server response, not sure if this is the right place or not.
I ask for all devices properties sending a <getProperties version=1.9 /> to the server and I poll my socket to see if there is any data, I read the data and I get back some XML that looks like this gist.github.com/MattBlack85/d44f658a933cce4e15461b3b9f689ed9
Since I am polling the socket I get often a bunch of messages together and that's the reason why i see a lot of deleteProperty ? every time the server fetches new properties froma device it sends back a deleteProperty of the given device plus the properties fetched until that moment?
I don't understand well why (what I think) is the final response with all the properties contains duplicate properties like
<setTextVector device="CCD Simulator" name="DRIVER_INFO" state="Idle" timeout="60" timestamp="2021-10-05T13:13:02"><oneText name="DRIVER_NAME">CCD Simulator</oneText><oneText name="DRIVER_EXEC">indi_simulator_ccd</oneText><oneText name="DRIVER_VERSION">1.0</oneText><oneText name="DRIVER_INTERFACE">6</oneText></setTextVector><setTextVector device="CCD Simulator" name="DRIVER_INFO" state="Idle" timeout="60" timestamp="2021-10-05T13:13:02"><oneText name="DRIVER_NAME">CCD Simulator</oneText><oneText name="DRIVER_EXEC">indi_simulator_ccd</oneText><oneText name="DRIVER_VERSION">1.0</oneText><oneText name="DRIVER_INTERFACE">6</oneText></setTextVector>
Hi everyone, I am trying to learn a bit more about the indi protocol and trying to build my own client to let it talk to the indiserver so I can get a better grasp on how the entire communication works.
The only official protocol document I find is still for the version 1.7, is there any place where I can found an updated document of the protocol?
on the same boat, this is very hard to catch and debug, personally I have never seen that happening on normal routines, it failed randomly sometimes when loading and slew or just after a meridian flip (which I supposes is still because of the load and slew) and not in a consistent way
Hi Juergen and thank you very much for your precise answer!
To answer to your questions: I am not using a DSLR, I am using a ASI 533 when solving, the stellarsolver works and works pretty fast, but I have crash sometimes and that's why I am trying to make astrometry.net working, also I'd like to point out that even with the simulator I can't solve anything using astrometry.
I changed to smallscalesolving (the 0.0/0.0 has changed now, it was 0 after a reset to defaults probably), I restricted the radius search to 10, I decreased the timeout to 60 (Which anyway is not respected!) and it seems it can solve some pictures, the timing is unacceptable anyway, it thinks for ~5 minutes before giving me back a pair of coordinates so probably some options, when using astrometry.net, are not respected/optimized?
Last sessions are giving me some headaches about kstars giving up after a meridian flip. I'd like to denote that the flip it self works very well, but after the procedure kstars is crashing or eventually it doesn't restart guiding.
A friend of mine has the same exact issue and it seems to be related to the internal solver, after he switched to astrometry he's reporting no more issues.
Now to mine, I switched to astrometry to solve pictures, but it seems to have a lot of issues, the most important is that it freezes my kstars process.
At first I think it was the version (astroberry ships with 0.76) but after a bump to 0.85 the behavior is still the same, the cli seems to work good enough and pretty fast if the RA/DEC coordinates are given (see