Open Research Institute 2021 Space and Satellite Symposium, 28 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Space and Satellite Symposium 2021 Daniel Estevez

Description

Space and Satellite Symposium 2021 Daniel Estevez

A

Hello today, I'd like to present my modem design for the q100 amateur radio geostationary payload. This is still a work in progress, but I wanted to share with you my findings so far for those of you not familiar with q100.

A

Three years ago, sl2 was launched. This is a geostationary tv broadcast satellite which was uh commissioned by the katsoi company, israel sat. It carries the first and only today, amateur radio, geostationary payload. This was due to a collaboration between the qatari amateur radio society and amsa-tl, which is the german amateur satellite association.

A

This payload has been active since february. 2019., the amateur radio transponder uses microwave bands. The uplink is in 2.4 gigahertz and the downlink is in 10.5 gigahertz. It's not so difficult to get working with this transponder because for the downlink we can use q q k. U lmbs for digital tv broadcast, the ku band goes down to 10.7 gigahertz, so these devices also work well at 10.5 gigahertz and for the uplink, probably the most expensive part is the power amplifier, and we can use wi-fi power, amplifiers and also devices from cellular technology.

A

We have this for 2.1 gigahertz, which can work unmodified or with small modifications.

A

This is the footprint of the satellite. As you can see, it covers all of europe and africa, the middle east, india also some parts of china, indonesia and brazil. Unfortunately, it doesn't cover the us or australia or japan, but it covers a third of the world, which is quite good.

A

Q100 actually has two transponders which, as us, bend pipe transponders the first one of them is a narrowband transponder. It's 500, kilohertz wide and due to the bank plans your signals there can be up to 2.7 kilohertz wide and not stronger than a beacon, which is relayed through the transponder. It is not generated on board but generated on ground.

A

The usage is quite similar to an hf band, so you can see the ssb analog voice, cw, most code, communications, narrowband, digital communications as those using hf.

A

We also have a wideband transponder, which is mainly intended for digital tv using dvb s2, but it is also possible to do any sort of vine digital experience. As long as we keep care not to interfere with other users. This transponder is 9 megahertz wide and 1.5.

A

Megahertz is continuously used up by the beacon, which is a dvb-s2 transmission, repeating a video loop and the band plan supports several channels of different widths, so you can see here on the graph if we have a user using one megahertz of of spectrum here, it occupies its channel, but if not, it can be used by three users with 333 kilohertz or many more users with narrower channels.

A

So the idea for the digital modem is as follows.

A

We should comply with the regulations for the narrowband transponder and those make us not be stronger than the beacon, which is approximately 50 db herbs of cn0 and at most 2.7 kilohertz of bandwidth, and now the trick is what is the maximum data rate we can fit in those conditions?

A

If we look at channel capacity for this kind of channel, which is depicted in this plot, we see that this is a severely bandwidth limited channel. Here we can see the bandwidth in a logarithmic scale. The channel capacity also log scale. The 2.7 limit is here so anywhere in this area. We cannot go because of the transponder rules.

A

Channel capacity is the red line so anywhere in this black area. We cannot go because of those physics, so in this white area is where our modem can work. We are going to be on this line, so you can using the maximum bandwidth possible and trying to get as close as possible to this corner, which is 14 kilobits per second, and it has a spectral density of 5.2 bits per hertz, which is a rather uh tricky to get working.

A

uh These lines here are the constant bits per hertz line, so one two three four and five- and we see operating at more than five beats per hertz- is rather tricky.

A

So well, this kind of setting probably doesn't make sense in a professional or commercial endeavor. Someone would say: either you have too much power for that bandwidth or you have to lead the bandwidth. You should try to change things to make communication easier in an mr2 setting. Still they are arguable. For instance, I have talked a lot with phil khan and mario lawrence about this kind of communications, modem and all the time. It seems that these restrictions are a little bit arbitrary and we could do better without them.

A

In fact, uh the conversation always uh ends up with. We should uh try to use spread spectrum, but anyhow, I understand why these regulations are in place and it keeps things working nice and tidy the way they usually work in hf.

A

So I like to see these constraints as an engineering exercise from which original solutions can appear, because if you encounter a problem which is somewhat different to what people have done, maybe to use new tools or the same tools from a different perspective, so the outcome can be interesting.

A

Anyhow, the goal, as I said, is to try to cram in as much data rate as possible within these constraints, and perhaps there is no real practical application for this, because uh if you want a higher data rate than a few kilobits per second, you can just go to a 125 kilo. Symbols per second channel in the wipe and transponder use dvds2 there, and it will work very well with 50 db, hertz cn0.

A

So maybe this idea is not so useful, but I think the problem provides its own set of rabbit holes to dig in and learn a lot and try to advance the state of the art here.

A

Some previous work, uh leading to this modern design, is the following. In december 2019 I was doing some experiments with eight psk to kill about so that is say six kilobit per second here you can see the constellation using coherent communications. The problem is that the uh squaring losses on the costas loop are rather large, and so we often get uh face slips on the custis loop, so I decided to try differential apsk which fixes that problem and it works. Well.

A

Of course you get some losses due to differential encoding, but it works with very few bit errors.

A

Then uh court morale from answer. Tl came with his multimedia high speed, modem design. It can use different modes up to eight psk at 2.4 kilobyte and it uses read solomon behind the scenes it's using liquid sdr. So that's an stl library. This is a complete application. With a graphical user interface, you can send files images, digital voice and it's multi-platform. So I definitely suggest you check it out. It's in the link here.

A

So motivated uh by a card's progress, I decided, starting uh in may this year, not to be conservative and really try as hard as possible to cram in as much ah beats per hertz as possible and to up the the bit rate.

A

The progress of this project has been rather slow because I'm uh doing many more things on the side and I'm favoring more advanced solutions, even if they require more development time in vm. This doesn't uh achieve to um obtain some useful solution, as it said, but to rather serve as investigation learning and to come up with new ideas, the design criteria, 50 db, hertz, 2.7, kilohertz bandwidth.

A

We assume ground stations, use good hardware, so very linear, sdr devices stable frequency references, because frequency stability is rather tricky. The mode and latency shouldn't shouldn't be too large. A few hundred of milliseconds should be good. This is comparable to the geostationary round trip time, so we shouldn't have very long latencies like 10 seconds, which would make it uh difficult to carry out back and forth communication.

A

This is mainly intended for long transmissions with a continuous carrier, so not packetized transmissions and the receiver should be able to synchronize at any moment within a few hundred of milliseconds.

A

So there should be enough synchronization markers for the receiver, I'm drawing lots of ideas from dvds too, because uh the channel is the same in dvds too, and it's really well thought out, but some of the ideas in dvb s2 are not really applicable due to our much lower symbol rate or bandwidth.

A

So there is where we need to use some novel ideas and ingenuity. The main challenge is frequency stability, mostly on the 10.5 gigahertz reception, so the modern waveform is going to be a single carrier. Aps-K waveform, just using dvds2, we use rrc filtering with only five percent excess bandwidth. This is a minimum supported by dbvs to x and that's important to up the baud rate within our bandwidth constraint.

A

There are long filters involved in these designs, so they need to be designed carefully. We will be using a symbol rate of 2570 volt so that with a five percent access bandwidth, it just fits inside 2.7 kilohertz.

A

What about the data constellation? I have already mentioned this is going to be 32 aps-k and the motivation is the following.

A

So with our constraints we have 15.9 es and 0, and we can go to this table on the dvd s2 documentation where all the modulations and codings appear together with their ideal esn, 0 and things start very low, but towards the end of the table, we have things which approach our 15.9 target, and in here we have 15.7, which corresponds to 32 apsk aps-k-89.

A

So this is probably the best candidate is, and it is what I'm using in most of the experiments I'm doing.

A

This is what the 32 aps-k constellation looks like, and there are two radiuses which are used to define things. They depend on the coding rate and I actually don't know how these radiuses have been optimized. Probably there is some simulation with the feck involved.

A

Another interesting idea I haven't tried so far is 64 aps-k. This is defined in the dvd s2x standard, it's probably quite risky due to the high phase noise, but anyhow we have this table. um For instance, we have 15.87 dbs here, so we have 16 aps k, 4 5. That would be a good idea for a modem.

A

This is more complex than 32 aps-k. There are in fact three different constellations organized in these three ways, and each of them is used uh for different modulation and coding.

A

So let's get on with a synchronization. Synchronization is the most tricky part because carrier phase recovery is much more difficult than for your usual dvd s2 at high symbol rates. Here the challenge is the low bandwidth, so you can look at it from a number of different perspectives, but channel coherence time is on the order of 100 milliseconds.

A

This depends a lot of on your uh frequency reference for your ground station, but we are assuming here that the user will have some sort of gps do either tcxo or ocxo, based so with a pll of 10 to 25 hertz. We can track this uh channel, it's no problem and there is more much more than enough snr for face tracking. So, for example, if we only spend 32 gb, hertz cn0 for phase recovery, we have more than 20 db of loop bandwidth, which is great. It will give you a very low face noise.

A

The problem is that symbols are very long. The channel coherence is only 250 symbols, so any of the phase, synchronization tools or techniques of dbvs 2 do not work in this setting. The problem is example the uh plc headers. By the time you receive the next plc header, many more than 250 symbols have passed and you have missed your channel and the same happens for the pilot symbols, which are an option in dvds2. They are just not as frequent as needed, so the possible approaches here are: we could use a residual care carrier.

A

This is a constant cw carrier which is either on top of our signal or next to a signal. It is a simple solution, but it's somehow problematic in that. If the carrier is on top of the signal or next to it, we will get interference from the data modulation and if it's a little bit away, then we increase the bandwidth which is required for the modem.

A

The second solution is to include pilot symbols in tdm, so that's make every uh one out of in symbols, make it be a pilot symbol, and that is the solution we take here so out of every 50 symbols.

A

The first of them is a pilot symbol, and this gives us around 50 pilot symbols per second, which is enough to estimate our channel and keep updating the estimate as the channel changes.

A

These pilot symbols are modulated in dpsk with a 31 symbol, m sequence. uh This is great for synchronization, because the sequence repeats every 600 milliseconds, so the synchronization time is still below one. Second, the receiver can detect this pilot sequence using circular correlation, so it can record a 600, millisecond buffer of samples and then circular correlate and find the current phase of this pilot symbol sequence.

A

It is also useful for initial carrier frequency offset acquisition. We can get sub hertz resolution with this correlation, but note uh that to achieve this, the initial carrier frequency offset needs to be less than 25 hertz, just because we only have 50 uh symbols per second, so we would get aliasing. Otherwise, this initial frequency offset is easy to tune either by hand or with an open loop estimate.

A

I have made a guinea radio implementation of this modem using custom c plus plus blocks, and this has been tested both with simulation and over the air are tests through the q100 transponder. So here you can see the main parts of the receiver.

A

First, there is an agc, then we do symbol synchronization, so uh everything else works after symbol, synchronization at one sample per symbol, and we have this uh pilot acquisition of the pseudo-random sequence, and then uh this uh gives initial estimates to the block downstream, which is the pll which works only with pilot symbols and divides the data and pilot symbols into two streams to be handled separately.

A

This is a little uh gui from the general radio flow graph. Here we can see the constellation in one of the tests in red. We have the bpsk pilots here and there and in blue we have the apsk constellation and we can make out the individual symbols, even though there's a little bit of confusion uh due to the low snr.

A

This is another picture of the over-the-air tests, so some over-the-air tests uh have been done basically to validate uh synchronization to see that it really works in practice with a real ground station. This is a picture of lean rot. I like to use lean route for spectrum visualization, and here we can see the whole uh 500 kilohertz of transponder bandwidth in the middle. We have this bpsk beacon, which marks our power reference.

A

These are two cw beacons on the sides which mark the edges of the transponder, and here is our signal. As you can see in the zoom spectrum, it has very steep uh skirts and it occupies exactly 2.7 kilohertz.

A

The results of these tests uh and the iq recordings are available online. If you are interested in those, the uncoded beta rate was about five percent, and here you can see another a nice plot of the constellation done with python, where you can see that.

A

Yes, there is some mix-up between symbols, but uh some photo correction will be able to fix those.

A

So coming on to the fork error correction design, we will be using ldpc codes here again following the dvds2 standard, our synchronization sequence, which uh lasts 600 milliseconds, gives us a natural frame size of seven thousand five hundred and ninety five bits.

A

That is uh the data bits which are transmitted along the repetition of this 31 symbol, bpsk sequence, and here the challenge is that the frame size is not so large, so ldbc codewords using dvds2 are much longer. The normal ones are 64.8 kilobits and the short ones are 16.2 kilobits.

A

So that's uh more than double or frame size and ldpcs work, much better with longer frame sizes. So here we is where we get some uh losses in comparison to dvb s2.

A

As we advance, we are trying to design a rate eight over nine code, uh which uh feeds our uh ebn0 target. That's 9.42, dbs using 32 aps k and the design of this uh ldpc code is still a work in progress, so nothing said on stone.

A

So far when I started working in this, I found that there are many references that explain how to implement ldpc decoders. However, there are not so many references which explain how to design your own ldpc code since in most applications you are just given the ldpc code. It comes determined from your protocol or your application, but here we are free to design our code and we would like to design a code which adapts to our frame size and to our target ebn0.

A

I have been mainly using sarah johnson's book iterative error correction and the references which appear in there to some papers to understand the different techniques to build ldpc codes, I'm using aff 3ct for simulation.

A

This is both a library and a command line tool which implements several error correction schemes and you can run benchmarks, and it's quite fast. In fact, some lessons learned are that pseudorandom constructions work rather well for moderate and long code sizes and, in fact, for 7.6 kilobits frame size. They work really well, but the code structure is very important, so things such as the column weight of your parity check matrix will set the difference from one kind of construction and another one.

A

We do not care too much about the computational code here, because the bit rate is low and we assume that the user will use a pc uh to decode these, so it will be more than capable. So, for example, the dvd s2 ldpcs are irregular, repeat, accumulate and they have a very efficient way to be encoded.

A

Here we lose this property with pseudo-random codes, but we do not care so much.

A

I have developed a small tool in rust, called ldbc toolbox to help me with this design, and this implements uh some matrix computations, some pseudorandom constructions of ldpc codes and the constructions of all the parity check matrices of the dvds2 codes. These can be used both as a command line tool and as a library, and you can check out the tool here.

A

These are some of the results and let me unpack for you this comparison, so here in red and blue, we have uh two different pseudo-random constructions for our code: size of 7.6 kilobits. These are the machining construction in red and the progressive edge growth algorithm in blue next up. We are comparing, with the code size in the short dvd s2 effect frames.

A

So in green we have the dvds two short frames and in yellow we have the machinial construction for the same code size. So you can. You can see that this pseudo-random construction is even slightly better than the dvd s2 code, but we are losing some performance uh due to the difference in code size and here in light blue. We have the long effect frames of dbvs ii.

A

They give extremely good performance and in fact the simulation only goes to 9.1 dbs of ebn0, because further than that, the frame error rate was too low and the simulation would have take many many hours to complete.

A

So we could say here that we are done in fact, uh 9.4 dbs of vbn0, which is our target, is uh around here, and if we look at the frame error rate, we have less than uh not point one percent of frame. uh Sorry a little bit more than not point one uh percent of frame error rate, which I think is slightly too high, but anyway the 50 dbs of cn0 was just a target.

A

No one would really care. If we run our modem say 0.5 db is stronger. In fact, the beacon is usually a few db stronger than 50 db's. But of course this is not really the end of the story. The question is: can we do any better than this and at first I wasn't sure because uh well the frame size is what is unless we want to have uh more than one second latency.

A

So in there we cannot improve uh comparatively with dvds2. We are doing quite well, but then I found that there are much better codes. So david mckay made an encyclopedia of assorted ldpc codes. He has many different types of codes, both are very short and very long. It's available on his web page and we find the very interesting codes which I have plotted here with the other ones.

A

So here in purple we see this one which doesn't seem to perform so well until you realize that the frame size is only 3584 bits, so that's less than half the frame size we are using for our modem. Yet the performance is comparable. In fact, if we look just at the frame error rate, it's more or less the same, so that's ash turned in that uh with a much shorter outsides.

A

It manages uh more than the same performance and then there is, uh it is shown here in pink. So maybe you can see it here and here that's a code which has 16 383 bits, so that's more or less the same as these codes, but their performance is much much better. So I'm amazed by these results. I didn't expect these codes to work so well and now.

A

My question is: what's the secret source here and I yet don't know, I haven't really looked much into the techniques uh mckay used to design these, but I think this is the way to go. So if there's a way to design a custom ldpc code, that would give us uh maybe half a db advantage over these machining and progressive edge growth constructions, we should really dig into that hole and see how that can be achieved, and with this I come to the end of the talk. So thank you very much for listening.

A

I have these two references here. They are uh posts in my blog and you have all the links to the software they're gonna, radio, modem, it's on github and also the results and iq recordings. Thank you very much for listening.