 So I'm really happy that this works now. I have the honor of actually having the talk that says, OK, how to start using the radio with something that I want to do myself and not only do something that someone else built somewhere. So the topic of my talk is from 0 to 60 or 30 minutes. I guess we're going to do it in 15. This is going to be fun, I hope. I have a small demo out in here, so maybe this will work out. So what I am is an electrical engineer, which means that in practice nothing works. In practice, there's nothing you can do. You have your tools. You have your problem. You analyze your problem. You apply your tool, you implement the solution. And then it's just like improvement by iteration. So in the end, you go from, I have my tools. I have my problem. I have my solution. And in reality, that's the kind of special with the radio, which is kind of the thing that I'm here for. The reality is, yeah, you get your tools ready. Then you fix the box in the installer of your tools. Then you familiarize with your tools. Then you really understand your problem again. And then you get nothing for the third time today. In the end, it all takes a long time to actually get a system running. But that's really how I like to do it, how engineering works. So rough structure is, this was my intro. Then I'm going to quickly go over how to actually get ready, because at the end of the day, it's a package. And it's available for most distros, but there's cave in it. And then I'm going to go about how to really go and solve an actual problem by designing your own neuray application. And if there's nothing that is already there to solve your problem, how to build your own tools with neuray. So getting neuray is a little bit challenging, often, because, well, neuray is a relatively big project. And it does a lot of DSP stuff. And it has visualization. So we've got a lot of dependencies. In fact, those are just really short-served. And there's a few of my favorites in there, and everyone remembers Rift, the only project in the world that I don't know anyone who actually built a full configure, include all of these features for me. And there's really a lot of problems getting the right dependencies on many of the operating systems. Then, of course, it's like we're trying to be cross-platform, which means we support Linux. And that means we can all the right places for the different distros. We also have a lot of people that do their work on OS X. So this is a pretty popular platform. And it's pretty well supported in our community. And then we have Windows, which is also a popular platform, but not really a well-supported platform. And I'd say we have a job. We actually worked a lot on that. But it's kind of like Windows development feels strange to a lot of us to say these. And also, all the facts that in Windows development, you can't be sure that headers are somewhere in user included or somewhere similar. It's really strange. And it's making it hard for us. But it's a work in progress. So if you want to help with that, that would be awesome. I'm pretty sure that we can use a lot of help with that. So what's also challenging is that the radio is a software development tool, kind of thing. So you might want to take a deep dive, like the gentleman who asked about the textbook might actually want to develop a feature with new radio actually fiddling with the interior workings and not mess up the bread-bringer new radio that he uses to do his FDR workforce employer. So this is really often a problem that you actually want to have different environments on the same computer and not always spin up a virtual machine just to try a different version of something. So, well, obviously the optimal solution for installing new radio is like use your distro. Well, the distro managers, they usually, the maintainers, their job and their dedication is actually to figure out how to build software in a way that they can package it and they always include the right dependencies and you never end up with something that doesn't work with the version of the library that's installed. So if you can, obviously you normally use a distro package. And the reality is like new radio is not only one project, it's like new radio and then there's the ecosystem where a lot of people actually just write a lot of tree module, write software that uses new radio and it's maybe very useful for someone else but it's not realistic that they're gonna end up writing like package for Debian, for Fedora, for Red Hat or whatever. That's really not the case in a normal sense. So the only thing that we can do is make that easy and also have some mechanism to install it. And of course, like if you want to have new radio with Comfort port for some reason, you need first in a recent version and you just won't get that on most distros. So today is not very probable that it comes with that right version. And all the versions are broken, but that doesn't change the take that Red Hat can't go back in history and just shift newer version. And so here you are with that problem. And also like obviously this is an open source developer's meeting, so everyone wants to look at code and build it themselves. I mean, aside from getting to people, that's really nice for if you want to look into something. Enter PiBombs. PiBombs is our, I always forget the full acronym, so this is our Python build overlay manage bump system, which takes the job of knowing how to install dependencies, knowing what dependency package, including the radio has. It knows how to install using your distros in standard ways or it knows how to build them from source if there is no standard ways or you're asked to build from source. So this is just really a nice, who can pick up it as something that actually like just takes the burden of going to the website, knowing to get the data that you have to clone, knowing how to call configure, knowing how to call make or see make or whatever, and installs it into a prefix. And this is really interesting. A prefix is a directory where you put your stuff and you just like point your runtime library linker and you point your path in there and suddenly stuff is there and you can execute whatever can vary companion and it works. And if you don't set the variables, your Linux system or your OSX system just doesn't know that like there's other libraries in there and it just every ever interfere with operation of your normal system. So this is something that has been very, very helpful for people that run experimental software everywhere basically. Since forever also, but no one knows that if you're a Python there, you might have to use virtual amps. So this is kind of the same idea. You'd basically just set the right variables in Python now where you look for Python modules. So getting PyBons is really simple. I'm not gonna go into detail about that for contemporary reasons. Using it as even simpler, you just like say, okay, this is the script that sets all my paths and you're done. You do that and then you can call your radio and it starts with radio applications and everything's there. But I mentioned that it is an ecosystem and Ben mentioned that in his intro. We have SeaGram and there's like every, a lot of out of three months or a lot of applications that people develop are already available easily and you can just install them by saying, PyBons install or whatever, PyP cap. And then you suddenly have an interface for capturing packets with wire chart in radio. So this is pretty awesome and it eases the installation of stuff pretty much and also it gives us the ability to distribute something easily. You have a central idea of what's there, what's missing and also like where to report bugs and this kind of thing. So this is the chapter break. I should have part that more clearly. We're coming to the part where we actually go from, okay, we have new radio, we have ways to install it. We have the idea that new radio is some kind of, yeah, five minutes, some kind of signal processing system. But how do we get from these abstract ideas to an actual implementation concept? So what I did is I looked at a simple like physical radio receiver and that's what we often think about it. It's a shame, it's a shame of, there's an antenna, there's an amplifier, there's a digital test mixer, there's an analog to digital converter, there's a digital PLL, so in my car radius ever something locks onto the channel I want to receive, then there's an emodulator and equalizer, so it doesn't sound as shitty, and then there's like the digital analog converter that goes into my loudspeaker amplifier and then there's the loudspeaker and so this is my whole system and this is how I want to understand it and how I want to represent it in the end in my software that I'm gonna write because, you know, somebody can read it. So, if you translate that into new radio and then it looks kind of like this, I'm gonna jump back to the last slide a couple of times so we have the USP source or the LSTM source or usually you just use the Osmo-com source which is like, yes, this guy wrote that, so, which covers a lot of hardware receivers and that has the job of like, that encapsulates your hardware interface which usually ends here, so this is all encapsulated by hardware source and so the next thing they do is like, the carrier tracking, then we have the FM demo that this maps one to one through like, the logical blocks that you have in mind when you're designing that system. Okay, then you have, I built like an equalizer that I could explain in four types of sentences, like we have three, we have three band pass filters and everyone covers another part of the audio band, everyone has a different gain and we end up with, and we add them back up so we can change the amplitude of like, the bass, the medium tones, the high tones and then we just feed it into our auditing which is like, the sound card and everything behind that does. So this is like, theory of your system converted to practice in less than two minutes. So, I have a demo, but I'd rather actually skip that because Daniel actually showed the same demo with GQRX which of course looks nicer and I just had the same flow graph for ANSI radio so that works. So this is my whole flow graph that works and it looks like that after you click together this. So you can build an application that actually like receives the whole ambient by clicking together this in the radio companion which is kind of awesome because if you understand what you wanna do then getting from here to there is really like five minutes of work. This is the power of software defined radio and especially in radio, if you've got the right tools you can just build what you want in a minute. But I have a minute left so I'd like to point out that it's not always the case, you don't always have the tools. For example, if you wanna build something really absurd well no one's gonna be there to build that before you come there. So you invent an out-of-tree module which is like our kind of saying okay this is a new radio package, you can have your blocks in there, you can have your flowgrass in there, you can build your application in one direction and share that with other people. So you build your new radio package and that's really easy, there we have tools, there's a new radio module which this meant to like build modules, you just add a new tool and my example for that is you can actually like build I thought okay what's absurd and I said okay let's do a speaking block that says at the next peak it's whatever, too late, you're telling me so. So how to do that, okay I'm lazy, I'm just gonna use something existing and write a Python block because you can write narrative blocks in C++ Python and because I'm lazy obviously I'm gonna go for Python and why do I do that? Okay we're gonna skip that point and how should it look like it's really like I have a clock and it just says at the next peak it's so and so and actually what I did then is like okay I make a new module, so new module speaking clock so okay I get that new module, now I change the directory I add a new block, I say it should be Python and then I add the functionality which is like eight lines of code at the right place. And you have a demo there? Yeah. So we can do that. I'm just gonna skip Q&A because I wanna see the demo and I'm just gonna say we have to let people out of the room like more than we can let in so I'm gonna walk over there and be about the demo. So the demo is really short, we can do that actually while people. No, we can't. Go ahead. Okay. Dr. Ramseh, so here we go. At the next peak it will be 12 hours, 25 minutes, 10 seconds. Which beat I have? At the next peak it will be 12 hours, 25 minutes, 30 seconds. So that works. Everything that I did was actually like right this block. Now, how does that block look like? Well I'm, so it's the most ugly code that I come up yesterday night. So it's actually like it's a state machine that says, okay, am I currently emitting samples? Am I waiting for the next time to say ding ding ding? Or am I currently speaking? And then it's just like place a ding ding ding song or wait. Where is it? Yeah, it actually generates the voice for the next second while I'm waiting for it and does that by calling eSpeed on the command line. So this is the most stupid way to do this, but it actually worked. And it was like 20 lines of Python and I put it into different things because I wanted to have time to mark but in the end, yeah. So, this is all that matters actually is in this work method which really just takes the input sample, in my case it was source because no, there's no input on the top. Then it generates output items and I write in the items whatever I want to generate and that's how you write the radio blocks basically. So this was a really, really, really short intro to writing the radio blocks. I actually rather have a little bit of Q and A so I'm gonna conflict around here. Okay, you have one minute and people can start leaving the room while you can get exactly.