PW-Sat2 Ground Station Update

​
While we advertise it more prominently in other media
than on this blog, some of the readers may be aware that we support PW-Sat2,
a 2U cubesat project created by a group students from the Warsaw University of Technology.

Specifically, we're responsible for developing the ground station component. It comprises the following functionality:

• a client app to crowdsource telemetry data from amateur radio operators
  (gathered when the satellite is broadcasting telemetry while overhead) ;
• a server app to aggregate the data, validate it, and present reports;
• a command module to the server app that allows PW-Sat2 operators to uplink with the cubesat.

The ground station project is still in the relatively early stages, since a number of issues remain open. We can, however, share a few words about
the technologies employed so far.

First of all, we're set to have the entirety of data processing implemented in Akka Streams. In fact, we don't care much about
backpressure in this project, as the expected data volume is manageable on even low-end systems, and the risk of a DoS is similarly meagre. Regardless,
a stream architecture has allowed us to conveniently "wire up" various processing components necessary to go from raw telemetry frames
to pre-processed data entities.

Happily, we are able to use Akka Streams from the very level of raw data capture via radio receivers. This is thanks to a library called
flow. In fact, this is the same library that we used for
low-level controller signal capture in our promotional game,
last year at Confitura.

Less importantly (but interesting nonetheless), we've decided to try out a graph DB in a Scala environment for this project. Of course, the workload we have here
is not characterized with a particular affinity towards storage. Nevertheless, due to the experimental nature of the project we have judged it to be a good opportunity to see
how a graph-based approach fares in comparison to relational- or document-oriented ones in a "vanilla" environment.

We went with OrientDB as our DB implementation. However, we've mostly operated on the higher-level abstraction of TinkerPop 3.
TinkerPop is an agnostic JVM-based layer for graph databases. It has made major steps towards API maturity lately
(and accordingly been named an Apache Top-Level Project very recently).

For us, it meant a now-convenient graph API, especially since a quite pleasant Scala implementation is available. One has to
thread carefully, as some rough edges remain - mostly regarding case class (de)serialization - so take care to evaluate independently regardless of this blog post. Fortunately, the library
certainly provides a net improvement over those Scala APIs based on previous TinkerPop implementations.

Overall, progress on the Ground Station is ongoing, and we hope to share some more tech-stack and domain info tidbits in the coming months.

PS. TinkerPop has possibly one of the most... unorthodox introductions of all IT projects. It certainly makes for an interesting read.