spacecruft
/
galmon
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

readme, library thing for libh2o

pull/1/head
bert hubert 2019-08-06 19:13:25 +02:00
parent 81ee669ce9
commit f3653f178e
2 changed files with 33 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Makefile
View File

@ -12,7 +12,7 @@ clean:
H2OPP=ext/powerblog/h2o-pp.o
SIMPLESOCKETS=ext/powerblog/ext/simplesocket/swrappers.o ext/powerblog/ext/simplesocket/sclasses.o ext/powerblog/ext/simplesocket/comboaddress.o
ubxparse: ubxparse.o ext/fmt-5.2.1/src/format.o $(H2OPP) $(SIMPLESOCKETS) minicurl.o ubx.o bits.o
g++ -std=gnu++17 $^ -o $@ -pthread -lncurses -L/usr/local/lib -lh2o-evloop -lssl -lcrypto -lz -lcurl
g++ -std=gnu++17 $^ -o $@ -pthread -lncurses -L/usr/local/lib -lh2o-evloop -lssl -lcrypto -lz -lcurl -lwslay
ubxdisplay: ubxdisplay.o ext/fmt-5.2.1/src/format.o
g++ -std=gnu++17 $^ -o $@ -pthread -lncurses

32
README.md
View File

@ -1,2 +1,34 @@
# galmon
galileo open source monitoring
Tooling:
* ubxtool: can configure a u-blox 8 chipset, parses its output & will
convert it into a protbuf stream of GNSS NAV frames + metadata
Adds 64-bit timestamps plus origin information to each message
* xtool: if you have another chipset, build something that extracts NAV
frames & metadata
* navtrans: transmits GNSS NAV frames emitted by ubxtool to a collector.
Performs some best effort buffering & will reconnect if needed.
* navrecv: receives GNSS NAV frames and stores them on disk, split out per
sender
* navstore: tails the file stored by navrecv, puts them in LMDB
* navstream: produces a stream of NAV updates from all sources, with a few
seconds delay so all data is in. Does this with queries to LMDB
* navweb: consumes these ordered nav updates for a nice website
* navinflux: puts "ready to graph" data in influxdb - this is the first
step that breaks "store everything in native format". Also does
computations on ephemerides.
* grafana dashboard: makes pretty graphs
The transport format consists of repeats of:
1) Four byte magic value
2) Two-byte frame length
3) A protobuf frame
The magic value is there to help us resync from partially written data.
The whole goal is that we can continue to rebuild the database by
rerunning 'navstore' and 'navinflux'.