I’m hacking on a SatNOGS station monitor. There are several motivations which led to this project, some are:
I wanted to know…
…what my station is doing.
…what observations are up next.
…is the station working at all.
I want to do all this within my terminal and it should be fast.
Have something I can show potential new ground station owners. It’s easier when you can show something in realtime while talking over SatNOGS.
Play around with the network/db API
I needed a project to learn some more Rust.
The current state is already useful to me but in an very early stage where I play around with concepts and layout possibilities. You’ll have to change the source if you want monitor your station.
The most interesting thing for me right now is what information other station operators are interested in and want to see in something that calls itself station monitor. Any input on this is highly appreciated!
And just because I hate it, when someone teases me with an image without showing a single line of code, even if it’s a huge mess… here is the mess:
That is awesome. It is something that is really missing from my GS. It shows all the useful information that I am after although I hadn’t thought that a terminal would be a good solution. Turns out I was very wrong. Look forward to seeing it showing my details.
One small thing to think about. I have potentially 2 GS’s (one is working and the other is being built). Can it handle more that one GS. Or would it need two screens (hang on that sounds even better )
The tabs at the top of the screenshot show the stations. You’ll be able to configure a number of stations and switch between them. Probably even jump automatically to one if an interesting event (failed obs, start of obs,…) occurs. The network tab will show an overview of the network and your configured stations. That said, this is not implemented yet but it definitely will be.
I have one ground station in production and building a second one with rotator and I want everything in one window
Very good initiative!, I was looking for something like that but my coding skills are too poor to write anything similar… Thanks, will try to install it on our station, Marco. IW1DGG
Nothing is preventing you from running one instance for each station.
At the moment it’s not bound to the station. You can run it on any Linuxish system. MacOS should also work. Windows won’t for now, I’ll have to switch the terminal library I’m using and Windows support is not a very high priority since you should be able to run it on the RPi and ssh to it.
I had a quick go at running it this evening but ran into a couple of errors. I’m on Ubuntu 18.04 and had to install freetype2 no big deal but then I’m stuck with this error when running satnogs monitor
error: Edition 2018 is unstable and only available for nightly builds of rustc.
warning: build failed, waiting for other jobs to finish...
error: build failed
I’m guessing that something isn’t happy so other than that error message I’m not sure. Perhaps come back to it later when my brain is working
I didn’t realize the 2018 edition was not stable yet. Until it is (at 06.12.) you’ll have to use a beta or nightly build of Rust. Sorry about that. I updated the Readme with the new dependency information.
In short:
rustup install beta
git pull
cargo +beta run --release
The freetype2 dependency is odd. Was it needed for libgpredict? I will replace this with a pure Rust implementation someday, since libgpredict doesn’t seem actively maintained.
I am guessing that the freetype dependency was on alacritty and I assume it was a local problem. The error messages are explicit enough to work out even for simple people like me.
I’ll have another go later (once I’ve fixed the leaking tap, made some shelving etc that I’m getting told off for not doing round the house )
While Alacritty really is a great terminal emulator, I don’t want to enforce it on anybody who want’s to try the satnogs-monitor. I tested it yesterday in rxvt-unicode, but the colors were messed up. If you run it within a tmux session everything looks ok, just the header has the wrong color. I’ll replace the few colors which are not supported and see how it looks.
I also build everything for the RPi yesterday and it works quite well over ssh. The build will take some time (about 45min) if you’re not cross compiling and building it directly on the RPi. Since the filesystem isn’t touched (no cache, log files, etc. yet) it should have no impact on the lifetime of the SD card.
)
