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).
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.