 So, to our next talk, imagine a world where information is spread across the whole globe, even to far reaches. And that's for free. There's a company that does this. It's called OuterNet. They do it through satellites. Unfortunately, part of their distribution channel is closed source. So, Daniela Staves, reverse-engineered the system, the signal, the protocol, and the receiver. Please welcome, with the anniversary edition applause, Daniela Staves. Is it working? Yeah. So thank you very much for the introduction. I would also like to thank the organizers, and let's go. The first of all, a brief introduction about myself, because it's the first time I speak into this conference. So I come from mathematics. I'm finishing my PhD. It's pure mathematics. It doesn't have anything to do with OuterNet or radio stuff. But I also have a background in computer science, and since 2.5 years ago, I took amateur radio as a hobby, and that's my Spanish call sign for anyone into amateur radio. And I also have a UK call sign, because I've been living in the UK for a while. So this is related to the talk. In my amateur radio activities, I started to decode some satellites which are orbiting low Earth, and they transmit into amateur frequencies. So what's the deal behind this? In amateur radio, encryption is forbidden. This is just mostly because of security measures, and that's part of the community also, because it's useful for amateur operators to just listen across the band and listening to whoever speaking, having, well, not so private conversations. But it's common to go and listen, listen, listen, and decode whatever you want. So that's kind of the amateur radio philosophy. And there are these small satellites, most of them are launched by universities or educational projects. They transmit some data, telemetry mostly, and the thing is that, well, these specifications for how to decode the telemetry, many times they release incomplete specifications. So you have to do some work in order to get a working decoder. I have been doing these for like two years ago, and that gave me some experience when I started working with Autonet. So enough of the introduction. Let's first go with what is all about Autonet. Essentially, you have a geostationary satellite, so it's fixed in one part of the sky as you look at it from Earth, and that's transmitting files from the Internet. I think Wikipedia files or weather information or miscellaneous information, small files, because the bandwidth is not so much. So then you have this signal and, well, you have this decoder from the Autonet, but these specifications are not open. So we want to construct a fully working decoder, and I'm going to explain how it works in two parts. First we have our RF signal, and we're going to turn that into bits or more precisely frames. And then what do we do with these frames? We want to turn those into files. And after that, some miscellaneous. Okay, so what is Autonet? It's a startup company, and its goal is, well, there are many places in the world where it's not so easy to get Internet access. And even if you could have a downlink-only access to some Internet content, that would be interesting. So picture yourself in the middle of Africa. It's impossible to get a proper Internet connection. The best thing you can achieve is satellite, but that's very expensive. What if you could just put a downlink-only satellite receiver and start getting information from Wikipedia, news, weather content, and so on? So that's the goal of this company, which is called Autonet. And they started broadcasting using digital television satellites, so you could use the same equipment that you would use in Europe, for instance, to receive digital TV from geostationary satellites. Indeed, you had a sector box. And this works because in DVBS or DVBS2, usually you embed digital video, MPG, or whatever, but you can embed all sorts of content, so they embedded files into that. But the problem with this scheme is that these satellites use spot beams, which cover only a region. For instance, you could have Astra satellite, and the beam only covers parts of Europe. You have satellites broadcasting to the Middle East, but you need, let's say, 10 or 20 satellites like these with their beams covering all the world if you want to have worldwide access. So that was very difficult for them to achieve. It's not impossible, and they switched it to L-Band broadcast. The L-Band is around 1.5 GHz, the same as GPS, more or less. And they now broadcast exclusively through L-Band. And they do it through three E-MOSAT satellites. This is a really large satellite company, which also broadcasts differential GPS information, information for air traffic, and so on. So they have these satellites in orbit. And it's just a matter of money to go to E-MOSAT and say, well, I want a really small channel on your satellite to broadcast my data. So that's what they did, and they have three satellites. One covers the Americas, the other one covers Europe and Africa, and the other one covers Asia and the Pacific. So this is worldwide coverage, except near the poles, where, of course, the geostationary satellites, which are on the equator, are almost out of view, but almost worldwide coverage. What do you need to receive out on it? Let's first go with hardware. You need an L-Band antenna. So typically you would use a patch antenna. This is like a square this big. You can also make it slightly smaller, but picture a flat square like this size. And that works fine. But if you have a dish, like a satellite TV dish, it's one meter diameter or 60 centimeters diameter. You can use that that will give you a much, much better signal. There are now people using a dish, and it's absolutely fantastic. You need an LNA that's a preamplifier. So unless your radio receiver is just next to your antenna, you need some sort of amplification into the signal. And usually you do it with a small piece of hardware, which is called LNA, and just fits between the antenna and the receiver. For the receiver, you can use any SDR receiver you want. But the software from AutoNet only supports these really popular RTL SDR dongles. I think many of you in the audience have known about these RTL SDR dongles. They're really popular on chip. And of course, you could run the software in any computer you like, but the software from AutoNet is intended to work on single board armed computers such as the chip, which is $5 or so, I think, or the Raspberry Pi 3. So the idea is that you have a self-contained kit where you have the software running on a dedicated small computer, and then it does all you want. So it gets the files from the satellite, and then it acts as a Wi-Fi hotspot. You can log in to the Wi-Fi hotspot and copy the files to your devices or whatever you want. And AutoNet sells these items as a kit from the web page, or you can go anywhere online and buy them because we're really inexpensive stuff. For the software, there is this RXOS. It's really a Linux image. You put it on your flash card, on your armed computer, and then it does all the decoding. And as I said, you can log in via Wi-Fi hotspot and get your files and whatever. The most of the software in RXOS is open source. The only problem is that the key parts of the receiver, the most important parts that you need to get the files are closed source and distributed only as a binary. Actually there is kind of an issue because this binary links some GPL libraries, the ones that had to do with the RTL-SDR at dongle. So these are GPL only, not LGPL. And well, I'm not a lawyer, but I think it's a possible GPL violation to link GPL libraries from closed source code. I told AutoNet about this, they don't seem to care. So anyway. And most important, the protocols, the modulation, and the format of the signal, so how everything works, it's secret, it's hidden behind this closed source receiver. So why did I decide to reverse engineer an AutoNet? Well first of all, that idea of spreading into the content just via broadcast from satellites is really nice, but I don't think that using a secret protocol and closed source software is a good idea for that. You should really use open standards or open information, whatever you want to call it. Also some amateur radio operators had started playing with AutoNet. It's really fun because, well, most real 1.2 GHz, it's 1.2, the nearest amateur band. So most 1.2 GHz equipment for amateur radio, it's expensive, it gets some money to get into that. But this is some very cheap way to start playing with microwaves, so amateur radio operators started with that. And as I said before, well, closed source and secret protocols are also very bad for amateur radio. So what did they have before starting? The receiver is like a black box where you have the binary running and the RF goes in and then magically you have files coming out of the other end. And you know this is figures from AutoNet that the bit rate of the signal is 2 Kbps, so that's not so much, but if you have running for the whole day and you're expected to leave it running like for many days, you get 20 megabytes of content per day. I also had access to this closed source software. It's free to download, but it's closed source. And I mostly looked at the AMD64 bit version of the software. It's an older version because now they've dropped support for Intel machines and now everything is only for ARM. So the closed source receiver has two parts, one is called SDR100, that's the SDR receiver which talks to the RTL-SDR dongle and gets the bits from the RF. And then those bits get sent into something called ONDD, that's a demo which is running and that's all the work of reconstructing the files and so on. And I also had access to some IQ recordings by my fellow amateur operator, Scotchaman, Kilo4KiloDeltaRomeo. So in fact, I don't have myself a receiver for AutoNet, I could set up one very easily but in these days it's much, much easier to go to some amateur operator who already has this equipment and tell it, well, can you give me an IQ recording I want to play with it and in a couple of days I had my IQ recordings and I could start working. So let's see how we get from RF to bits. When I look at the RF signal I do it with my favorite SDR receiver, this is Lindrad, it's not very popular but most of you have heard of SDRsharp or whatever. So this is the waterfall on the left hand side, I don't know if I have, yes, the mouse cursor. This is the AutoNet signal, these are stronger signals which are, I'm not sure, either DGPS or air traffic somewhat and here you can see some packet data. So this is the first you see, just the waterfall. And in the waterfall the only thing we can see, apart from signal strength, which is okay in this recording, is that it's 4.8 kHz wide and there's no feature, there's no pattern in the waterfall. So it just looks like a hump in the noise floor. It's something which is 4.8 kHz wide and just above the noise floor. So I like this quote from Phil Khan very much. It says that if you use a good enough modulation or protocol then there are really no features in the spectrum or in the waterfall. So what do we do? Well, we have some experience and satellite communications most of the time. They use PSK modulation, a single channel, no OFDM, that's for terrestrial. But we don't know if it's BPSK, QPSK, it could also be QAM. But we suspect that either BPSK or QPSK are the most likely candidates. So we use GNU radio for the signal processing, anyone here familiar with GNU radio? Well that's good, yeah. So if you're into DSP or signal processing it's really easy to get started with GNU radio. If not, you need to learn a bit but you can start playing without knowing too much of the signal processing. There are lots of examples and things you can do and things you can run, sorry. So here I open my recording with GNU radio. The first step is just to filter out the signal. So the filter signal is in red and not so much to talk about this. I also shift it to baseband, so I center my signal about a frequency of 0 Hz. Here you can see it, 0 kHz. So that's the usual procedure in signal processing. You center your signal and you filter. Now we want to find the PSK order. So there's some standard way to do this, you take your signal, this is my filter signal. It comes in here and I multiply it by itself. So that's like raising the signal to the power 2. And what happens when I look at the spectrum, I get a DC spike. So there's a strong frequency component next to 0. And this means that the signal is BPSK. If the signal would be QPSK, I wouldn't get a DC spike for the power 2. I would have to go to compute in the fourth power, so that's multiplying the signal with itself four times in order to get a DC spike in the middle. And you can sort of go and do it for higher order, PSK for instance, 8 PSK, it's also popular. So there's a fairly simple mathematical reason why this works, but I don't want to go too much into it. If anyone's interested, please ask me later. We also want to know the board rate, so how many symbols per second. There's also standard way to do this analysis. It's called cyclostationary analysis. And this involves the following computation, which is much better described in this GNU radio flow graph. You take your signal and you multiply it with the conjugate of the delayed signal. It's not critical how many samples you're delaying your signal. One sample works okay. In this case, perhaps 10 samples would work as well or even better, but you must delay it a little bit. And then you look at the frequency components. So you get a DC frequency component, but that's not what we're interested into. We're interested into the next strong frequency component, and that happens at 4.2 kHz. So that tells me that's the symbol rate. The symbol rate is 4.2 kB. All right. Now that I know that I have a BPSK signal and it's 4.2 kB, I can do the BPSK demodulation. This is fairly standard. There's a really nice GNU radio tutorial about how to do this. If anyone's starting with GNU radio after doing two or three very basic things, I recommend you should go and do this tutorial. So again, really standard for BPSK demodulation. You have an AGC, just to maintain a constant signal level, which makes signal processing work best. Then you have a clock recovery with the polyphase clock recovery algorithm. And this is where our 4.2 kB enters the picture. Here, samples per symbol works out to... Well, I have so many samples per second in my recording. I don't recall how many. I have 4.2 kB samples per... Kilo symbols per second in my signal. So that's the quotient. And then this recovers the clock and gets the symbols. And then a costas loop for frame frequency tuning. So the frequency is slightly out and it's always going to be. This constellation diagram wouldn't be still. It would rotate like this and you don't want that. So costas loop takes care of that. And this is the constellation diagram. For anyone which is not used to these diagrams, each dot is one of the symbols we're receiving. And they cluster around this point, which is, let's say, the bit one. And the point on the left, which is the bit zero. So if you have two clouds, which are really well separated, then your signal is very good. You draw a line in here, in the middle. And everything which is on the left is read as a zero. Everything on the right is a one. So the problem is when these two clouds start to merge and you have some bit errors. OK, so in this case, it's more or less good. We can proceed doing things. What happens with the coding? Well, I have 4.2 kilobots, but the bit rate is only about half. It's only two kilobits per second. That's a number taken from Autonet's web page. So we suspect that FEC is in use, an R equal one, half a code. What does that mean? That means that half of the bits are spent for error decoding. If you get some bit errors, there's no problem you're spending half of your bit stream in using a code which is able to resolve those bit errors. So once again, we have no idea about which forward error correction code is in use. We try first whatever is most popular, and this is really, really popular. It's used anywhere, the CCSDS convolutional code. It's a convolutional code and anywhere. Amateur satellites, long range space probes, Autonet as well. But there are some parameters. So this code has some variations. To find the proper parameters, there's a very nice tool from Balenciva. It's called Autofec. You just plug this block into your Gino radio flow graph, and it tries to use different parameters for the Viterbi decoder for FAC. And it tries on different parameters until it finds the combination, which makes the bit error rate go very, very low. So when the bit error rate goes low, then you know you have the correct parameters. So using that, I found that the CCSDS code used is a standard one, albeit with the two polynomials swapped. That's a technical detail. There are two polynomials which are used to obtain the code. So those are called usually Poly A and Poly B. First you go with Poly A, then you go with Poly B, Autonet does the opposite thing. You first use Poly B, and then you use Poly A. So you have to know that, otherwise you are not going to get anything from the stream. OK, so knowing that, we can use the stock Gino radio Viterbi decoder, and it goes like this. First, we have to swap every pair of symbols because of the Poly A and Poly B thing, which are swapped. Then this is the stock Gino radio decoder, which spits bytes. Each of them has eight valid bits or symbols. So this just takes each byte and outputs eight different bits, because we want to look at the bit stream to see if there's an important. And I have two Viterbi decoders running in parallel. One is running on the stream, and the other one is running on the delayed stream. Why? Because when you do Viterbi decoding, the symbols are going to be in pairs, so you want to process them in pairs. And you're looking at a symbol, and you don't know whether its pair is a symbol coming just before it or just after it. So you just try something in one branch of processing, and you try the other thing in the other branch of processing. And one of them is going to succeed, and the other one would fail completely, but you don't care. You know at some point in the chain. So I have two decoders output in the bit stream, and while it just looks garbage, it's completely random. So that means we needed a scrambler. That was expected, because if not, patterns from the data can be seen in the waterfall, and we had no patterns. So there's some scrambling, which takes our data, which is full of patterns, into something which looks random, and that's much better for radio transmission. But we have to reverse the process. OK, so now what do you do? Again, you try the most popular scramblers, you know. But in this case, none of which I know did work. What can I do? Let's recall I have the working binary for the receiver, so I can look at the assembler code. And this is the AMD64 bit. I don't know if it can be read fairly well. So this is the assembler code for the scrambler in the close source receiver. Well, you just take your assembler code, and you start in writing a C code translation. And of course, you simplify your C code, and it lets human readable. And then there's a really nice scrambler function. Anyone who's into these scramblers could go and understand what's going on. So this is nothing I had seen before, but actually it turns out it's really popular in the geostationary satellite industry. It's called IESS308. It's from standard from Intel sat. And actually, the standard, it's not open. They only give it to our partners or business partners or whatever. This is from a datasheet of whatever component. I find these randomly on the internet. But very nice description. So if anyone's into these scramblers, this piece in the middle with the shift register just looks like a multiplicative scrambler, and that's what it is. But the new thing in this scrambler is this counter. So this is just like a multiplicative scrambler, but with a counter. And once we have the code and how it works, we go implement it into a GNU radio block, plug it into the processing chain in there, and now we look at the data. And you can start seeing some patterns. So this must be read from left to right and from top to bottom. So you have some pieces of bits which are constant. You can see it there, right? So this looks fairly good. OK, and the next step is framing. We have to know where frames start and where they end and so on. So once again, you could look at the bit stream and start looking to see if you figure out any patterns which might indicate start of frame or something else. But that's, in this case, it's much easier. So I was looking at the SDR 100 binary. I can read the names of the functions in the assembler code. And several of those have the name HDLC in them. So HDLC is a framing protocol. It's used in amateur radio, packets radio, and many, many other things. So, well, we suspect HDLC framing. And there are tools in GNU radio to deframe HDLC. There's a stock deframer, but I prefer to use my own GR keys packet to deframe HDLC. So this is what we do. This is the output of the scrambler. We feed it into the HDLC deframer. And the nice thing about my own deframer is that you have this check FCS parameter. So HDLC uses CRC, 16-bit, to check the integrity of the frames. Many times when you're doing these sort of things, you want to skip the check and get frames even if they have some bit errors. So if you put it to false, it's handy. It's bit frames, whatever the CRC check might be. And a slight thing in here, sorry. When you're receiving BPSK, there's a phase ambiguity of 180 degrees. You don't know if you're looking at a 1 or a 0. So either you're looking at the good bit stream or the inverted bit stream. So you have to take, and again, you assume it's the good bit stream on one branch of the chain. You assume it's the inverted bit stream. So you inverted once more in the other branch. And only one branch is going to succeed at one time, but you don't care. So any one of these two will output frames at the end. And of course, recall that we had two Vterby decoder branches, so each of those has two deframers. So we are running 40 framers in parallel. And with this, I start to get frames. So now, what do we do with the frames? Well, the techniques, just to look at the hex dumps for the frames very carefully. And something much clever you can do. You have the OMDD binary. It gets frames from SDR 100 with a Unix socket. So you can feed frames into the Unix socket and see what happens. So you can figure stuff out that way. And well, the protocols that are used in AutoNet, they are custom or they look that I haven't seen anything like those. So I have named them as I liked. And this is a typical frame. Can anyone see any structure in here, please? No? OK, this FFFF thing at the very beginning is really caught my attention. This looks like a broadcast Ethernet address. This is a broadcast Ethernet address. It makes very much sense. This is a broadcast network. So in fact, this is an Ethernet frame. You have the broadcast destination, the source mic of whatever PC is running on AutoNet's ground station. And the Ethertype is custom. All the frames or the largest frames, which are most of the frames, are 276 bytes. And I think that's chosen because it takes approximately one second to transmit such a frame over the air with the modulation in use by AutoNet. So that's really handy. If you're setting up your antenna within one second, you know if you're getting frames or not. So let's look first at the level three protocol. It's called the AutoNet protocol, or OP. And since this is a broadcast network, its only role is to handle fragmentation. So in fact, it's a very convoluted way of handling fragmentation. But you have one byte, which indicates whether this is the last fragment or not. And in case you have a fragmented packet, you have one byte which indicates the number of fragments in the packet or the number of the last fragment. And you also have a byte which goes counting up from zero to the total number of fragments in your packet. So this only handles fragmentation. You have also a packet size in there, 16 bits. The liar for protocol, it's called LDP. And it's really similar to UDP. So you have some concept of ports that are used to identify different services within the network. I'm not sure. And it's really hard to tell with the data we have. If there is a concept of source port and destination port, I really don't care. So I have two ports. And the pair of two ports identifies the service. And I call those the A field and the B field. And you have packet size and a checksum. So very much like UDP. Apart from transferring files, something out on a DAS is to broadcast time packets. And these are used to set the receiver clock because it's intended to run without internet access. So you cannot use NTP. And these are very easy. They have here the ASCII code for, in this case, ODC2. That means alternate data casting too. It's the identification for the ground station in the America satellite. This comes from Scott's recording in the East Coast. You have something which I don't know what it is. But you have the Unix timestamp. So anytime the receiver gets a packet such as this, it reads the Unix timestamp and updates its clock. And there is some padding in the end because packets have to be at least 46 bytes. This is some limitation of the Ethernet physical protocol. Let's go to how files are broadcasted. So one file is broadcast at its time. This need not be so. The protocol allows for simultaneous broadcast. Every file gets split into 242 byte blocks. So you have many, many blocks. There's LDPC codes used to recover the file even if you fail to receive some of the blocks. So if you have holes, you can fill them using the LDPC code. And there are three types of packets. First comes a file announcement, which tells you all the details about the file. Then you have a bunch of file blocks, which are the contents of the file. Lastly, you have the effect blocks, which are the parity check bytes for the LDPC codes. And these are used to fill in blocks in case you missed some of the file blocks. So these file blocks and effect blocks are sent into lift. The file announcement packets contain an XML in ASCII with information about the file. And they are signed with an X509 certificate, Y, probably to prevent spoofing. So the autonet receiver has the certificate for autonet CA, and it checks that the file announcement is properly signed. And if not, I don't know what happens. Probably it discards the file. So the information you want in here. The ID, the size, the name of the file, a hash to check, and some information about the LDPC code in use for the file. And the block size is always 242. So file block packets. Very easy. You have in blue the file ID. In green, the block number, it goes counting from zero to whatever number. And then the block contents, 242 bytes. So that's how packets are transmitted. And once we have all of this information together, we can just go and code a Python implementation that gets the frames and recovers files. So we haven't been able to reverse engineering LDPC codes yet. That means you need to get all the blocks for the file. If you miss a single block, you have a hole in your data, and you cannot get the file. But otherwise, you're fine. So this is the Python implementation. It prints out a lot of debugging information or curiosities. You may want to know the Mac of the Grand Station or whatever. But the nice thing is that here, where is it? There's a new file announcement for amazon.com Wikipedia page. And that's around 1803. And 20 minutes later, that's what it takes to transmit that Wikipedia page. You get all your file blocks, and these manage to recover the file and save it onto your hard drive. So what do we have now? Well, there's lots of documentation, everything I've talked about here, and a little bit more. In my blog, there's the guinea radio receiver. You can output frames in real time with UDP, or you can do a kiss recording. And then you have the Python code, which takes either real time frames from the UDP socket or the kiss file recording and gets the files from those. So what about LDPC decoding? We've done some progress, not so much. There's some track of the progress on GitHub. If anyone's interested, come talk with me. Currently, I don't have much motivation to go into the binary code on reverse engineering, but we might be able to do something. So some miscellaneous fun stuff. Well, it's Adelaide modern. So the X509 certificates, they use a CN. These addresses, odc2.houtanet.is for USA, odc3 is for Europe. So what's in there? You can ping that machine. It pings. You can go by HTTP. Why not? And now the HTTP port, it's blocked. So they've noticed. But before I swear, I got the login page of the satellite modem they use on the ground station to upload the data to the satellite. So huge security flow. Of course, I didn't get past that. It was open surely for weeks, perhaps even for more than a month. Huge security flow. What I'm interested is what's the model of the modem. It's an M7 modem. And now you go Google it. And there's lots of documentation and some pictures for you modem fans. This is the data sheet from the modem. I've marked in yellow what is used in Outanet. Let's see if I can zoom in here, yes. So yeah, probably not a very good idea to do it like this. So this is for the FAC, which they use Biterbi Modulation and so on. As you can see, only the most basic options of the modem are in use. They could have used QAM, and there are very nice LDPC codes, probably much harder to reverse engineer it, and much better performance that they could have used instead of the really simple CCSDS or Biterbi code. What else? Well, you have the IPs for the ground stations. So you can geolocate them, use any online tool, maybe you want to know where the ground stations are. So the Americas is in Toronto. The Europe Africa is in Amsterdam. I don't know if there's anyone from Amsterdam in this room. It would be, yes. Yes, so it would be very, very nice if you can listen on the uplink signal. I don't know the frequency, but maybe you can search or maybe you can manage to do it. So listen on the uplink signal and see if you can just receive the uplink signal. The format is the same. The satellite is like a bent pipe transponder. Whatever goes up goes down. So if you're in Amsterdam or anywhere near all the ground stations, see if you can receive the uplink. And another thing you can do if you can receive the uplink is go and do some radio direction finding. Maybe you can find the ground station. Probably it has very, very large satellite dishes. So actually, Asia Pacific, it's in some small village in New Zealand. What else? Finally, the data throughput. So 20 megabytes of content per day, that's what OuterNet promises. Is this true? Well, let's run the numbers. So we have files which are sent in 242 bytes per block. They feed inside Ethernet frames, which are 272 bytes each. So that's 12% overhead for headers. I've seen Ethernet headers, OP, and LDP headers. Then most of the files use LDPC codes as well. The rate is around 0.83. So this is a 20% overhead on top of the 12% overhead. That works out to a total overhead of 30%. And the bit rate is only 2.1 kilobits per second. And that's at most you would have to factor in the bit stuffing done by HDLC. So when you work out how many information per day you have, it's only 15 megabytes per day. With the convention that one megabyte is 124 kilobytes and so on, if you use the 1,000 convention, you would get, I don't know, 60 megabit. But nothing near the 20 megabit we were promised. So thank you very much. Thank you, Danelle. Do we have questions? For questions, please use the microphones provided over here, here, and here, and here. 1 to 4. And we also have a signal angel. Do we have questions from the internet? Yes, we have. Actually, the scrambler, is it basically encryption, or is it for another RF purpose? You mean like this whole reverse engineering work? So most of the techniques are useful for many other stuff in RF, VRF processing. Most of it, it's standard in amateur satellites, other commercial satellite communication. So I'm not sure if that was the question. The question was, you build a descrambler. So why is the signal scrambled at all? Ah, why is the signal scrambled at all? So it happens like this. If you have data most of the time, the data is going to have some pattern in it. For instance, in here, every time we have the Ethernet header, we have this whole bunch of FFF data, which is the broadcast MAC. So any time you have patterns in your bit stream, if you modulate with any sort of modulation, be it BPSK or anything else, that means some pattern in the frequency domain. So that's not very good from the performance point of view of RF engineering. You get less performance with respect to signal to noise performance, also interference to other channels. So when you want to transmit some digital data on RF, you want that your data looks completely random. And what you do is you use some simpler scramble function, which takes your data and outputs something which is easily recoverable, but looks random enough so that you don't get any patterns in your RF spectrum. Thank you. Question for microphone 1. Hi, I understand the overhead for the forward error correction, but why do they use 14 bytes for the Ethernet header? Any idea? Well, the thing is that if you go back to the documentation about the satellite modem, where is it? Probably here. Yeah, here. So on the top, it supports several different input formats. So you're going to have a PC or PC Lite machine, which is running all the broadcast software in the alternate ground station. And then you plug that into the satellite modem. And of course, they have to talk to each other. So they have to know a common protocol that should be simple enough for them to implement. And Ethernet is OK. It's very easy to wire it up via Ethernet. Why do the Ethernet headers go over the air? So this is intended in the commercial application, as far as I understand, for you to have a real Ethernet network. But over satellite, where you can have many different stations and it acts just like an Ethernet bridge. So that's why. Thank you. Microphone number two, please. Hi. Did you see any packets with the destination, which is not the broadcast destination, like Unicast packets? I think I did. So I can go back to my recordings by Scott. And do you have dumps of these messages somewhere sort? Not in my head, but yes, in my computer. So in my computer, I have all the files I've used. I think I saw something which was not broadcast, or at least, which was not like this scheme where you have your custom method type and you fit your alternate packet inside. So maybe ARP or something else, which was probably not intended to be broadcast over there. So yeah, I saw some of that. I'm not sure from the top of my head what it was. I can look it afterwards. So yes, they happen sometimes, unintended broadcasts. Thanks. And I think we have a question from the internet. Thank you. First, I have a comment. The four bytes in front of the Unix timestamp, is it possible that this might be a 64-bit timestamp? So that was not a question, just a comment from the internet. The question is, there is no user-based uplink. So what is broadcasted? Who is deciding what is broadcasted? OK, so the thing goes more or less like this. I'm not really sure, but at least this is what they say. And in fact, there are some people which are interesting in monitoring what is being broadcasted, because there's not like a public list of what goes out and when it goes out. So the idea is that most of the content regarding bandwidth is Wikipedia files. And this is from the most popular Wikipedia files. So this seems somewhat random, but Wikipedia files. They also broadcast some weather information, which is most usually for sailors sailing on the high seas. Some small files for amateur radio, APRS. Anyone heard of APRS? So some APRS, whatever goes with the Outnet tag in it, it goes sent back. And the users can also propose content to be broadcast. So files at most 10 kilobytes each, and they get screened before and moderated to prevent whatever malicious or whatever. So they moderate, and the process of moderation and so on is not open. So that's a very interesting question. What gets sent and why? Thank you. Another question from the internet? OK. So in this case, thank you, Daniel. Thanks for your time. Thank you for your interesting talk. And I hope we see each other again. Thank you very much indeed. Please, with an applause, Daniel S. Haves.