An open letter about ESEO telemetry specifications

Dear Piero Galeone and Antonio de Luca,

As an Amateur Radio operator experienced in the field of Amateur satellites and in the space industry, I am publishing this open letter to motivate and request the release of the complete technical specifications for the telemetry that the ESEO satellite will transmit in the frequency 437.00MHz, in the 70cm Amateur satellite band.

According to the ITU Radio Regulations for the Amateur and Amateur-satellite Services, “Transmissions between amateur stations of different countries shall not be encoded for the purpose of obscuring their meaning, except for control signals exchanged between earth command stations and space stations in the amateur-satellite service.” A strict interpretation of this rule means that the specifications of all digital protocols used by Amateur stations should be publicly available, so that anyone is able decode the data. The use of protocols with undisclosed specifications can be seen as a try to obscure the meaning of the data.

Continuing with the ITU Radio Regulations, the definition of the Amateur service describes it as “a radiocommunication service for the purpose of self-training, intercommunication and technical investigations carried out by amateurs, that is, by duly authorized persons interested in radio technique solely with a personal aim and without pecuniary interest.” In my opinion, the use of protocols with undisclosed specifications goes against the spirit of this definition, in particular, it can hinder technical investigations and self-training.

For these reasons, I am a strong proponent of requiring that all the protocols used by Amateur stations have publicly available specifications, allowing anyone to decode the data, study the protocols, learn, experiment and improve upon the state of the art. In view of the paragraphs cited above, publishing the full specifications so that anyone can build a complete decoder independently is both an obligation and the best practice.

This is especially important for Amateur satellites, which often use at least some form of ad-hoc protocols in their telemetry downlink. The public specifications for this telemetry downlink are often incomplete or inexistent. As an attempt to remedy this situation, I develop gr-satellites, which aims to decode every satellite that transmits in Amateur bands. Developing this tool usually requires some reverse engineering, due to the lack of documentation. Some similar tools by other Amateurs are the Soundmodem decoders by Andrey Kopanchuk UZ7HO and the Telemetry decoders by Mike Rupprecht DK3WN, who face similar challenges.

A large number of Amateur operators and enthusiasts throughout the world routinely use these tools to decode telemetry from Amateur satellites, contributing valuable data to the satellite operators through the SatNOGS network and other databases. Also, these tools can be an invaluable reference to educational or research institutions or companies that start building satellites.

Regarding the ESEO satellite, I believe that the educational and collaborative aims of the project is in line with the self-training and investigation aspects of the Amateur service. Thus, publishing complete specifications for the telemetry downlink seems the best practice to respect the goals of the project.

Additionally I think ESA should be held to the highest standards and be exemplary in publishing the specifications. This is specially important, since currently it is often hard to get documentation from the developers of many Amateur satellites.

While some documentation for ESEO has already been published, this is not enough to build a complete telemetry decoder. For instance, the equations needed to interpret the raw telemetry readings such as voltage, current and temperature are missing.

I hope that this letter serves to raise awareness about the need of publishing specifications for the protocols used in the Amateur service and that a complete set of documentation is published for ESEO, allowing Amateurs to build their own telemetry decoders.

Best regards,

Dr. Daniel Estévez, EA4GPZ.



9 Replies to “An open letter about ESEO telemetry specifications”

    1. Hi John,

      That information is about the FUNcube 4 payload in ESEO. To be clear about this, there are several payloads with radio transmitters onboard ESEO.

      One of them is FUNcube 4, which is based on the payloads in previous FUNcube satellites. The documentation available is complete, ranging from what is the modulation, the FEC, the meaning of each bit, and what are the formulas to transform binary data into telemetry values.

      Another payload has a telemetry downlink at 437MHz. This is the payload addressed in this post. The information about this payload is here and here. I haven’t seen any additional documentation regarding this transmitter.

      From the information published, the first document is a bit strange. First it explains some generalities about AX.25, hinting that the modulation and coding will be standard 9k6 FSK packet radio. However, it seems that several kinds of AX.25 control packets are used for telecommand, and it says that UI frames are not used in ESEO. Literally every other satellite I’ve seen that uses AX.25 uses UI frames to send the telemetry. I don’t have a clear idea about which AX.25 frames are used to send the telemetry (but I didn’t read the document thoroughly). At the end of this document, some information about Reed-Solomon is included. However, AX.25 doesn’t use Reed-Solomon, and there is no information about how this is used in the frames. Also, the information about the of the finite field and generator polynomial is not enough to specify a Reed-Solomon code completely (for instance, see the issue with conventional vs. dual basis for CCSDS Reed-Solomon).

      The second document only contains the names and sizes of the fields of the telemetry packets. There are no formulas to convert this to meaningful values or even whether each field should be read as signed or unsigned integer or floating point. Also, there are several beacon types but there is no indication about how to distinguish between them.

      That’s what I got from a quick read through the documents. There might be other issues or something I missed.

    1. Hi Piero,
      As you can see from the other comments in this post, I had already looked at that document. However, yesterday a new document was published here (this is an updated version of the “attachment 2” document). This document contains much more info than the previous version and it is probably enough to build a fully working telemetry decoder. From a first read, I still don’t know how to distinguish the different beacon types, but probably this will be easy to figure out by looking at some packets.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.