 Okay. Our next speaker is Andre, and he's going to talk to us about Java Satellites and Raspberry Parts. Yeah. Hello everyone. My name is Andre. I'm a software developer. I'd like to talk about Ertogloud. This is software which lets you download the data from Satellites. Yet another. I'd like to talk about the design, the features and a bit of future plans and answer questions. So, but before I move on, a brief history. So, several years ago, I decided to contribute to space technology and improve our space tech somehow. But for software developers, it's really hard to do. Really hard to find the niche and all that stuff. So, I found a project called SETNOGs. This project was about building a base station for tracking satellites. I was really excited. I started building it, trying to run this on my MacBook, compiling and I had a lot of issues with that. Because of different Python versions, different C++, there was a lot of issues I had. Actually, I opened the SETNOGs UI, trying to find what the data SETNOGs can provide and how they can contribute to the web server and I didn't find any data there. Only waterfalls and some audio files. So, I was really disappointed at that time. What a software developer would do in such case, I decided to build my own station, of course. My base station should do all these things. So, I should see some pictures from space, this is super cool, it's visible. I would like to see any telemetry. The solar panels, voltage, everything should be stable. I should be able to run my base station on Sonopalus somewhere in the woods and leave it for years, don't bother with it and get the data eventually. My base station should be stable and it should be simple. And it should do one thing, just gather the data from the satellites, but it should do it well. So, I started to play with the design a bit and I came with the following. So, it consists of two steps. The first one is very simple. When the satellite comes over with horizon, my base station should schedule an observation from FTIL-ZR, it should get the data, zip it, save to the disk for further processing. So, nothing fancy here, super simple, just save the data to the disk and execute the next step. So, one satellite is left to the sky, then base station should stop at FTIL-ZR and just execute the next step. And the next step is the following. It reads the data from a disk, simply demodulated, simply decoded and save it onto disk result. And optionally, maybe save it somewhere essentially for aggregation purposes and sharing with the community and the scientists. And this step could be executed concurrently with the first one so that I could optimize the load. Yeah, all I have to do is just simply demodulate and decode the data. Right? So, I have no idea how to do it. Especially three years later, three years ago. But I knew that somebody else can do it better than me. Right? And I started Googling it and Googling it and Googling it. And I found a project called Geosatellites. You might have heard about it, right? So, this project contains a lot of satellites and a lot of decoders from a lot of companies. And it's a really good place to look at. I highly recommend the work Daniel did. And this is a special hard work because the satellite owners, they normally do not share the protocol details, right? And it's really hard to find the way to get the data out of bits. So, this project was completely fit my purpose, right? But what, the next steps for me to do, right? The first step, I can use GNU radio, right? Because the Geosatellites based on GNU radio, I can use GNU radio, I can start building it, working with the Python version, so my back book and feeling pain. And essentially, it would be the same, what SatNox did. And I didn't want to fold it, that route. Another option, I could write my own DSP framework, right? And spend my next five years trying to debug it and see if it really works. That's too much time consuming. I don't want to do it again. Or maybe I can do something in between. And I did it. Use Java. I decided to rewrite the Geosatellites piece in Java. Well, of course, I had to rewrite the piece of GNU radio in Java, right? The first thing, why Java, right? The first reason is because I know Java, I'm a Java developer. The second thing is write once, run everywhere, log when it still works. I can run my Java program on my MacBook, run it on Raspberry Pi in production, and test it in Travis CI or somewhere else where Java can run. So this is very convenient. I don't want to install Conan framework to do the package management and build the different options. Yeah, and this is single language for the whole stack. If somebody tried to get the settler data, you might know that you need to compile a lot of dependencies for GNU radio, some dependencies for Geosatellites, and hope for the best. This is a single language. The thing is I had to rewrite piece of GNU radio. And I did it this much way. Of course, I decided to implement the interfaces and make my blocks binary compatible with the GNU radio blocks. So the input parameters in my Java implementation are the same, and output and input are the same. So what I did, I created file source, run it through the interesting GNU radio block, and save it somewhere. Then I did the same for Java and just compared the result between the GNU radio output and my own output, and it actually worked. All my blocks are binary compatible, up to five decimal places. So if it is a float, then five decimal places are okay. So there's the differences, of course, between the GNU radio and my own implementation. The first one I'm writing in Java, so in Java we have very interesting equalities. So the first thing is a garbage collection and the memory management. So you can allocate buffers and then allocate them because that would create great pressure on a garbage collector. So for that, I pre-allocate everything. So my garbage collector just did not work at all, just don't bother with this. So these blue things are actually pre-allocated stuff. So normally, as you can see, there's no GNU operator and nothing is allocated. Another thing, another major difference is a single thread. So I must admit that the schedule concept is too complex for me. So I decided not to implement it at all. And as Marko said previously, the single thread might work. And actually, I think it's even better than running on multiple cores because if you have a multiple cores, you have to copy the memory from one core to another core, do a lot of synchronization between them and that could hit performance. And there would be a lot of cache misses as well if I do this on several cores. So I decided to go single thread and write my flow graph as a sequence of blocks. They just change one after another and get an input one from another. So from a programmer perspective of you, they're just blocks, one to one for the GVM, which runs this, it's just a lot of cycles. And GVM can optimize it very efficiently and compile it to the native code because everything is executed on the same CPU, on the same single CPU. And another thing where I chose this because I would like to run it on Raspberry Pi. And on Raspberry Pi, we have four cores. So one core would be allocated for these artels there. The second core would be allocated to DIG modulating decoding. The third core might be allocated to some system-wide operations. And the fourth core might be just in case. All right, the third difference is tests. So my inner enterprise developer admires this picture. I wrote a lot of tests, so that's why I'm saying my blocks are binary compatible. I have proofs, of course, and I wrote a bit more tests for the decoders as well. So I took some data from a satellite recordings project, which is run by Daniel as well. And some data from Art2Cloud, my own project. So what's the difference between the two? So satellite recordings, they contain very strong signal, which is very useful when you want to test for your decoders. You want to make sure that you understand protocol properly, and yeah, it's easier to do a revs engineering. But if you want to decode signal in a wild, you have to deal with a multipath, with a Doppler, with a neighborhood antenna, and whatever might come up. So I have two types of tests for this, one for the protocol and the second one for the real-time signal, which I collected from antenna. And three years later, well, nearly, I've implemented some satellites, the active satellites from GR satellites. I've implemented all transit repositories because the satellite owners, they provide some code, which is useful, but it's not normally, doesn't normally feed into other stacks, or ever implement everything and just run it on a single thing. Lip-fake, everything. And I got resolved. This is a real telemetry from real satellite, from real space. It contains some boot count, some voltages, solar panel thing, whatever, really cool thing in JSON. Yeah. Also, my base station can automatically schedule the next passes for some satellites. As you can see, the green line is a line where I was able to decode at least one packet. Yeah, so as you can see some, I was not able to decode some working fine. Then I can aggregate the data. So several base stations can transmit the data and I can analyze it on the central place, somewhere here. And you can share this data with the set knocks, again, with some researchers, FunCube, warehouse, whatever, and a great bonus. I have a real picture from space. Here it is. This is the night side of the earth, as you may see. And this one is a bright one. This is an image from Meteor M. This is Russian satellite, protocol LRPT, yeah, and it can transmit the data and I can one day can put this image onto the Google Maps and see how the weather changes over time. But for now it's there. Actually, it looks much better on my laptop. Yeah, I'm used to Discord antenna. This is very simple, basic, and with a negative gain. But it fits my purpose. Then a very standard block, V3 after there, Raspberry Pi. Right, I'm talking about Java, but never said about performance, right? But I'll just say that the performance not really needed here, and here's why. The first thing, the satellite, they transmit the beacons one way only. So you cannot reply it to the signal. So this is one way transmission. No need for real time. Then RTL is there, this is only the receiving. It can only receive the data. So even if I can respond to it, that doesn't allow me to do it. So I don't really real time response to these packets. And no one on Earth is really interested in getting real time beacons in his university. Okay, give me more data. I can spend any amount of time doing a decoding. I run some performance metrics. So for CubeSat, this is a very narrow band signal, 10, 15 minutes for the full pass. So this is nearly real time because it takes nearly 10 minutes for the satellite to pass over. And one hour and a half for Meteor M. Oops, but that's not really Java related. This is what we're doing. Anyway, performance is not really needed in this kind of software. I can optimize it maybe just to reduce power consumption and run on solar panels. But for now, it's okay, right? What can be proved, demodulators. They definitely need to be improved. I haven't found any resources which clearly state what the parameters for demodulators are standard. So I have only BPRK for BPSK demodulator. And that's it. Maybe I need more parameters like time to log, time to re-log the signal, any other parameters. For FSK demodulator, we need BPRK or whatever, multi-path propagation is not covered here as well. So this is just AVGN channel. Yeah, and I need more demodulators, FSK, QPSK, or SK parameters, real-world signals, the lack of them, but it's getting better. More satellites, as Daniel pointed out, satellites constantly launching in space and they're constantly falling on Earth. So this never ends in battle between the Earth gravity and satellites. And we started to support them more and more, maybe FPGA stuff, to optimize demodulators and reduce power consumption. Yeah, and this is it, I think. Thank you for your time, thank you for listening. Open to our sessions. The question was, what's the support for famous Earth... Well, I support for any RTL-SDR compatible sticks. So if they can be run with RTL-SDR program, then I can support them. No, no, I'm a single developer. I can support the variety of hardware, so just only one. Sorry? Yes. You're right. So my demodulator is a red one. So it's... But there is this Berkoff-Kaldus on the AVGN channel. If I want to test against a multi-path propagation channel, then the Berkoff would be different and it might be worse than the theoretical. Yeah, it looks good. Yeah, so I spent some time on tuning it. And actually I took a lot of code from a GR satellite to do it, yeah. Question? Yeah, because of complexity. So if I want to run my thing on a MacBook, then I need only Java dependency. If I need to run GNU-Radio, I need a lot of dependencies and dependencies of dependencies. And sometimes it's not very convenient and sometimes I want to run the tests in cloud. So all the tests they're running in cloud, in trade-stri integration. So I'm not sure if it would be possible to install all these dependencies there. Questions? No, I just focused on the decoding. Sorry? Did you also plan a space segment of the satellite or is it just to receive the segment you didn't do? I mean, would this be on a... Yeah, the question was, is there any plans to put on a space segment? I think it's not my choice. So if anyone would like to use it, it's freely open, just use it, see the data, you can just open GitHub and see the tests, everything's there. Do you see the possibility of... Yeah, yeah, yeah, so all decoders, yeah, it could be possibly used, yeah. All right, I think this is it. Thank you very much.