Yesterday, the FM repeater on the Amateur satellite LilacSat-2 was active. I’ve talked about LilacSat-2 before, but so far I hadn’t made any recordings containing subaudio telemetry. While contacting several Spanish stations (EA5TT, EA1JM and EA1IW) throughout the pass, I made an IQ recording to analyse the telemetry later. Here I take a look at the telemetry format and the decoded data.
A scrambler is a function that is applied to a sequence of data before transmitting with the goal of making this data more “random-like”. For instance, scrambling avoids long runs of the bits 0 or 1 only, which may make the receiver loose synchronization or cause spectral concentration of the signal. The receiver applies the inverse function, which is called descrambler, to recover the original data. The documentation for the scrambler blocks in GNUradio is not very good and one may need to take a look at the implementation of these blocks to get their parameters right. Here, I’ll try to explain a bit of the mathematics behind scramblers and the peculiarities of their implementation in GNUradio.
Yesterday, there was a big hailstorm in my town. During the storm, I rushed to the radio shack to see if this produced any effects in my Ku-band satellite receiver. This is a 95cm dish pointing to the 26ºE geostationary orbital position, and it will be used to receive Es’hail-2 in the future. In the image below, you can see that the difference is huge.
In the waterfall, you can see several beacons from broadcast satellites. It is clear that during the hailstorm the noise floor was much higher. In fact, 2.5dB higher. This is probably caused by scattering of DVB-S signals from satellites in other orbital positions, scattering of thermal ground noise, or a combination of both. Also, although it is not easy to see in the waterfall, the beacons of the satellites where weaker during the hailstorm. For instance, the beacon of BADR-5 was 0.9dB weaker, due to the increased attenuation caused by hail.
These differences may not seem large, but in fact they are. I have a cheap DVB-S2 decoder connected to the system. It usually receives fine several channels from the BADR satellites (on some other channels, the signal is not good enough, apparently). However, during the hailstorm, this receiver couldn’t even get a lock on the DVB signal.
Recently, Mike DK3WN pointed me to some decoder software for the satellite GOMX-3. This satellite is a 3U cubesat from GomSpace and transmits in the 70cm Amateur band. It has an ADS-B receiver on board, as well as an L-band SDR. As far as I know, no Amateur has decoded packets from this satellite previously, and Mike had some problems running the decoder software. I have taken a look at the software and tried my best to decode some packets from GOMX-3. So far, I have been able to do Reed-Solomon decoding and get CSP packets. However, I don’t have the precise details for the beacon format yet. Here, I describe all of my findings.
This weekend has being very rainy, so I haven’t been able to participate in the national V-UHF contest with my usual portable setup. Instead, I have driven to the countryside just outside town and used the mobile antenna on my car to work in the contest from inside the car. This antenna is a 50cm vertical whip which is magnetically mounted on the roof of the car. Of course, due to the low gain and polarization mismatch, I am only able to work some local contacts with this antenna. In this way, I have been able to have a couple hours of fun this morning without getting wet.
As always, the map of stations worked below. My position is in red. Stations in blue where worked only in 144MHz. Stations in green where worked both in 144MHz and 432MHz.
The current features of this decoder are as follows:
- FEC decoding of both long frames and short frames using the code from bbctl (this code is included in the Gnuradio decoder)
- CSP header parsing according to the specifications in Wikipedia
- Parsing of the COM and EPS fields in telemetry beacons, using the code from the university team
In the future, I would like to be able to parse more data from the satellite, but I don’t have the format specifications. I’m trying to get the university team to send me some information.
After sorting out some problems with several connectors which caused huge phase noise in the external 27MHz reference, I have my 10GHz receiver up and running as it should. This station will be used to receive Es’hail-2 in the future. The station is composed of a 95cm offset dish, an Avenger PLL321S-2 Ku-band LNBF modified to use an external 27MHz reference, an OCXO/Si5351A kit used as the 27MHz reference, an RTL-SDR, and a cheap DVB-S2 receiver as a power supply (this allows me to change polarizations and LO frequency easily).
The dish is pointing to the 26ºE or 25.5ºE orbital position, where Es’hail-2 will be. Actually, I have pointed the dish to peak the beacon from BADR-5 the best I can. To test the performance of the station, I have tried to receive the beacons from several Ku-band satellites. Here are the results.
Today I woke up early to receive the signals from AAUSAT-4 as it passed over Spain for the first time. This satellite was launched from Kourou yesterday at 21:02UTC into a Sun-synchronous orbit. The main payload for the launch was Sentinel-1B, a 5GHz Synthetic Aperture Radar satellite from the Copernicus project of the ESA. The remaining satellites that were launched by the Soyuz rocket were Microscope, from the French CNES, designed to test Einstein’s equivalence principle and the three cubesats in the Fly You Satellite! program: OUFTI-1, from the University of Liège, which carries a D-STAR amateur radio transponder, e-st@r-II, from the University of Torino, and AAUSAT-4, from the University of Aalborg, which carries an AIS receiver. Since the launch was into a polar orbit, the first pass of the Fly Your Satellite! cubesats over Spain was at 05:42UTC today.
I’m using a OCXO/Si5351A kit as an external 27MHz reference for my LNBF-based 10GHz receiver. At first, I intended to use a buffer amplifier to take out directly the 27MHz cyrstal oscillator in the kit. However, I finally configured the Si5351A to generate 27MHz, as that was simpler.
Taking a look today at the documentation for the Si5351, I’ve realised that it is possible to configure the Si5351 to connect some of its outputs directly to the crystal oscillator input, acting as a buffer and bypassing all the frequency synthesis stages. To do this, XO_FANOUT_EN, which is bit 6 in register 187 “Fanout enable”, must be set to 1. The selector CLKn_SRC, which is bits 3 and 2 of clock control register (registers 16-23), is set to 00 (XTAL source) on reset, so this is already set correctly. It is probably a good idea to set CLKn_IDRV to 11 to get the highest drive strength on the output pin.