In my previous post, I examined a recording of LilacSat-1 transmitting an image. I did some calculations regarding the time it would take to transmit that image and the time that it actually took to transmit, given that the image was interleaved with telemetry packets. I wondered if the downlink KISS stream capacity was being used completely.

You can find more information about the downlink protocol of LilacSat-1 in this post. The important information to know here is that it consists of two interleaved channels: a channel that contains Codec2 frames for the FM/Codec2 repeater and a channel that contains a KISS stream. The KISS stream is sent at 3400bps. At any moment in time, the KISS stream can be either idling, by sending c0 bytes, or transmitting a CSP packet. The CSP packets can be camera packets (which are sent to CSP destination 6) or telemetry packets (and perhaps also other kinds of packets).

I have extracted the KISS stream from the recording and examined its usage to determine if it is being used at its full capacity or if it spends time idling. The image below represents the usage of each byte in the KISS stream, as time progresses. Bytes belonging to image packets are shown in blue, bytes belonging to other packets are shown in red and idle bytes are shown in white. (Remember that you can click the images to view them in full size).

The first 3 or 4 seconds of the graph are garbage, since the signal wasn't strong enough. Then we see some telemetry packets and the image transmission starts. We observe that most image packets are transmitted leaving an idle gap between them. The size of the gap is similar to the size of the image packet. Every 10 seconds, a bunch of telemetry packets are transmitted, in a somewhat different order each time. Some telemetry packets are sent back to back, and others are interleaved with image packets. Image packets are only sent back to back just after a telemetry transmission.

The next graph shows the usage of the KISS stream averaged over periods of 5 secons. The y-axis means fraction of capacity of the link, so a 1 means that the full 3400bps are used. The capacity spent for image packets is shown in blue and the capacity used for telemetry is shown in red. The green curve is the sum of the blue and red, so it means the fraction of time that the link is not idle. We see that the link is never used completely. The total usage ranges between 60% and 90%, but never reaches 100%.

As expected, the capacity used for telemetry spikes up every 10 seconds. The blue curve is more interesting. It is roughly around 55%, but whenever telemetry is sent, it decreases a little. Just after each telemetry burst, the blue curve increases a little. This matches the behaviour we have seen in the previous graph. Every 10 seconds a telemetry burst is sent, using up some capacity that would normally be spent for image. After the telemetry burst, some image packets are sent back to back in a burst, peaking up to 60% capacity, but soon the packets continue being sent with idle gaps between them, and the capacity goes down to 55%.

It is a bit strange that the link is not fully utilised. One would expect that image packets are sent as fast as possible, stopping only to send telemetry. However, we have seen that there are many idle gaps. It seems that the image can't be read very fast or that there is some other throttling mechanism. This would explain why a burst of image packets is sent after each telemetry burst: the image packets buffer up, because the link is sending telemetry. When the link is no longer busy with telemetry, it sends all the buffered image packets in a row, but soon enough image packets can't be produced as fast as the link sends them, so idle gaps appear. This seems quite an important performance issue, as it appears that image transmission speed is capped at about 1870bps.

The Python code that generated these graphs can be seen below. The KISS file is also in the same gist.

## Testing LilacSat-1 Codec2 downlink and GPS telemetry

Today I've finally had some time to test the LilacSat-1 Codec2 downlink on the air. I've been transmitting and listening to myself on the downlink during the 17:16 UTC pass over Europe from locator IN80do. The equipment used is a Yaesu FT-2D for the FM uplink, a FUNcube Dongle Pro+ and my decoder from gr-satellites for the downlink, and a handheld Arrow satellite yagi (3 elements on VHF and 7 elements on UHF). Here I describe the results of my test.

## Waterfalls from QB50

In the previous post, I analysed a QB50 recording. Now I have prepared some waterfalls from my recording using the procedure I already described a while ago. The image above is obtained from a 1600x1024 waterfall with a resolution of 2.93kHz or 0.86s per pixel. I have labelled all the satellites and cropped it to a 1600x900 image that now I'm using as my desktop wallpaper.

I have also made a large 14120x16384 image with a resolution of 183.1Hz or 0.1s per pixel. The image can be downloaded here (142MB). I have found the following interesting crops within the large image. Remember that you can click on each image to view it in full size.

The fast fading that I detected in nSIGHT is clearly visible below. Note that the beacon period is almost, but not quite, an integer multiple of the fading period.

In the image below, we can see that SpaceCube is not very stable in frequency. The carrier frequency tends to rise rapidly each time that the transmitter goes on. Also, the overall trend is a frequency increase, counteracting the frequency decreasing effect of Doppler. This excerpt is near the end of SpaceCube's pass, so the change in Doppler is not so large. The other French satellite, X-CubeSat, also shows a similar behaviour.

AAUSAT-4 usually transmits in 4k8 FSK using CCSDS FEC, but it also transmits a CW beacon sometimes. Both can be seen below.

Finally, a couple of CW satellites with interesting behaviour. On the upper part of the image below we can see BeEagleSat with fading. On the lower part, we can see Aalto-2 with its characteristic sidebands.

## A tour of QB50

The QB50 project consists in a constellation of cubesats with the goal of studying the thermosphere. The cubesats are built by different universities around the world and each of them carries one of three different scientific instruments. A total of 36 cubesats have been built for the QB50 project. All of them transmit on the 70cm Amateur satellite band. A total of 28 were launched to the ISS on April 18th on the Cygnus CRS-7 resupply ship. Over the last two weeks, they have been released from the ISS. The complete launch schedule and radio information can be found here (note that the launches on May 23rd were delayed due to an unforeseen EVA). Several other non-QB50 cubesats, some of them transmitting in the Amateur bands, have also been released together with the QB50 satellites. This is probably the time that more Amateur satellite have been released at the same time. The satellites have not separated much yet, giving a great opportunity to record a single pass and analyse the telemetry of all the satellites.

A few days after the release of all the 28 QB50 cubesats, on May 29th at 18:25:29 UTC, I made an SDR recording of the complete pass of all the cubesats. The recording spans the 3MHz of the 70cm Amateur satellite band (435-438MHz) and lasts 23 minutes and 08 seconds. It was made from locator IN80do using a 7 element handheld yagi (the Arrow satellite yagi) held in the vertical polarization and a LimeSDR. The gain of the LimeSDR was set to maximum, but no external LNA was used. Here I look at the recording, list the satellites heard, and decode their telemetry.

## Monitoring IMD levels in the EAPSK63 contest

This weekend I have recorded the full EAPSK63 Spanish PSK63 contest in the 40m band with the goal of playing back the recording later and reporting the stations showing excessively high IMD levels. In PSK contests, it is usual to see terribly distorted signals, which are the result of reckless operating techniques and stations which are setup inadequately. Contest rules don't help much, as they are usually too weak to prevent distorted signals from interfering other participants. Amateurs should take care and strive to produce a signal as clean as possible. For instance, in the US, Part 97 101 a) states that "each amateur station must be operated in accordance with good engineering and good amateur practice". Here I describe the signal processing done in this study and list a "hall of shame" of the worst stations I have spotted in my recording. I will notify by email the contest manager and all the stations in this list with the hope that the situation improves in the future.

## First data from BY70-1

The Amateur satellite BY70-1 launched yesterday at around 3:00UTC. The launch was a partial failure, as all the satellites from this launch have been put in a 520x220km orbit. The perigee is too low to support a long duration orbit, and the satellites will decay in a couple months. BY70-1 has a 9k6 BPSK telemetry downlink on 70cm. This downlink is also used to download JPEG images from the onboard camera. I've talked about this in a previous post.

Since I'm at 33C3, I haven't been able to receive this satellite with my own equipment yet. However, Tetsu JA0CAW already has posted some IQ recordings. Here I look at recording1 and recording2.

My first impression is that the packets are not very strong. I don't know if this is something about JA0CAW's station or that the downlink of BY70-1 is not very strong. I've only managed to decode the strongest packets in the recording. In comparison, LilacSat-2 has a very strong downlink and I can decode correctly almost from horizon to horizon with a handheld 7 element yagi.

Perhaps it's possible to do some optimization of the decoder parameters such as filter width or loop bandwidths, but so far I haven't experimented much. I just wanted to write a quick post to publish all the information I've managed to decode. I'm using the decoder from gr-satellites. The decoder log from recording1 is in this gist. From recording2 I could only decode a couple of JPEG packets and no telemetry packets.

There are three distinct types of telemetry packets. It seems that BY70-1 transmits all the three types in a single burst. Another curiosity: the message in one of the telemetry packets uses the callsign ON02CN, which is the Belgian callsign that LilacSat-1 will use. Since LilacSat-1 is part of the QB50 project, it makes sense that it uses a Belgian callsign. However, it seems that it's some sort of software configuration error that BY70-1 is also using this callsign.

Update on 30/12/2016: I have found that there was a problem with the Costas loop bandwidth in the GNU Radio receiver on gr-satellites. Its value was too large. I have copied the value from the example demodulator on gr-lilacsat and now the decoder works much better. I have even been able to decode the following image from recording2.

The result looks pretty bad, but the keen eye will notice that in fact there are few packets lost in this JPEG image. Compare with the image posted by BG2BHC, which has no errors and is presumably the same image.

This is a follow up post to my experiments studying OTH radar. I have found that the signal processing I did there to obtain the cross-correlation was far from optimal. This produced the strange side-bands below the main reflection. The keen reader might have noticed that I was doing the cross-correlation with a template pulse that lasted the whole pulse repetition cycle. However, the pulses from the radar are shorter. Therefore, it is a better idea to use a shorter template pulse. Ideally, the template pulse should have the same length as the transmitted pulse. However, I don't know this length precisely, because multipath propagation makes the received pulses a bit longer. However, I think that 6.5ms is a good estimate.

I have also changed the window for the pulse. I'm now using a Dolph-Chebyshev window. I use scipy to compute this window, because it is not included in GNU Radio. This window has the property that the side-bands have constant attenuation. Indeed, it minimizes the $L^\infty$ norm of the side-bands. There is a parameter that tunes the side-bands attenuation. For higher attenuations, you have a wider main lobe, while if you want a narrower main love you get less side-band attenuation. These properties make this window useful in radar applications.

Below I'm doing the cross-correlation in GNU Radio with a shorter template pulse shaped with a Dolph-Chebyshev window set for 55dB attenuation.

The good thing about the settable attenuation of the Dolph-Chebyshev window is that it can be used to trade-off performance between different features. First, we use an attenuation of 100dB. The side-bands are below the noise floor in this case, so we have no "false responses" in our cross-correlation. The drawback is that the main lobe is wide so the resolution of the features of the ionosphere in the image below is not very good.

Next we try with 55dB attenuation. This narrows the main lobe, improving the resolution and crispness of the features of the ionosphere in the image below. However, side-bands start being visible above the noise floor, producing "false responses". However, comparing with the image above, we now know where the false responses are.

I have updated the gist with the GNU Radio flowgraph and python script used to produce the images.

## Looking at an HF OTH radar

Most amateur operators are familiar with over-the-horizon radars in the HF bands. They sometimes pop up in the Amateur bands, rendering several tens of kilohertzs unusable. Inspired by Balint Seeber's talk in GRCon16, I've decided to learn more about radars. Here I look at a typical OTH radar, presumably of Russian origin. It was recorded at my station around 20:00UTC on 8 December at a frequency around 6860kHz. This radar sometimes appears inside the 40m Amateur band as well.

## Testing Opera sensitivity with GNU Radio

Some fellow Spanish Amateur Operators were talking about the use of the Opera mode as a weak signal mode for the VHF and higher bands. I have little experience with this mode, but I asked them what is the advantage of this mode and how it compares in sensitivity with the JT modes available in WSJT-X. I haven't found many serious tests of what is the sensitivity of Opera over AWGN, so I've done some tests using GNU Radio to generate signals with a known SNR. Here I'll talk about how to use GNU Radio for this purpose and the results I've obtained with Opera. Probably the most interesting part of the post is how to use GNU Radio, because it turns out that Opera is much less sensitive than comparable JT modes.

## Some measurements of CAS-2T on orbit 25

Last Thursday, a CZ-11 Chinese rocket launched from Jiuquan. Alan Kung BA1DU posted in amsat-bb some minutes after launch saying that this launch contains an Amateur payload: CAS-2T. As it is usual with Chinese Amateur satellites, little information is available publicly and we hadn't heard about CAS-2T before.

According to BA1DU, CAS-2T is a 2U Cubesat with a CW beacon on 70cm and a V/U FM transponder. The satellite will not separate from the upper stage of the rocket, so it will decay between 10 and 30 days before launch. However, this is not correct. After launch, CAS-2T was identified as object 2016-066E by Mike Rupprecht DK3WN using Doppler measurements. This object is on a 1030km x 500km elliptical orbit, so it will not decay soon. Apparently, due to a problem in the launch, the upper stage of the rocket has being put in this 10 year+ orbit. Indeed, there are radar TLEs for 6 objects from this launch. Four of them are on circular orbits of roughly 500km height, while the other two are on elliptical orbits of 1030km x 500km radius. All of these orbits will last for many years.

Reports of CAS-2T from Amateurs worldwide agree that the CW signal has good strength, but it suffers much fading. Unfortunately, the FM transponder does not function properly. It seems to respond well to an uplink signal, but it doesn't modulate properly, as if it lacked power or suffered some other problem. On Friday afternoon, I took an SDR recording of the CW and FM signals of CAS-2T during its orbit 25. Here I show some measurements of these signals. The recording was done with a 7 element yagi and a FUNcube Dongle Pro+, and it has been Doppler corrected using the TLE for object 2016-066E, which gives a very good match.