I’ve been working on a LoRa satellite ground station based on an ESP8266 + LoRa module, as an alternative to the traditional Raspberry Pi setup used in SatNOGS.
To test it, I’ve been successfully receiving telemetry from NORBI (NORAD 46494) and uploading frames to SatNOGS DB from my station LW2DTZ in Buenos Aires, Argentina.
Since NORBI currently shows “No Decoders Found” in SatNOGS DB, I wrote a Kaitai Struct decoder (norbi.ksy) based on the official NORBY telemetry specification and verified it with real frames captured by DK3WN and my own station.
I’ve opened a Merge Request to contribute it to satnogs-decoders:
Hoping it gets approved soon so the decoded telemetry (temperature, voltage, battery charge, GLONASS position) becomes visible on the SatNOGS DB dashboard for everyone receiving NORBI.
Thanks for bringing this decoder to a merge request.
However, since Norbi’s frequency use wasn’t coordinated by the IARU, Norbi is marked as “Frequency Misuse” in SatNOGS.
This brings along a 14 days delay for the decoding of the data.
Thanks for the clarification on the 14-day delay policy.
I understand the spectrum management policy, but I think applying a 14-day delay to NORBI’s decoder is counterproductive. This satellite has been operational since 2020 and its telemetry is already publicly available in real time on TinyGS, DK3WN’s blog, and other platforms — with no restrictions whatsoever. The delay doesn’t protect the spectrum or discourage the use of uncoordinated frequencies in any way; it only penalizes SatNOGS users and contributors who are doing exactly what the community encourages: building decoders and contributing to Space Situational Awareness.
If the goal of the policy is to discourage satellite operators from skipping IARU coordination, a 14-day dashboard delay on a 5-year-old Russian university satellite achieves nothing in that regard. The satellite is already up there and won’t change its frequency.
I’d strongly suggest reconsidering the delay for satellites where the IARU coordination ship has clearly already sailed.
Regarding the QSL card — honestly, I’m not a QSL hunter. My reward in this hobby comes from a different place — building the station, decoding the signal, and contributing the decoder to the community. That’s what drives me.
You perhaps like to take a look on my thread IARU Coordination - Frequency Misuse (satellite QUBE)
where a majority of users voted to not follow the IARU decision (in the case of QUBE), but SatNOGS didn’t accept the consequences of this democratic process.
Prior to this vote, the uploaded telemetry wasn’t decoded at all.
Now they changed it to the 14 days delay.
After contributing already about 35 decoders to the community I thought about that a QSL card in exchange for writing a decoder (and usually also building a dashboard) would be appropriate.
But my question in case of Norbi is not of that background.
I am aware of the discussion and the different opinions expressed regarding the QUBE case, the IARU coordination process, and the subsequent actions taken by SatNOGS.
However, I believe this matter has already been extensively debated and I do not have anything further to add. The policies adopted by SatNOGS are decisions for the SatNOGS team and community to make, just as frequency coordination decisions are made by the respective organizations responsible for them.
From my perspective, the most productive path forward is to focus on supporting satellite operators, improving telemetry decoding capabilities, and contributing technical work that benefits the amateur satellite community as a whole.
I appreciate the considerable effort you have invested in developing decoders and dashboards over the years. Those contributions are valuable and have helped many satellite missions.
That said, I do not intend to continue discussing the QUBE/IARU/SatNOGS dispute further and will consider the matter closed on my side.
My intention to point you to the QUBE/IARU thread was not to continue this discussion, but to show you that your suggestion
won’t make SatNOGS decision-makers move even an inch.
.
.
Let’s think your LoRa decoder a step ahead.
If your decoder were to go online, it would only be able to decode LoRa beacons (no FSK) and with a 14 days delay at that.
Furthermore, the data would have to be uploaded manually, since SatNOGS does not offer a demodulator for the proprietary LoRa modulation to get something out of a scheduled pass with the LoRa transmitter via SatNOGS network.
My experience shows me that, by this point at the latest, you’ll be practically the only one actively contributing.
So, to now circle back to my QSL card question:
If you really like to …
… it’s not a bad idea to first ask them whether there is any interest in support at all.
In the case of Norbi, I did that six times between 2022-09 and 2025-06, every time with no response at all.
Nice work on the ESP8266 station — a LoRa receive chain that cheap, feeding SatNOGS DB, is exactly the kind of thing that grows the network.
One lesson from the dashboard side that might help once Norbi’s decoded fields flow: I run Grafana dashboards over ~23 satellites decoded with satnogs-decoders, and the hard part wasn’t the panels — it was that every decoder names and scales things differently (csp_data_payload_eps_vbatt, raw_frame_rt_tlm_batt_a_v, volts here, millivolts there). Dashboards written per-satellite stop scaling around the third bird. What worked: derive canonical fields (battery_v, battery_i, battery_pct, with heuristic mV/V scaling) next to the raw ones at ingest — one battery panel then serves the whole fleet, and the raw fields stay queryable for anyone who wants the exact values. Same pattern would apply to a Norbi dashboard from day one.