I have been involved with AMSAT for the last couple of years, working on the ground station software FoxTelem. It decodes the telemetry from the spacecraft and sends it to the AMSAT Telemetry Server. We can then make it availabe to others for analysis, including the Universities who have placed experiments on Fox-1A (AO-85).
I got involed with Fox-1A because I love learning. I'm not a satellite expert, but I do understand software and I was keen to understand more about telemetry.
Recently I have been looking at better filtering for the High Speed data and it has led me to better filtering for both Data Under Voice (DUV) and High Speed. Today we have an aggressive 200Hz low pass filter for the DUV telemetry. This chops off the audio and leaves us with pretty clean bits. For high speed I tried various filters but they were never better than no filter. So we have AGC and DC balance, but nothing else.
I had previously explored matched filters, but it turns out I never really understood them. I thought we needed the same filter as we use on the spacecraft, but using the equivalent filter on the ground was ineffective.
It turns out that a matched filter isn't implemented the same way as the filters I currently use. The existing filters implement an array of coefficients, sometimes called taps, and we slide it over the input stream of values, adding and summing the result. This is called convolution. (We also store and add the overlap to the next set of data because we chop the input stream up.)
The filters we use are the Raised Cosine or Windowed Sinc. Longer filters, with more coefficients, produce a sharper response. So in theory more coefficients is better. That is why we have the option of long Windowed Sinc filters. They are slightly better than the Raised Cosine, but the difference is hard to measure and they use a LOT more CPU.
In contrast, a matched filter is a correlation rather than a convolution. You use a set of coefficients that mimic the shape of the pulse you want to extract from the noisy signal. Something in the mathematics means that the template is reversed, but given we have symmetrical bits we can ignore that.
To test if a matched filter would help I created a square mask like below. It is a 10 element array of coefficients with 0 in the first 3 places, 0.5 in the next 5 and 3 in the remainder:
I then ran this matched filter against the data. The two traces below show high speed data with no filter, as we have today, and high speed data with the matched fitter:
The bottom trace with the matched filter looks much better. It decodes the same number of frames in my test file.
Below we can see the Bit Signal to Noise for no filter and then with the matched filter (and with a green trace showing the running average).
Hmm, this is not what we want or expected. The SNR is worse with the matched filter...
We are getting a worse Signal to Noise ration because our bits are not square. We shape them on the spacecraft. This reduces the bandwidth that the bits take up. So let's try again with a different filter shape. If we use a matched filter that is shaped like a Raised Cosine, then we do get an improvement in the signal to noise ratio. The coefficients then look like the below set for High Speed. Notice that this is still only a filter with 10 coefficients. Notice also that the zero point where it crosses the axis is still right around coefficient 4 and 7. It is effectively a shaped bit for us to match.
The raised cosine matched filter produces a nicer looking signal. Now the bits have much more equal heights.
The Signal to Noise Ratio is also better. Not dramatically better, perhaps 0.2 - 0.5dB, but better than either no filter or the square matched filter.
I tried a Windowed Sinc matched filter but the results were not as good.
As a test I slightly detuned the signal. Given this is Frequency Modulation, that had the effect of introducing more noise. The raised cosine matched fitler definitely helped. We decode more frames than without a filter. That seems significant enough to include it in the next release, even though the measurements above are not compelling.
After some success with high speed I decided to repeat this experiment for DUV with unexpected (for me) results. As I said at the top of the email, today we default to a 512 coefficient Raised Cosine filter. That is the default from testing, by the way, not because theory says it is the best.
I started with a square matched filter again. Below are the existing filter followed by the square matched filter:
It does a remarkable job of recovering the bits given it does not actually filter out the audio. You can clearly hear the QSO still if you listen to the filtered audio. Even more amazing is the fact that the matched filter decodes all 63 frames from the test file, just like the existing filter.
The eye diagram is triangular, as shown in the second trace above. This is expected from the theory because a perfectly square bit, correlated with a square mask, which is then slid across it, results in a triangle shape. That is a bit hard to follow, I know, but this page explains it well.
When we look at the Signal to noise of the bits, it is worse, just as it was for the High Speed. This is the SNR for the existing filter and then the matched filter:
Next I tried both the raised cosine and windowed sinc. These have 480 coefficients because each bit is 240 samples long, at least at 48000 samples/sec. The shapes are now much more defined as you can see below, but these are shorter than the filters we are using today.
Both of these are better than our existing filters, with the Windowed Sinc filter the best.
Here is the SNR for a "matched" 480 coefficient windowed sinc filter. This is 1-3 dB better than our existing filtering.
It also gives a very nice bit shape:
So, not really understanding all this stuff and relying on the experimental method, I tested two more cases. What happens if we first aggressively filter the audio to get rid of everything above 200Hz, then run a matched filter? Well, we get a very interesting bit shape that feels like it has been opened up:
But the bit heights are uneven and the SNR is not as good as the Windowed Sinc. But it is better than our filtering today.
If a 480 coefficient filter is better than 512, then is a longer filter that is a multiple of 480 coefficients even better still? Some quick experiments suggest it is not. We get "ringing" in the bits and the SNR suffers
Enter Comments Here:
| On: 05/16/16 16:16 AC2CZ said: |
| Addendum: Extensive parallel testing against the old and new filters has
shown that the DUV matched filter is NOT better than the stock 512 tap Raised
Cosine Filter. So in the latest release (Version 1.04) I have made the matched
filter available, but the default is still the original filter.
This is a puzzle to me. I don't understand why the Signal to Noise ration can be better but the decode rate is slightly worse. More investigation is needed. |
Copyright 2001-2021 Chris Thompson
Send me an email