 So I'll start the whole thing now. Hello and welcome. Today you will hear a little bit about Sat Nox. Basically, it's the ground control station for the satellites that you might see there or any other satellites, probably. So you can look and control your stuff that you just don't build an expensive piece of space trash. You need the station to actually see what it does and give it signals. How that's working out, Nikos will explain. Give us a warm welcome for Nikos with Sack Nox. Hello, everybody. So yeah, we're going to talk about Sat Nox. Before I dive into the project, some introductory speech about what we are and what we do. I guess you already heard some of that stuff if you were in the beginning of the previous talk. So we're in the Libre Space Foundation. It's a foundation, a nonprofit foundation. We founded actually to support Sat Nox, but in the process other projects were developed inside the foundation. And the mission of the foundation is to advance and use open source technologies in space. So trying to push the boundaries of open source to the final frontier, pretty much, the space. And we come from the initial team, at least, of Sat Nox. It comes from the Athens Hacker Space in Greece. It's a Hacker Space, as you might expect, with a lot of tools and a lot of intelligent people coming together with various backgrounds and various skill sets. So we have people that are space enthusiasts, radiometers, but also coders and developers. And as you will see along the talk, Sat Nox is a project that requires many different skills and many different kind of people to work on that. So the fact that we have this one place, one physical place to meet really accelerated the success of the project, which you may have heard of that already. So when we started about three years ago and about six months after we started, we won the Hacker Day Prize. And that was a big moment for us because it boosted the project both in terms of financially because it was a financial prize, but also in terms of community expanding because it made the project very well known to certain communities, especially radiometers or space hackers. So what's the project initial idea is that this is a picture of objects around Earth. There are thousands of satellites, especially in the Leo Earth orbit. And as Piero explained in the previous talk, and I'm sure many of you may also be involved in various university or even Hacker Space projects to build CubeSats and satellites in general. So the teams that build these CubeSats sometimes in the rush of building their satellites, sometimes they don't focus much on the ground station or the Earth side of things. So many of the teams that launch the satellite, they put it in orbit, and that's it. Sometimes they don't even have a ground station to listen to it or talk to it. Sometimes they have their resources and the expertise to build one ground station in the university or in the place they are located. And they just wait for one or two times per day to listen to the satellite when the satellite is above them. And that's a problem that every team like that faces. So this is a diagram of how nanosatellites exploded over the last years. This is a diagram for CubeSats and other kind of nanosatellites, pocket cubes, for instance. So as you can see, the trend is that more and more nanosatellites are put into orbit. And in most of these cases, nobody actually communicates with them. So it's pretty much a problem of scale. And the idea we had back then, three years ago, was what if we could build a network? What if we could build a network of ground stations and try to solve this problem of scale in an open source manner and a crowdsource manner and see how this works and how big this network can be and actually solve the scaling problem? To give you a quick overview, when I'm talking about network, we're thinking about something like this. So on the left side is the users, which can be people who want to communicate with satellites. It can be anyone, pretty much, but also satellite operators themselves. And the network gives them access to a few ground stations or a lot of ground stations around the world and schedule observations for satellites. So instead of everyone building its own ground station in one place, you have a global network of available ground stations. Similar to the CubeSat project, the CubeSat, we also try to find out what's already there. So building a global network of ground stations is not an easy job because many moving parts. So we try to see if there are other people out there building open source ground stations. If there is software open source that we could use other ground stations or the network side of things or the web services side of things. Unfortunately, there weren't many things. So for most of the co-bonates we had on the project, we pretty much built everything from scratch. And we tried to do it in a modular way. So you don't have to use the entire stack of SADNUX if you want to just observe a satellite. You can just build a SADNUX ground station. But if you have a ground station already, you can just plug it in the network and use the rest of the SADNUX project or the other way around. So SADNUX, as I said, is a modular project. So I'll dive more into some parts, some modules, of this project. So it consists of the network side of things, some of the client, which is a software that runs on the ground station itself, the rotator on the ground station, antennas, of course, and DB, which is a web service that I'll talk in detail in a bit. So starting from the ground level, we built a rotator for our ground station. In an open source manner, everything on this rotator is, of course, open source and open hardware. We tried to keep the cost low. So we decided in a way that can have parts that are 3D printed or parts that you can easily find in a cheap way in the store. And you can either build your own ground station or just use any rotator that's supported by Hamlip and Ctld. Also, one of the things that we wanted to achieve in order to keep the cost low, but also make it more accessible, both in terms of cost, but also in a way how to make it easier for you to build a ground station. We also tried to keep the tool chain we use open source. So if you try to build a ground station, you don't have to buy any expensive software or rely on a proprietary solution. So first of all, we're using Ohio. It's a web app built by Lulzboot that's an easy way to showcase construction steps, manufacturing steps of a hardware device. In our case, our rotators. So if you go to our Ohio instance, you can see pictures and videos for easily steps to how to build the ground station. Ohio, of course, is open source itself. We use open source tools to build and design the parts of the rotator. FreeCAD, KeyCAD, QCAD, that's for antennas. And of course, we also like to build our own rotation. So this is the rotator controller. And all of this is, of course, open source and all the schematics and all the designs are unrepositories. So this is a photo of a ground station rotator apart. So you can see this is actually a reference platform, but you can use any different kind of setup. So our reference platform is based on Raspberry Pi 3 and another LSDR. But as I said in the beginning, it's really modular. So if you don't like Raspberry, you can use even a Linux PC or another embedded device. And so the requirement here is that we rely on Python and GNU radio, at least for our client software. And you can see that it can be really packed in a small box that you can find easily. So what we do for the client software, we're using also here open source tools to build Raspberry Pi 3 images. So we use the continuous integration platform of GitLab. And we combine that with PyGen. PyGen is a project to help you kickstart Raspbian images, which is debent for Raspberry. And we also use Ansible to orchestrate all the changes we do on top of default Raspbian image. And in the end, what you get is a Raspberry Pi 3 image with all the SADNOX software ready to be flustered in the Raspberry Pi 3. So we have currently also nightly builds, but also we try to have regular releases in a more stable fashion. So this is some photographs from various cloud stations around the world. So on the left top, for instance, is the one on the top of the rooftop of the Hacker space in Athens. We have Indiana, Australia, California on the left. And in the middle of down is the one in Copenhagen. As you can see, that one is without rotator. It's just a 10-style antenna, which is really good for NOAA weather satellites. So you can see a different kind of ground stations, different setups, and so on. This is a quick view of the map of ground stations around the world. I'll come back to this a bit later, but you can see that they're pretty scattered all over the world. So now let's go back to the cloud side of things. This is the SaddoxDB. So when we started the project, one of the problems we had is that we didn't find any centralized place for information around satellites. So the only way that we could have satellites in order to have observations about them and communicate with them was to just dig around blocks and websites, unfortunately. And we decided to create one website that will, in the same manner, use crowdsourced methodologies to gather all that information in one place, most commonly frequencies about satellites. So right now we have about 220 satellites with information about frequency and transmitters. And that keeps expanding. It's a website that gives the possibility, the ability to satellite operators, but pretty much to anyone to submit suggestions about new satellites or information for existing satellites. And we have a team of moderators that vet this information. Eventually, SaddoxDB also ended up to be a place where we gather telemetry data from the observations, decoded telemetry data. And that includes not only data that come from Saddox, but also from other tools. We have the TLM for water, for instance, and anything that's telemetry data that come from a dear satellite project. And also, DB Saddox has a public API. And I'm sure most of you know Gpredict. So Gpredict uses SaddoxDB API to fetch frequency formation for all the satellites. Yeah, and I think we just passed the 10 million frames barrier for satellites recently. Yeah, as I said, on DB we have decoded telemetry data. That's not an easy thing to do because the decoding information for satellites is not always easy to find. And each satellite may have its own spec on how to deal with things. So here is a short snippet of a decoder for the Unisat. You see the mission patch on the left. But in a similar manner, we have our own decoder for our own CubeSat, Ubisat. So we decode the telemetry data so we know the specific way this satellite sends the data, for instance, temperature, voltage, and stuff like that. So we know how to decode them. And then the next project we're trying to build is actually create some telemetry dashboards for the satellite. So it's easy to see how these values change across time. So let's go to the network. This is actually the observation orchestration tool of Zadnox. This is the place that all ground stations actually connect through a REST API and push back all the observations. But also it's the place where the FETs, all the observations they need to do. So the goal is, well, first of all, let me explain what the observation actually contains. And we'll see in detail in a few slides later that an observation contains a waterfall, demodulated audio, and demodulated data. And we'll see some examples of that later. Here you see a screenshot, for instance, of a ground station and some satellite passes for that specific ground station. So the network gives you the ability to orchestrate and schedule observations that can happen in two ways. The first way is, let's assume you are interested in one specific satellite. You are a satellite operator, or for whatever reason, you just want to focus on one satellite. So you can come to this page, you choose your satellite, you choose a time frame, and a specific transmitter. And you just see what the observation windows available in various ground stations around the world for that specific pass. And you can see, for instance, here in the screenshot that we have two ground stations that are available. And we can schedule that specific observation. The other way is to go, if you don't really are a satellite operator or you're not focused on specific satellites, if you are a ground station operator, for instance, you can go on the ground station page and then see what are the available observation windows, which are the satellites that actually pass above you in certain times in the future. And you can schedule each one of them. You can see some metadata about the observation so you can decide if it's a good pass or not, if it's too low or too high, and so on. And you can schedule all these individual observations. So this is a screenshot from an observation. On the left, you can see the metadata that the network keeps, which is pretty much the same metadata that we saw earlier. On the top left, you can see which is the satellite, which is the observer, which is the ground station, and so on. On the bottom, you can see the TLE, the orbital data that was used for that specific satellite, for a specific pass. And on the top right, you can see the demodulated audio with a spectrogram so you can have a visual representation of the audio. But also, you have the waterfall, which helps you quickly understand if the observation actually returned any data or not. And in some cases, we have demodulated data if we know how to demodulate them for a specific satellite. So here is a weather satellite, NOAA. So we know that we can decode that data back to any image. So one of the challenges we had with a network is that, as you can imagine from the previous slide, that each observation has an audio file. That audio file can be really large because we try to keep it as high quality as possible so we can decode it later. And the problem we had is that we had a scale problem because we needed so much storage in order to keep all the observations. We don't delete any observations. So one thing we recently did is that we actually utilized Ethernet Archive, which you probably already know. Ethernet Archive is one of its mission statements is to actually archive open data on the internet. So we recently switched to Ethernet Archive to keep audio files so in that way, we utilized what Ethernet Archive offers. So on the software, since we are on the software, we come back to the ground station again. So as I said, there is a Raspberry Pi with an image and inside that image runs a various open source project, like Hamlet, for instance. But we also have our own client software written in Python that orchestrates all the necessary work for the ground station. And what the client does, it fetches all the observations for that specific ground station that have already been scheduled on network. It starts all the necessary scripts, new radio scripts, or rotator, rot-cdl scripts to handle the rotator, adjust the frequency for doubler correction, and in the end, it generates the waterfall and the audio or any other data and push back the results to the network, as we saw before. You can use that. The easy way to use that is, as I said, with a Raspberry Pi 3, but it's a standalone project. You can use it in a Linux PC, too. And also, it would try to make it as easy as possible for people to use it, because it's not necessary that an observator or a satellite operator is a Linux expert or so. So we create also a web interface that can be accessed in a local network to access your ground station with a web interface and do some configuration, do some very basic functionality, and we keep expanding it so it can be used for both receiving and transmitting. That's the web interface of the client software. First, as here, you can see that that specific ground station has a few observations already scheduled. And on the bottom, you can see the logs, actually, from what happens on your ground station. So without actually SSH-ing to the machine, you can see what happens. And this is a screen that we saw on the previous talk also. So the client also supports command and control web interface, so you can easily also communicate with the satellite. This is for the UPSet, but in a similar way, this can be configured to be used for other satellites, too. So if you want to contribute, there are many things and there are many different skills required for the project. So depending on your skills, you can contribute either by just building a ground station. That's the very significant contribution and help the network expand. And depending on if you are a developer, you can write code for the software projects. Some of them are written in C, some in Python, most of them Python, and JavaScript, of course, for the web projects. And you can also join our IRC matrix channel. We have an assembly here on the OpenRBDFarstructure cluster. You can find us there as Libre Space Foundation. And if you have any question either here or later, we can discuss and showcase, even on the assembly, how the network works in more detail. Thank you. Thank you very much. So we still have some time for Q&A. If you have questions, there are microphones, one, two, three, and four in the hall. Please line up behind them. I will call you up. And if you leave before Q&A is over, please do this in a quiet manner that we can go on with Q&A. Thank you. Starting with Mike One. Hi. Just a simple question. Are there any legal implications? I mean, you could listen to satellites that you don't own. Are there any legal implications for you as a ground operator? Yeah. Well, the quick answer is that we are mostly focused on amateur satellites with frequencies in amateur bands. So you're OK to listen to them. It's allowed to listen to them. Thanks. Mike, one, two, please. I have two questions. First one is, what would it cost to build one complete antenna? Well, depending on the setup and the parts you choose, of course, but more or less around $300 if you build the whole rotator and antennas. And if I'm already in the middle of Europe in a very dense area, you've showed us the map of ground stations. Does it make sense to need more antennas in these regions? Or is it covered? Yeah, because we may have multiple satellites over your area. And at the moment, at least the ground stations can only pick one at the time. So the more, the better. OK, thank you. Mike One, please. I have just a simple question. Can you receive or also send data? Both. I mean, the network right now on the network side of things, if you visit the website, you see mostly, of course, observations that we listen to satellites. But if you are a satellite operator, you can contact us and see how we can adjust the command and control we showed so we can talk to your satellite. Thanks. Microphone two, please. So if you build your own station, can you also use it exclusively? Or how is this scheduled with other users who want to use it and you want to use it in your local amateur club? Yeah, so right now the network, you can make an account on the network. But if you want to schedule an observation, you have to be a ground station operator, a ground station owner, yourself. We have that to use it as an incentive for people to build ground stations. So not everyone can schedule observation at this point. But in the web interface of your client up in the top right, you can see that there is a network mode, there is a standalone mode. So if for some reason you want to put your station in a standalone mode and move it out of the network, just to use it on your own, you can do that. But once it's on the network mode, that means that while it's idle, any other of the observators can use it. Microphone one, please. Yeah, actually referring to what the person said before on this microphone, it would be actually cool to get some control data to those stations and to control satellites. A lot of projects actually doing this outside of the amateur radio satellite service. So the Dowling is actually on amateur radio bands, like mostly on URTF and on VEGF, sometimes on 13 centimeters or 23. But actually, what about urging those developers of satellites also to make actually the uplink on amateur radio satellite service allocations and actually to get this to the crowd so everybody can control the satellites together in the crowd and actually that they don't have to invest in some time shifts at big control stations and big ground control stations? Yeah, the idea is, I mean, if you have a global network and I saw already that we have already main stations and keep expanding, so on the receiving kind of side of things, that it's true. I mean, you don't have to buy time shifts in other commercial services. You can utilize the whole network. And in transmitting, you can also do it in a sense. But since you are the one who knows how to communicate with your satellite and what your satellite expects, it's easier to have a ground station with a command control software and actually communicate with the satellite. I'm not sure if I answered completely your question. The internet has a question. Yes. One user wants to know what is the ideal minimum coverage for the ground stations, like one in 60 kilometer radius less or more? Yeah, that's a good question. Yeah, I don't know the exact number, to be honest, about that. Thank you. OK, we don't have any more time. It's very sad. But thanks a lot, Nikos, again. Give him a warm welcome or applause. Great talk. Thank you very much.