Thanks for the architecture flow graph, that helps @pierros…
Just to throw out some more context here: we’re currently collecting about 50k frames/day in satnogs-db from SiDS sources across 150 contributors (no way of telling how many are from gr-satellites vs @DK3WN’s tlm forwarder, as we don’t report/track that through the protocol)… But I throw it out there to point out that this pipeline is a critical piece of the puzzle right now, and why the “WIP” satnogs-dashboard that pierros linked to is such a priority.
satnogs-network is pulling in about 1.5k frames/day with about 50 stations in prod today (and another 23 testing in prod, and 35 in dev).
I point this out to say that we should definitely continue the manually generated pipeline that gr-satellites provides today, if that is feasible. That said, there is a lot of functionality and modes in in gr-satellites that we do not support today and we have a growing number of stations that could benefit from this collaboration!:
One other area of collaboration, I notice that @EA4GPZ has a lot of telemetry decoders already in his repo. With a little modification and relaxing the desire for kaitai format, we could plug these into the new decoding pipeline easily.
Glad to see this happening!!
-Corey