HYDRA-T is a PocketQube developed and operated by the Spanish start-up Hydra Space. It was launched on SpaceX’s Transporter 12 mission on January 12, and according to this news article (in Spanish), it is very similar to HADES-R, another PocketQube also launched in Transporter 12 and developed by Hydra Space and operated by AMSAT-EA, the Spanish amateur satellite society. While HADES-R is an amateur satellite that carries a transponder for amateur radio communications, HYDRA-T is a commercial satellite which according to the news article carries a payload from the 6G-XTREME CON-SAT project from Universidad Carlos III de Madrid related to 6G deployment.
Some days ago, people in the LibreSpace forums started noticing that HYDRA-T was transmitting telemetry on 437.780 MHz, which is a frequency that belongs to the amateur satellite service 435 – 438 MHz band. This was acknowledged by Félix Páez EA4GQS, who is AMSAT-EA’s president and Hydra Space Software and Satellite Operations Manager. Félix expressed that HYDRA-T should not be transmitting in this frequency even if it has a license to do so.
I could delve more and give my opinion about whether HYDRA-T can rightfully transmit on this frequency, specially given the fact that it is doing so under the Earth Exploration Satellite Service (active) allocation (see the frequency allocation tables from ITU, and the ITU Space Explorer entry for this satellite, which for some reason is listed there as HYDRA-A), which is a whole different usage from a telemetry downlink of a communications satellite. Maybe I will do this another time. In this short post I wanted to focus on the analysis of the short telemetry recording shared by Jan van Gils PE0SAT, and show the similarities between HYDRA-T and HADES-R, as well as previous satellites from AMSAT-EA, for which documentation of their telemetry format is publicly available.
The recording shared by PE0SAT is an audio-frequency recording that contains a single telemetry packet. The modulation is 200 baud FSK with a deviation of approximately 560 Hz (I haven’t attempted to measure the deviation accurately). A waterfall of the recording is shown here.
After some analysis, I have seen that the coding used in this telemetry packet is the same as the one used by HADES-R. The news article was not wrong to say that HADES-R and HYDRA-T are very similar. The HADES-R telemetry is documented here, and this documentation also applies to MARIA-G, UNNE-1 and HADES-ICM, which are all upcoming satellites by AMSAT-EA.
The HADES-R telemetry is very similar to the HADES-D telemetry (documented here). The only differences are that HADES-D uses 50 baud FSK with 500 Hz deviation, while HADES-R uses 200 baud FSK with 562.5 Hz deviation, and that the correspondence between packet types and the length and telemetry format of each packet type is different. I had already implemented a HADES-D deframer in gr-satellites. The only thing I have needed to do to extend it to support HADES-R is to define a new list of mappings between packet types and packet lengths.
I have used the following GNU Radio flowgraph to decode this HYDRA-T packet using the Satellite decoder block from gr-satellites configured for HADES-R. Besides the Satellite decoder block, the rest is just plumbing to convert the audio frequency recording to complex baseband.
The flowgraph produces the following packet, which passes the CRC-16 check.
0000: 1a 38 25 10 00 00 00 00 00 00 00 cb b8 6d 95 ff
0010: 43 03 40 00 fe 01 22 ad 11 00 00 00 00The packet type is given by the 4 MSBs in the first byte, so it is 1 in this case. According to the HADES-R documentation, packet type 1 is 31 bytes long and contains some voltage and current information. The length of this telemetry packet measured by hand in Inspectrum matches this 31 byte length.
The address of the transmitting satellite is given by the 4 LSBs of the first byte. In this case, the address is 0xa, which does not appear in the HADES-R documentation. The following addresses are listed: 0x2 HADES-ICM, 0xb MARIA-G, 0xc UNNE-1, 0xd HADES-R.
There is an AMSAT-EA telemetry parser software for HADES-R. This will refuse to parse this HYDRA-T packet with a “Satellite is unknown” error because it checks the address field. By commenting out that check, the following output is produced.
sat_id : 255 (Unknown)
sclock : 1058104 seconds (12 days and 05:55:04 hh:mm:ss)
spi : 0 mW (total instant power)
spa : 0 mW (last 3 mins peak)
spb : 0 mW (last 3 mins peak)
spc : 0 mW (last 3 mins peak)
spd : 0 mW (last 3 mins peak)
vbus1 : 5576 mV bus voltage read in CPU.ADC
vbus2 : 4092 mV bus voltage read in EPS.I2C
vbus3 : 4096 mV bus voltage read in CPU.I2C
vbat1 : 5584 mV bat voltage read in EPS.ADC
vbat2 : 4092 mV bat voltage read in EPS.I2C
vbus1-vbat1 : -8 mV
vbus3-vbus2 : 4 mV
vcpu : 1213 mV
icpu : 17 mA @DCDCinput
icpu : 57 mA @DCDCoutput (estimation)
ipl : 511 mA (Last payload current)
ibat : 34 mA (Current flowing out from the battery)
peaksignal : 0 dB
modasignal : 0 dB
lastcmdsignal : 0 dB
lastcmdnoise : 0 dB
All this telemetry makes sense assuming that HYDRA-T was in eclipse (Jan PE0SAT didn’t say when he made the recording).
Edit 2025-02-07: Bob N6RFM has noticed that the packet needs to be passed to this software in upper case hex. Passing it in lower case hex (which is how I obtained the values above), will cause wrong output values rather than an error. These are the correct values obtained by converting the packet decoded by GNU Radio to upper case.
sat_id : 10 (Unknown)
sclock : 1058104 seconds (12 days and 05:55:04 hh:mm:ss)
spi : 0 mW (total instant power)
spa : 0 mW (last 3 mins peak)
spb : 0 mW (last 3 mins peak)
spc : 0 mW (last 3 mins peak)
spd : 0 mW (last 3 mins peak)
vbus1 : 4138 mV bus voltage read in CPU.ADC
vbus2 : 4092 mV bus voltage read in EPS.I2C
vbus3 : 4096 mV bus voltage read in CPU.I2C
vbat1 : 4151 mV bat voltage read in EPS.ADC
vbat2 : 4088 mV bat voltage read in EPS.I2C
vbus1-vbat1 : -13 mV
vbus3-vbus2 : 4 mV
vcpu : 2835 mV
icpu : 17 mA @DCDCinput
icpu : 24 mA @DCDCoutput (estimation)
ipl : 429 mA (Last payload current)
ibat : 34 mA (Current flowing out from the battery)
peaksignal : 0 dB
modasignal : 0 dB
lastcmdsignal : 0 dB
lastcmdnoise : 0 dB
In this post I have shown that a HYDRA-T telemetry packet recorded by Jan PE0SAT on 437.780 MHz uses exactly the same modulation, coding and telemetry format that HADES-R. Since this analysis is limit to a single telemetry packet, this does not exclude the possibility that HYDRA-T might use other packet types which are different from those used by HADES-R, and thus not included in the publicly available AMSAT-EA documentation.
Thank you for the analyses and inside into HYDRA-T.
The input file was created 2025-02-03T21:34:19 when passing my station, and this was indeed when the satellite was in eclipse.
Hi Dani,
Thanks for doing this, and to Jan for providing the test IQ!!
When commenting out line 1089 of HAFES-R-main/byte_version/main.c file, the resulting file does not re-compile (make command), and throws an error. Will investigate further. Maybe I was on the wrong line.
As a less elegant alternative, from the decode you obtained instead I changed the hex 1a at the beginning to 1d to trick the stock decoder into treating this as HADES-R frame. From this, I was able to obtain the results below;
20250206-14:14:50 : Running…
20250206-14:14:50 : Processing file jan.txt
20250206-14:14:50 : Bytes read : 1D 38 25 10 00 00 00 00 00 00 00 CB B8 6D 95 FF 43 03 40 00 FE 01 22 AD 11 00 00 00 00
*** Power packet received on local time 20250206-14:14:50 ***
sat_id : 13 (HADES-R)
sclock : 1058104 seconds (12 days and 05:55:04 hh:mm:ss)
spi : 0 mW (total instant power)
spa : 0 mW (last 3 mins peak)
spb : 0 mW (last 3 mins peak)
spc : 0 mW (last 3 mins peak)
spd : 0 mW (last 3 mins peak)
vbus1 : 4138 mV bus voltage read in CPU.ADC
vbus2 : 4092 mV bus voltage read in EPS.I2C
vbus3 : 4096 mV bus voltage read in CPU.I2C
vbat1 : 4151 mV bat voltage read in EPS.ADC
vbat2 : 4088 mV bat voltage read in EPS.I2C
vbus1-vbat1 : -13 mV
vbus3-vbus2 : 4 mV
vcpu : 2835 mV
icpu : 17 mA @DCDCinput
icpu : 24 mA @DCDCoutput (estimation)
ipl : 429 mA (Last payload current)
ibat : 34 mA (Current flowing out from the battery)
peaksignal : 0 dB
modasignal : 0 dB
lastcmdsignal : 0 dB
lastcmdnoise : 0 dB
Some of the numerical values above are a bit different from what was reported. Do you think changing 1a to 1d be result in such a change? BTW, I needed to change characters from lower to upper case for the stock decoder to read the file.
From – 1a 38 25 10 00 00 00 00 00 00 00 cb b8 6d 95 ff 43 03 40 00 fe 01 22 ad 11 00 00 00 00
to – 1D 38 25 10 00 00 00 00 00 00 00 CB B8 6D 95 FF 43 03 40 00 FE 01 22 AD 11 00 00 00 00
All Best,
Bob
N6RFM
Hi Bob, you need to comment out lines 1089 through 1095. That is the code that says “if the source address is none of the expected values, then print an error and exit the program”. Commenting out only line 1089 indeed causes a syntax error (you are removing the condition check, but not the body of the conditional).
Also awesome that you have realized that the hex packet needs to be written in upper case. I hadn’t realized that, because for me the lower case packet was giving reasonable values. What happens is that there is a hex2int() function in the code that handles correctly uppercase letters A-F and numbers, but returns -1 (rather than a fatal error) for anything else, including lower case letters a-f. The effect of this -1 is that the program goes on, but all the numbers read from data that includes lower case a-f are wrong (to be honest, this program is written rather badly).
So the values you obtained by giving it an upper case packet are the correct ones. There is nothing strange going on with the satellite address. If you comment the lines I mentioned, you will obtain the same values regardless of whether the packet starts with 1A or with 1D (but it needs to be all upper case).
Thanks Dani!! All good now. Cheers. Bob