 Our next speaker needs little introduction. Daniel will talk to us about GR satellites. Well, thank you very much. I'm glad to be here for the first time actually. So what is GR satellites? GR satellites is a new radio out of three module and has a collection of telemetry decoders for many different amateur satellites. By amateur satellite, I understand any satellite which transmits data, digital data on amateur radar spectrum. So these are satellites built by research institutions, educational projects and universities, also amateur individuals or small groups, things like that. If we see these as a small black box, the input to the decoder is usually IQR samples, either taken in real time from SDR hardware or a conventional radio like a Kenwood or Icon amateur radio, or maybe an IQ recording done with that hardware before. The output you get from the decoder is either packets printed out in hexadecimal format, or you can save the packets to a file on your computer, or pass telemetry values. So those are things like voltages of batteries and buses, and current intensities, temperatures and maybe even payload data. So some satellites have experiments, I don't know, maybe a high energy particle detector, for example. The main project goal is to provide an open source solution to decode any amateur satellite. So there's some philosophy to that, that any amateur radio signal needs to have clear public specifications for anyone to be able to build their own decoder, but that would be a matter for a different talk. This all started for fun and learning in 2015. Some small projects I did with a few satellites, no one besides the audience had decoded before. It sort of grew up and turned into a collection, which is mainly a one-month project, but I'm always eager to collaborate with other people. So versioning, before summer this year, this was only working for radio 3.7, and it had just a master branch releasing versions 1.1, 1.2, etc. And since October, I switched to GNU Radio 3.8, and most of the packet decoding is done in Python, so that was a large but good change from Python 2 to Python 3. And now I have the main 3.8 branch, and I'm releasing versions 2.1, 2.2, it's 2.2 now on the branch. And I've kind of dropped development on the GNU Radio 3.7 version. So that is stuck in the past with the satellites that were supported before October. If anyone really wants a satellite which has appeared only for 3.8, I might go and back port it to 3.7. But this talk is about a large refactor I'm kind of doing right now to all the code base of GR satellites. This is in the next branch, and when it's ready, it will be released as version 3.0.0. So let's talk about how GR satellite looks like inside to motivate the need for this refactor. So each different satellite has its own flow graph. We're talking more than 80 different satellites, so that's a huge amount of flow graphs. Basic information is written in the readme about each of the satellites or flow graphs, such as the kind of protocols, photo-recorrections, CSC codes it uses. So the readme file is quite useful, but very, very long. And the flow graph contains all the things you need to turn IQ data into useful data. So you have blocks to demodulate the data to run photo-recorrections, to pass the telemetry into useful values, also image decoder for satellites which transmit JPEG data into small chunks. There's Nogui. The flow graphs have some configuration parameters. So the idea is you should run this as a dot pi script generated from GRC, from the terminal. So you can just say dash dash, whatever parameter. And the input they get is standardized to get in UDP input. So samples streamed in in real time using the UDP protocol. And this is a real not IQ. This was chosen because it's the protocol used by GQRX to stream data out. So you can interface your satellites easily with GQRX. Also, if you have a wolf recording taken from a convention of radio or something like that, or just from Satnocks, it's not so much different from this. So interfacing to very different formats is always difficult. You need to handle different sample rates and so on. And from the point of view of output, you get everything printed out to the terminal or passed on to other applications via sockets of files. So an example flow graph we can see here. Here I have my pointer. We have the UDP input. And then some of you may recognize here an AFSK demodulator, so audio frequency GMSK actually. This is running with GOMSPACE-U482C radio. So here we would perform the packet boundary detection to turn different packets into PDUs. Then fact decoding. And here we end up with the useful packets transmitted by the satellite. So then it depends on your intended application for that. We can submit the packets to Satnocks database with this telemetry forward block. And we also have a telemetry parser to print out human readable values. But you could do something like store into a file or whatever. So problems with this kind of approach. There's lots of repetition as you can imagine, there's an FSK demodulator in many of the different flow graphs. So this is really difficult to maintain. If I want to change a single parameter for FSK demodulation or the kind of algorithm I use, I would have to go into maybe 50 different flow graphs updating the very same thing in all of them. So that was natural and fine when there were very few flow graphs on satellites but it has grown a lot so this doesn't make sense any longer. At the same time it's very flexible and not very flexible. So the user can go and change anything he wants. Let's say as an example before you want to write the packets into a file or process them with your custom, whatever, send them out to an application using ZMQ. You can do that but doing that is cumbersome and if you want to do that for all the flow graphs it's more or less impossible. And also for adding support to new satellites which is something I do quite often as they keep launching more and more stuff it's also cumbersome. So you copy us a flow graph for a sort of similar satellite and then modify the things you use and then modify the things you need to change. So the main idea for the refactor would be to eliminate all these redundancy. And the motivation is well let's see if we can come up with a way to describe what the things the satellite is transmitting like have a simple text file with these satellites doing this protocol with this error correction and this sort of things and then we should have code to read that text description and automatically figure out how to put together the decoder flow graph. And I identify three different use cases for this kind of refactor decoder. One is a standalone decoder like a command line tool where you say this is an IQ recording for this satellite just decode the data for me and maybe print it on the screen or put it to a file or whatever and so the command line tool should have enough command line options to be flexible. It should support different kind of inputs and outputs. Also an important use case is building blocks for all the custom new radio decoders maybe people building their own station solution for the satellite that's something that ESA did recently for the Opsat satellite. So I recognize that there are users who want to go more advanced customization than just using the command line tool with everything built in. And also some other cool thing which I haven't gone at yet is a plugin. So this is reused parts of GR satellite but not as a user to build something else but from the point of view of an application. So I'm especially interested in hooking this to SADNOX network from the server side decoding point of view so ground stations everywhere in the world submit the data to SADNOX and currently the decoding is done by the distributed ground stations. So this has the problem that whenever a new satellite is launched if it uses really different protocols they need to push the updated software to all the ground stations and this is a coast pool and it takes time. So SADNOX people are also interested in hey can we do server side decoding so I think your satellite would integrate really well with that but also a plugin for GQRX or any other SDR GUI app would be really great to have like a pop-up menu this thing now I'm tuned to is this satellite do something with the data. So key elements, there are two key elements for the refactor. One is what I call SATYAML files describing the satellite, basic information on the satellite name, NORADID and the protocols and transmitters. Why YAML? It's just because since radio 3.8 is doing YAML for GRC, flow graphs and blocks I figured out it wouldn't be such a bad choice to keep doing YAML also for satellites. So this is one part, the other one is components the idea of components is to break up the decoding chain into logical higher level functions we'll see that in a moment so the idea is you have your very simple blocks you put them together into higher level components and the way to write a SATYAML file is to specify what components you need to put together to decode the satellite so that's what the standalone decoder do it reads the SATYAML file for satellite and figures out what components it needs to connect together and runs the flow graph but it's also possible for the user to go on, generate your companion to create either high level components or lower level blocks from your satellites to create any kind of custom flow graph So components speaking from the IQ data on to the final packet you can break the chain logically into these four main tasks the first one is the modulators convert the RF samples into symbols then decoders look at the symbol stream detect the boundaries of the packets perform photo correction CRC checking etc so roughly this would correspond to the physical layer of the system when we get to the upper layers if we think of this as a network stack it's kind of messy because you have CCSDS standard protocols but many small satellites do ad hoc protocols so you don't really have a good separation between different network layers so this kind of upper layer thing is handled by what are called transports so whenever you want to convert from your physical frames into something else maybe you want to perform deframmentation or things like that that would be implemented in a transport and finally data sinks are the blocks which do something useful with the data be it to print it on screen with telemetry values to submit it to some online server to storage file JPEG file whatever so if we look at the example before and we identify the functionality all the part in dread would be the demodulator in this case for AFSK then these two blocks would implement a deframer for this particular GOM space radio and then we have a few data sinks which do the useful stuff so if we replace all the low level blocks in the example before with components we end up with something much more simple that's easier to understand for many users and easier to reuse so we have this AFSK demodulator just turn any AFSK signal into soft symbols replace UA2C deframer whenever I have this custom protocol transmitted by this GOM space radio just detect packets run for the correction and speed out the frames as PDUs and then the useful things we want to do with the data so any user who wants to work with this kind of GOM space radio about forwarder or correction or anything like that he just needs to know well it's this radio and it's transmit AFSK so just put together these two blocks and you're done so let's look at Satyamel the example here is actually the Satyamel file for the satellite I'm using as example in this talk is to describe the protocols that the satellite is using in a component centric way and what I found is that many of the protocols are very ad hoc so it doesn't make a lot of sense to try to chase like all these specific parameters of course we could describe this kind of GOM space ad hoc framing by things like it uses read Solomon CCSDS code and this kind of scrambler and the header looks like this with some goli error correction but it tends to become really messy so whenever I see something which looks kind of a talk I just call it by name rather than trying to parameterize it so in here the framing we specify is just u8.u482c and that's the approach so if we look at here we have basic information like the main name of the satellite alternative names and you can call the decoder by using any of these names the NORID ID this is used to transmit the telemetry to the database also you can call up the decoder using NORID ID so this is helpful to automate things then for the data the satellite transmits we say we have telemetry parser for the data and the name of the telemetry parser the Python class is AU03 and here we describe the transmitter with parameters related to AFSK and for the framing we just say it's the custom gomspace radio thing so this is the list of modulations I'm framing supported, modulations is something very basic, FSK, BPSK and variations of that but in the framings some really standard things like AX.25 and some CCSDS protocols but also some specific names of the satellites because they're using ad hoc protocols you can also use Satyameli in GUNER Radio Companion so the way to do that is you have the satellite decoder block and the satellite decoder block does the work that the command line tool does so it gets IQ samples on one end and on the other end it spits out frames so you're free to do whatever you want with the frames but you don't need to know anything about the satellite you just write the name or put here the path of our Satyameli file and this block figures out how to put together the decoder the standalone command line decoder looks like this so you need to run it like GR satellites and then the name of the satellite because the amount and type of command line parameters you get depends on what sort of functionality is needed to decode the satellite so for example for this particular satellite we have forwarder correction decoding so there's a verbose forwarder correction option but there's no CRC so there's no verbose CRC option so the way this works is when you run GR satellites AU-03 it looks at the Satyameli file it figures out what kind of component blocks it needs to put together to decode this particular satellite and then it asks every of those component blocks what kind of command line options would you like to put into the whole command line set. Telemetry passes this is something which was more or less present in previous versions in the same manner but I'm relying onto it so much for this refactor which is done using a python library construct which allows you to define how your data structures look like, like the first field is 8 bits wide and it's called whatever voltage and from this definition you get a parser and an encoder for free so we use the parsers not the encoders but if anyone wants to build a satellite transmitter he could use the encoders so new telemetry definitions can be written by writing this constructor class and then this telemetry definition can be specified in Satyameli files and can also be used with the telemetry pass block which just takes your construct structure and parsers according to that and currently there are 20 different telemetry definitions there are many satellites without a parser the format the satellite uses for many of them it's publicly available so just because lack of time I'm not adding more but if you want to help that is something you can help with and something that the refactor also brings is a new file slash image receiver so there are several satellites which transmit file or image data broken up in small chunks and the way each of the satellites does it is quite a bit different some tack the sample some tack the chunks with a chunk number so you get things like chunk 0, chunk 1, chunk 2 some don't and assume that you are not going to miss any chunks and if you miss one chunk you're screwed some don't tack the chunks but rather say this chunk starts at offset 1000 bytes within the file so the idea of these file image receivers to have a general python class that can deal in a generic way with these ways of transmitting data by chunks and to use a specific protocol you should derive from that class and implement these specific things but for most of the protocols it's already inside the general python class so the things you need to specify when deriving the class are very very little and in a few situations it's enough to build a construct tractor where you just say this field of the chunk is the chunk number this is the useful data this is file name for example so currently there's support for all these satellites and road map most of the things that were functional in v2 are now also in the next branch have been releasing alpha versions to engage with the community because I don't want to break not a functionality but workflows for people who are used to modify flow graphs themselves or whatever so just to engage with them see if I break anything of what they were using how well it works for them etc and currently I'm testing the performance of the modulators and when this is done probably I'll release v3 but there are many possible improvements which are made easier by this refactor so this will keep appearing in later versions and final question what about integration with SATNOX Network I don't know if there are any people from SATNOX in the room we have thread open in the forums since 2019 not much progress has been done about integration with GR satellites and SATNOX both on their side or on my side so hopefully with this new architecture it's much easier to put things together on interface so that's all for today thank you we have a question over there and if you're going to leave please start very quietly shuffling out of the room I've got a question regarding testing and refactoring we have like 19 captures of all the satellites how come that you run your programs again or how do you do testing? the question was about testing and not breaking things with the refactor so that was actually one of my major concerns and I don't really have much in terms of unit testing I have small IQ samples for most of the satellites but not expected output because depending on radio version or some variations some of the packets can be barely missed or barely decoded so what I look at is that when I run the recording through the decoder it at least produces some packets and they look sensible for example if you have a CRC and the CRC is ok you can be pretty much reasonable maybe you lost a bit of decoding performance but at least you haven't broken anything serious yeah the question is whether can we support a couple different channels I guess you can yeah also two different modulation schemes so I haven't thought about this yet I guess you can run two copies of the decoder or transmitter but if you want some interaction it's not better ok we got it