update README and Makefile
bert hubert
parent
ee24f6f639
commit
ac76ba1d28
10
Makefile
10
Makefile
|
|
@ -2,12 +2,12 @@ CXXFLAGS:= -std=gnu++17 -Wall -O3 -MMD -MP -ggdb -fno-omit-frame-pointer -Iext/
|
|||
|
||||
PROGRAMS = navparse ubxtool navnexus navrecv navdump
|
||||
|
||||
all: $(PROGRAMS)
|
||||
all: navmon.pb.cc $(PROGRAMS)
|
||||
|
||||
-include *.d
|
||||
|
||||
clean:
|
||||
rm -f *~ *.o *.d ext/*/*.o $(PROGRAMS)
|
||||
rm -f *~ *.o *.d ext/*/*.o $(PROGRAMS) navmon.pb.h navmon.pb.cc
|
||||
|
||||
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
|
||||
|
|
@ -26,11 +26,9 @@ navrecv: navrecv.o ext/fmt-5.2.1/src/format.o $(SIMPLESOCKETS) navmon.pb.o stora
|
|||
$(CXX) -std=gnu++17 $^ -o $@ -pthread -lprotobuf
|
||||
|
||||
|
||||
|
||||
|
||||
navmon.pb.h: navmon.proto
|
||||
navmon.pb.cc: navmon.proto
|
||||
protoc --cpp_out=./ navmon.proto
|
||||
|
||||
ubxtool: ubxtool.o ubx.o bits.o ext/fmt-5.2.1/src/format.o galileo.o navmon.pb.o gps.o
|
||||
ubxtool: navmon.pb.o ubxtool.o ubx.o bits.o ext/fmt-5.2.1/src/format.o galileo.o gps.o
|
||||
$(CXX) -std=gnu++17 $^ -o $@ -lprotobuf
|
||||
|
||||
|
|
|
|||
66
README.md
66
README.md
|
|
@ -1,5 +1,51 @@
|
|||
# galmon
|
||||
galileo open source monitoring
|
||||
galileo/GPS open source monitoring
|
||||
|
||||
Theoretically multi-vendor, although currently only the U-blox 8 chipset is
|
||||
supported.
|
||||
|
||||
Goals:
|
||||
|
||||
1) Support multiple wildly distributed receivers
|
||||
2) Combine these into a forensic archive of all Galileo/GPS NAV messages
|
||||
3) Make this archive available, offline and as a stream
|
||||
4) Consume this stream and turn it into an attractive live website
|
||||
(https://galmon.eu/). As part of this, perform higher-level calculations
|
||||
to determine ephemeris discontinuities, live gst/gps/galileo time
|
||||
offsets, atomic clock jumps etc.
|
||||
5) Populate an InfluxDB timeseries database with raw measurements and higher
|
||||
order calculations
|
||||
|
||||
To get started, make sure you have a C++17 compiler, git, protobuf-compiler,
|
||||
libh2o-dev.
|
||||
|
||||
```
|
||||
git clone https://github.com/ahupowerdns/galmon.git --recursive
|
||||
cd galmon
|
||||
make
|
||||
```
|
||||
|
||||
If this doesn't succeed with an error about h2o, make sure you have this
|
||||
library installed, and if you have remove the # in front of "# -lwslay".
|
||||
This may solve the problem.
|
||||
|
||||
Once compiled, run for example ./ubxtool /dev/ttyACM0 1 | ./ubxparse 10000 html null
|
||||
|
||||
Next up, browse to http://[::1]:10000 (or try http://localhost:10000/ and
|
||||
you should be in business. ubxtool changes (non-permanently) the
|
||||
configuration of your u-blox receiver so it emits the required frames for
|
||||
GPS and Galileo. If you have a u-blox timing receiver it will also enable
|
||||
the doppler frames.
|
||||
|
||||
To see what is going on, try:
|
||||
|
||||
```
|
||||
./ubxtool /dev/ttyACM0 1 | ./navdump
|
||||
```
|
||||
|
||||
Setting up a distributed setup is slightly more complicated & may still
|
||||
change.
|
||||
|
||||
|
||||
Tooling:
|
||||
|
||||
|
|
@ -7,18 +53,13 @@ Tooling:
|
|||
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.
|
||||
UPDATE -> will be part of ubxtool
|
||||
frames & metadata. Not done yet.
|
||||
* 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.
|
||||
UPDATE -> part of navnexus
|
||||
* 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
|
||||
* navnexus: tails the files stored by navrecv, makes them available over
|
||||
TCP
|
||||
* navpartse: consumes these ordered nav updates for a nice website
|
||||
and 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
|
||||
|
|
@ -40,9 +81,6 @@ Big TODO
|
|||
* Dual goals: completeness, liveness, not the same
|
||||
For forensics, great if the packet is there
|
||||
For display, not that bad if we missed a message
|
||||
* Navnexus permanence
|
||||
lmdb? sqlite?
|
||||
* It looks like we have some ups and downs in WN/TOW
|
||||
* In general, consider refeed strategy
|
||||
Raw serial
|
||||
Protobuf
|
||||
|
|
|
|||
Loading…
Reference in New Issue