 science fiction story, talk about the communications. You always see it supports everything that you're doing, all the cool things that are happening in that science fiction story exist, and that's all, oh that's cool, I want to build that, I need that, I need this. It's all underlying, there is the communication, but nobody deals with that, it's kind of the hidden layer, but it's such an important layer, but it kind of is hidden for a reason, and right now it's almost too popular, it's almost too much in the conversation. One of my telecoms professors used to say that the telecom engineer, anybody only thinks about him when the system fails. So we actually don't want to be that person, we just want to be the underlying tech to support all this stuff. So a lot of that is going to be taking it from the utility of the processors, your software radius, or utilizing your CPU heavily and mismanaging the resources of that CPU. Because you really want that thing to just be, you just want to launch a new radio as part of the rest of your application, and can do all the other stuff on top of there, and integrate it with the rest of your operating system, and just it being the tool that gets your data from one point in space to another point in space. So getting that processor, utilizing that better, and getting it out of the way, is going to be a huge part to support the cool things like what Bastion does, like seriously doing his output, and the capabilities of the tools he's produced. He's up here making use of this stuff, right now we're all, a lot of us are still down here trying to just get that to move that data around. Looks like a mic is not working. Oh, okay. Alright, so challenges. I kind of touched on this in my talk a little bit. One of the things that I think is really cool about software radio is how many different fields it requires to be successful. It requires people who know how to write operating systems, people who are skilled with embedded stuff, people who know wireless communication systems, and DSPs, and FPGAs. That's also a significant challenge, right? And what we commonly see is we have lots of different users who come to the project with different backgrounds and different expectations, and they end up perhaps not uncommonly not being successful. One example would be somebody who spent half a decade in grad school studying cellular networks and designing the next cellular network that will be deployed across the world, and they're an expert. And, you know, these sorts of algorithms and theory, and they know, I'm going to develop this in GUNI radio, and they sit down and they're told, oh, you know, you need to install this list of dependencies and build something from source and make sure your Python path environment variables is set right. And he's like, what's Linux, you know? And that's a little bit of exaggeration perhaps, but it's not far from it, right? So people who are these wireless people, we want to use GUNI radio, which makes sense, right? It's a wireless tool, but they don't have the software experience. And from the opposite side, we have people who are coming into us from, for example, the cybersecurity community, who are software experts and infrastructure security experts, who maybe don't have the DSP background. So they open up GUNI radio and they see examples of flow graphs, and, you know, it's like, oh, the loop bandwidth of this is 43 kilohertz, and then we're passing it through a polyphase channelizer, and then we're equalizing it. And to them, it's like, whoa, you know, I was just thinking this was going to be writing Python code, and I realized I needed to understand 100 years of DSP theory. And so the approachability and usability of the project, I think it's a significant challenge because we have to make it approachable and usable for so many different types of people. And we've put a lot of effort into this, and it's come a long way. So now you can come to the project without any DSP background at all, and you can see lots of examples of how people have built things, and you can learn how it works and then add on to that. And, you know, we have the out of tree modules where you want to track, you know, you want to track Air Force One as it flies around the world. Well, somebody already built that for you, and you can install it and track Air Force One as it flies around and see how it works. It's just maybe cut that part out of the video. And in GQRX, for example, which was demonstrated several times, that's an example of a really great front end for, if you're a ham radio enthusiast, GQRX, as you saw in Daniel's presentation, was immediately useful. GQRX is built on top of GUNI radio. That is a GUNI radio application, but you didn't even know that looking at the front end, right? So this problem of usability and approachability and making it so that lowering the barriers to entry. So regardless of where you're coming from, you can come be successful in the project, regardless of the technical challenges that you're trying to solve. That in itself is a really big challenge for us. Yeah, I'm actually going to comment on that, and I think it addresses the problem from Bastion as well. Why do so many, so little people actually contribute to the action? I think it's because it's a really steep learning curve. How many of you are from PhD students or professors? How many of you are in academia? Okay, so that's much less than I expected. I've seen it dozens of times, a PhD student who comes to me because I know a bit about how to defend radios, and he asks, yeah, my supervisor wants me to do this project, which is completely unrealistic, but his supervisor doesn't know that. And, you know, he's just screaming at the student until he gets it done. And, you know, to build prototypes, especially like you said, when you're looking at LTE 5G, these 3D advanced standards, you need to deal with propagation, RF, FPGA, and then you have this electrical engineer who has been working in Windows most of his life, and yeah, I started out, I never used Linux before starting to work on this ER either. So it was a really steep learning curve, and I think documenting that for all kinds of different people would really go a long way into bootstrapping a lot more, at least from the research perspective, really helping people getting started. Because I see a lot of people just get started and just give up after a few months because, you know, they don't get it, they don't see it, they don't go the extra mile to learn something and learn how to code in Linux or how to do C++ or Python or whatever. So I think really, I mean, someone was suggesting a textbook before, I think that's actually a really good idea, but, you know, target to a certain audience, of course. So yeah, I wanted to say the textbook thing, because I actually tried to write a textbook when I was running the project. So there's kind of two issues with that. First, because I was developing the project, trying to explain to people, like, we forget very easily what other people don't know when we walk into the room, right? Like, we can go very high level, very quickly, you know, I've tried to talk to undergraduates, and suddenly I'm in like, you know, PhD level mathematics and they're just like, you know, blank. You're like, oh, sorry, sorry, let me, you know, let's back up here. So trying to figure that out is really difficult from, you know, so from my perspective. And that's what, so we actually made these, these tutorials. Marcus over there was hugely helpful in that. And a lot of the, actually, Carl's your students and others, we actually, we specifically went in and tried to get people who were not going to radio experts, but had like, but, you know, knew something about the area. We're a little bit familiar with it, but so that they could think from that perspective of, you know, I didn't know this when I came into it. So this is helpful to put that stuff down. The second thing that I had a problem with writing a textbook was, by the time I wrote a chapter, it was already obsolete. And that was just really annoying because we were moving so, so fast writing that, writing in a radio and doing all the cool stuff that we now do. I'll leave it to Ben to kind of maybe think about where we are from that perspective, because maybe it is at a more stable position now, as far as just the rapid movement that we're doing to get to where we are. Maybe the stability exists so that we could write that, because I think it would be helpful to have a text, a something out there. I'd like to not go too far in that. I will, I will, I'll pick you in a sec. I just want to sort of make sure that we sort of stay on track and focus and, you know, move this in a good direction. I'm going to go into whatever one of you said right now, but it seems like this accessibility is sort of like the most urgent problem we need to solve. Just like just talking to you four guys. How many people here have tried using Canoe Radio? Just raise your hand and keep your hand up if you feel the same way that it was hard to get into. So it's like people are actually, essentially, yeah. So I feel like this is a good thing to talk about. It looks like this is something you're also interested in. So before we forget about you, let me pass you the microphone. Thank you. Well, I have a booth question and answer to that, and it's probably more to my academic colleague. Well, I'm responsible for like 40 hours of RF design experience stuff, and I have like 10 students in Master 1. And I think they would be interested in contributing to that kind of project because I'm completely against a vertical classment of student project. I find that completely stupid. People work on stuff that makes sense to try to make them work for the greater good of the community. But where do I start? Actually, while we're at it, let me collect a couple of audience questions and make it slightly more efficient. And I feel like people want to give more time. Yeah, this is maybe very obvious to the people in this room. But when I talk about new radio to friends who are interested in RF, they don't understand exactly what new radio is. And to me, what I try to tell them, it's a tool to build tools. And I feel that that's something I had to figure out by myself in a way. New radio is not an end to itself. You can build something that will work stand alone. And if you have one particular use case, like for example, I design hardware, which communicates over RF. And new radio is really nice to build a test bench or something to measure the performance or whether I'm polluting the airwaves. And when I've built that, I might not touch new radio for another six months. But I want that tool to run daily and to run stand alone. And ideally, and that might be science fiction, but I would even like to take that tool and put it on my phone, like Android, because we all know that it's going to be a lot harder on other platforms, but at least like to build that into something that can work stand alone. And maybe I won't need new radio. Well, it will be there as a library, but my tool would be like GQRX. And that's actually one of the only examples I know of a tool. And there are probably others, but of a tool that like kind of spun out of new radio and is now a tool in and of itself. And I don't know, maybe there is something to that and telling people, okay, you love that tool. Now go learn what has been used to build it. That's a great point. We address it in G-Sock a little. I think Ben would be a good guy to comment on that. So Jean has a question. I just wanted to comment on the teaching part. I'm teaching about 30 hours of digital communication and radio frequency. And when you ask, did you find new radio difficult? I did raise my hand, but actually I was mistaken. It's not the new radio part that I found difficult. It's actually the, well, the particular thing I found difficult was propagating the right sampling rate. So being consistent on the sampling rate between all blocks. And what I mean here is I didn't find new radio difficult. I found the DSP difficult in the beginning. And once, I think this is really the main challenges is the story about being consistent about the sampling rate. And after 30 hours, we can get a few students get involved, at least from the user perspective, using new radio for demodulating of various signals. We do, of course, Poxack, we go all the way to GPS with the students in 30 hours. It's a bit difficult, but we get to there. But I think new radio allows student involvement within 30 hours of teaching. So that's a comment from the practical. I'll give, I'll add one more question and then we'll sort of try and actually get some more. Also a question. Well, as a user, I also use other things like a red pitaya where you can really have an app store or something. You can demify you, you just go there, you run this application and it works. And then you can start digging deeper and modifying things. And there's new radio. I had this feeling that I had to work to make my first application. And then when I wanted to discover go deeper writing modules, every time it's really quite a big, big, big step. So it, my suggestion would be to have some even simpler way of getting this first great thing going because that motivates people. Okay, so I think this is going to let me just check my notes. I'm trying to keep track of all the questions. So we, we don't have all that much time. I think we've already come up with way more things that we could talk about in even the entire hour. But there seems to be a common theme here is sort of the accessibility and then how to get people and basically your questions are how to get people started. It could be a very good segue into sort of the next section. So I know I cut off the book discussion, but I feel like this is more relevant to more people in the crowd. So I'm just going to pass that on. Like, how do we get started? So we have a, the specific example was we have a classroom of master students. Well, it would be a good thing to do, a good first thing to do. Okay, so just a bit on documentation. I think Edus did a great job on UHD manual in the recent years. I mean, I remember when I started on it, it was just haphazard collection of notes. And it was very hard to find anything. And you had to go on a mailing list all the time and spam you and stuff like that. And I think this has been really worked on recently. I think that's something that could be done in radio as well. So you said something that those master students could do though, as a contributor? Well, okay, I don't know, but they could use that to get started, I think. You know, if they have a couple of web pages, it's easier to maintain and to update as you move along than a textbook, which you're probably right about that. But that manual really went a long way. So now I can just send my students say, okay, you read those pages of the manual and come back in one week and then we can actually get started on more interesting stuff. So I kind of hear two separate questions. I'm going to answer your question. And actually, I'm going to answer all the questions again from this side of the room at once. So regarding just DSP stuff generally, right, you're talking about sampling, right? But there's lots of stuff like that. Yeah, a fur filter, right? I mean, what does FIR stand for? Right? How many radio users know what FIR stands for? And I mean, it just isn't a... Thank you, Phillip. And I remember an email that we got on the mailing list several years ago, someone who was sampling subnyquist and was furious that Gunradio was aliasing his sinusoids. And, you know, you think about stuff like that, and I may have just broken the mic. And so going back to the comments I tried to make when I was opening, I think one of our major challenges is making Gunradio a tool such that it is approachable by people who perhaps don't have that background, you know, and making it so that if you look at it and you don't know what all those words mean, it doesn't scare you, right? And I don't think that we've been successful doing that yet. Coming back over here, we're talking about education, getting people started. I kind of see this as all one big problem. So education actually is a really big deal for us. There's lots of universities that are using Gunradio and actively developing, not just labs but also curriculum development. Actually, one of the groups I mentioned in my presentation, the NRAO, National Radio Astronomy Observatory, has recently secured federal funding in the United States from the NSF to not just teach students about RF with Gunradio, but to teach teachers with Gunradio how to teach students. And that is extremely exciting to me, but it's also a little bit terrifying because they're high school teachers, by the way. So you imagine high school teachers trying to resolve falling down a dependency hell and trying to figure out how do I install the right version of Python on this legacy CentOS system that my high school says I have to use because they haven't updated their network in 10 years, right? I see some people who have experienced this, right? So containerizing things, I'm using the word container here, I realize everyone thinks of docker, as you say, container, or flat packs, or whatever the current rage is. But containerizing these sorts of things such that Gunradio itself cannot only be and then easily deployed to the question that you had asked is something that we're actually working very hard on right now. That everyone recognizes that as a huge challenge and that if we successfully solved that problem, it would make everything easier, just everything easier. And so PyBombs is actually the first step in our process towards that and you're joking about an app store, but we are actually very serious about an app store. So the way PyBombs works is PyBombs recipes and the C-Gran website is actually auto-pulling the PyBombs list of recipes and populating the web page. And so it's an easy step to go from where we are now to a GUI that you can browse and click and install, but the key enabling technology that we haven't solved yet is, okay, how do we, again, containerize all of that such that it is a click to install? Right now it's a, oh, I can search it, I can click it, and now I get clone install or PyBombs clone install and it does all the dependencies, right? It's that kind of difficulty that scares people away, that don't have the Linux experience, the software experience. So that actually covers a lot of what I wanted to say. Okay. You only talked about this is a similar processing side of things. For example, I'd like, for example, my cousin's tutorial on getting signed with the hacker network. Yeah. He does really good basic stuff. Yeah, so he's... He does simple exercise and now he's going to graduate. Yeah. And he does help at least to get somewhere and not to get, but you know where you're going to get started. I feel like Tom can answer this. So just to give background for Tom's response, I'm assuming, just to give some background before Tom responds to that question. For anyone who doesn't know... I'm sorry, what's your name? Case. Case. Anyone who doesn't know what Case is talking about, Michael Osman has a series of tutorials, video tutorials that don't just go over how to use GiniRadio, but they go through basic theory that you would need to design a wireless comm system from the ground up, including what is a complex number. Right? It starts at that level. So with that... That's great. Yeah. Because that's right. And Mike Osman is a part of our community. You know, he comes to our, the conferences, you know, he promotes, uses GiniRadio, he promotes it. And when people do ask me this question, where do I get started? That's often one of the first places to point them to. I think Marcus over there probably has a macro now on his computer to reply with tutorials.giniradio.org. Yeah. Like, we had so much that they made a subdomain, tutorials.giniradio.org. You know, we did spend a lot of time on that because we were focused on this problem. But of course that only covers a certain number of subjects. I had always wanted to take that even further and have more of those types of tutorials and improve there. But, you know, Mike will help give you some of the background DSP. The tutorials will help give you some of that, especially like how do you write a block? How do you write a block in Python and C++? So there is tools out there. And, you know, this has been a conversation we've been having with the community at large for basically 10 years since I've been, or more than I've been involved in this project. So we definitely heard you. And it is a big part of what we've been trying to do. Obviously we're not there yet. And again, you know, I have a PhD in electrical engineering and wireless communications, right? So it's like, how do I take the years that I spent learning this stuff and condense it down into a week's worth of material that you can walk away with some confidence? It should be done. I think we can do it. But it's a tough challenge just to kind of lay that out there. One of the two things I don't want to do before I let Bastion respond. One of them is maybe to take some of this under, but really to, he pointed this out in his opening remarks and I want to just reiterate them because I think it was a very astute comment that we haven't really, I don't think, thought about. Is Sea Grant and Pi Bombs were built to support this ecosystem of all these tools and apps that people are creating on top of the toolbox of Gini Radio? And that's great, but they tend to just be a single user who is behind that and who maintains it. And so if they go away, if they get sick of it or they just get a job that doesn't support them or time to do this stuff, what happens to that code? It starts to bit rot. There's no support for it. Nobody replies to the mailing list on it. That's a huge problem. So I think we've been building the community around this idea of Sea Grant, but not really really focusing on getting more than just a single author invested and working on some of the big tools that people do want to use. So that, I think, is something that would be really interesting to work on. So the other thing that I want to mention, and I'm going to throw him under the bus, unfortunately, I love the guy, but Ballant isn't here to defend himself. But guys like myself and Ballant and others who go around doing a lot of presentations on how to use Gini Radio, sometimes they look back at us thinking, I don't know if we've really done ourselves the right service with how we've presented the material. It's like, here's all this cool stuff you can do in Gini Radio, and people walk away going, oh my god, that's so cool. I can do all this cool stuff, and then they sit down and they go, I have no idea how. So we kind of go at it with like, oh, of course, you just blah, blah, blah. It's just a block flow graph, and it's going to do this thing. And you're just like, but we almost oversimplify it when we show it in that light, as opposed to kind of going at a different level of, let's build this concept up. So, and that's like, we've shown how you can use Gini Radio, but it points to Jean-Michel's comment there about we don't necessarily, we don't dive enough into the DSP to give you the backgrounds in order to do the stuff that we can do so easily. So I think that's actually, that's something interesting. I tried to amend this a little bit in one of my last GR contacts. There was kind of a, there was a block or a tutorial that Eric Blossom wrote when he created Gini Radio, like probably him and Matt Addis probably did this together, called Hot to Write a Block. And it was to kind of walk through how you just kind of start from scratch and write your own block in Gini Radio. So I made a lecture that says how not to write a block. And it was supposed to, in 30 minutes, kind of walk through some of the common mistakes that we make when we write this stuff. And so kind of trying to go at it from a different perspective of when things go wrong, what do you do then? What we've often done is just when everything goes right, it's awesome. But what happens when things go wrong? So those are maybe some ideas that we can keep working on to address some of these topics. Okay, so I wanted to add that the problem with, yeah, that students find it very hard to get into Gini Radio. And I think it would be, of course, really good if we have good documentation so that you can tell a student, go there, read that stuff, and then you know what you have to do. But I think the ideal case would be if there would be also kind of getting help, like there would be courses, the sort of signal processing with Gini Radio, for example. And I think it's currently very hard for the, I think many senior academics realize that Gini Radio is a thing. It's cool. We maybe want to use it. But as you said, we then really are trying to implement something. Even if you know the theory and even if you teach that for years, I think it doesn't take zero time. So for a professor, for example, to create this new course, I think he might have a hard time. So these course materials that you mentioned that they create, I think they could help really a lot if you have some lectures and the virtual machine that you can just give the students so that they are up and running in basically zero time so that would be very beneficial. Then if they start with that class, then they can maybe read the more advanced material later and do some more bachelor's thesis or master's thesis in the topic. So I think that would be really cool for us to get more students. Let me summarize the current state of the discussion for us. So it seems like that we have a consensus that includes all of you in the room. I would please tell me if you disagree. Is that documentation would always be better? More is always better. That has always been the case since I joined the project 10 years ago. So that will continue being the problem. Of course, we don't have professional writers. Someone needs to write that documentation. So we have two loose ends. I feel like I'd like to wrap up. I just want to bring them up again so we don't forget about them. The first one was the actual practical question. What do your students do? And I feel like maybe this is coming together. Maybe we're sort of converging on a single problem because the other one was like, where are all those cool standalone apps? And that's also something. And that was the very first thing Tom brought up, although he phrased it differently. We can decode ATSC, but we don't have a cool ATSC viewing app that just looks nice. It looks like VLC or something and does a good radio in the background. By the way, that is a GSOC project that we've suggested because we are aware of that problem. It seems like the people in the community prefer working on the low-level guts and not on the shiny goods. Exactly what Tom said at the beginning. So there's a third thread. I don't think we'll be able to address it. It's like, how can we get more people to take responsibility and collaborate on projects? I feel like that's also a very generic free software radio. Sorry, free software, open source problem. So I feel like we can focus on that right now. But I feel like all the other things that we just talked about, they're converging on a common theme of when we get new people involved, what can they work on? By the way, we're lacking all these one cool standard on Absid B documentation. Maybe that's exactly the kind of direction we can go into. So I hope I haven't oversimplified the outstanding questions and statements here, but I feel like that's where this conversation is going. So we had a comment from Jean-Michel. I think we had another question and you wanted to say something. So what was your comment? I just want to rephrase publicly what I told Tom privately. I think last year, first then, he emphasized the use of new radio for prototyping DSP. And this is, it's really a pity that this talk was lost because it's new radio for listening to real things, one thing, but prototyping DSP and getting your hands on DSP, that was really for me a great insight in your talk. And I think that's really something that should be emphasized. Even if you don't have hardware, new radio is an awesome way of prototyping with simulated signals DSP and getting insight and getting to touch what DSP is beyond the boring mathematical course. And actually, it makes mathematics much more fun. Okay, I forgot to give you the mic, but what Jean-Michel said was that if we want to play around DSP, a new radio is a great tool, especially for the prototyping. Okay, I'll give you back the mic and just start with you and you can pass it around. And I'd like you, I know you had another comment, but what do you feel about this concept that if we want to get the new students involved, maybe we can just have them building the apps? Is this a feasible direction the project can take? And maybe as a site issue, can we sort of work on the documentation in the same path? So I'm not really a software guy, I'm a hardware guy, so I don't know much about writing apps and making shiny things on the computer. I think it would definitely be a good selling point. There is a lot of stuff that's already out there in the new radio and that lacks this shiny display to kind of make it nice. And, you know, especially if it's open source, if people want to start changing it afterwards, well, that would be a great way to, one, get them involved and get them interested and start it using it and then once they want to go beyond what they see, well, they can still go digging in the codes and try to figure it out by themselves. So, I think I talk about this every single time I get the mic. Cross-domain, doesn't matter where you come from, something skim-skill you have is applicable. I think that, as a student, come into good radio, whether, you know, you're coming to good radio because you want to, because you're a DSP person and you want to build a DSP app or you're not a DSP person and you want a good radio app that does something that, you know, is interesting in your particular field, I would be blown away if any new user who came to good radio, students included, did not have a skill that would be, that they could contribute to the project. I don't care what it, even if you only know JavaScript, I mean, we have a need for JavaScript developers. We have a need for just about anything you could think of, QT developers. I mean, really, if you only know, you don't have any programming language, I mean, there's obviously a need for technical documentation, which is, and writing good technical documentation is a really hard problem that is often underestimated. So, I mean, I think one of the major problems in terms of, you know, people coming to good radio and they're starting to use it is, right now there's not a good way to know where the gaps are and what we, using the royal we here is in the project leadership, care about having solved, right? I mean, you could go to our bug tracker, which has lots of bugs in it, but unless you already are familiar with the way good radio works, most of the bugs probably aren't going to make any sense to you. And there also isn't a bug that says, for example, like, the good radio project would like to have a web front and that does X, or the good radio project would like to have a new QT widget that does Y, right? There's a bug that says, QT widget X is broken. Please somebody fix it because I need it for my master's thesis. So, one of the things that I've been trying to figure out internally is a way to communicate to the community at large the things that we care about and the gaps that are in the project, not just the problems that are currently in the project, but the areas that we want to grow into. Because then I feel like as a student, we're talking about here, students coming to the project, but I feel the question really is more general is as a new user coming to the project, everybody has skills, you know, and I'm 100% confident that everybody has a skill that can make the project better. And I think finding a way to communicate that and communicating, you know, all the different areas that you could contribute so that when you become involved, you know, even if you're not a DSP expert or a software expert, you're able to identify a way that you can get involved and start having fun. And that's just not something that we do well right now. He has a question, should I? It's directly, it's just a small remark. It's new radio is intimidating as a project. I mean, I know how to program. Sorry. Nice catch. Sorry. I'd say I'm a competent programmer, but not a really good programmer. I'm not an expert, but even when you have the will to contribute, sometimes you're like, I don't know how to ask these big brains where to get started. And so there's documentation. There is knowing where to put your energy. So you've talked about that. And how do you take the first step? To me, it would be interesting to know that there is someone I could ask just for help on doing it, not asking you, please fix the widget. I'm willing to fix the widget, but if I don't know where to start, it's also really, really nice to know that, okay, just being that guy and he'll get you started. He doesn't have time to fix it for you, but he'll put the time and effort to tell you at least where to look at. I know I already talked about 10 minutes. I really want to respond to that. Okay. All right. So I had this discussion really regularly, especially people who are not, who have heard about what it's like to contribute to free software and come away terrified from it, right? I mean, I have family members who have never written a line of code of software in their life and have read emails that Linus Torvalds has written, right? And are like, why would anyone ever do this? Why have you dedicated your life to writing free software, right? The Green Radio Project, it's always been this way and I feel very strongly about this. I'm not interested in that and the Green Radio Project, I don't think it ever should become that. Simply because of the nature of the project, we have to be inclusive and I understand, I'm not attacking Linus, I actually, there are a lot of projects and I can name some where I completely understand the need to protect your time, right? For someone who comes and says, hey, you know, you're, this is not a Green Radio example, but hey, your GSM base station isn't working, I don't know what GSM stands for, but please can you fix the bug for me? And I understand the immediate reaction to say you're not even willing to put time into this, you need to go away. It's often not said quite so politely. We will never do that and I feel very strongly that as a project we must always be inclusive and approachable and welcoming of developers, regardless of skill level. So, and we have a lot of people in the community who actively do that. I think Marcus Mueller here who probably should be more acknowledged for this has, if you're on the mailing list, he's effectively written master's theses in responses to emails that include like law tech equations, explaining basic sampling theory and complex numbers. So as a community we're already willing to do that and we're already willing to accept these people who don't have the background to even be successful on day one or week one or month one. But yeah, the problem that we have is exactly what you said is knowing how to contribute. Who do I contact? Who would I email? What website do I go to that tells me like how to just even get my foot in the door and start talking to somebody, right? And I would really like to solve that problem. I have some ideas about how to solve it and if anyone has feedback on that, please come talk to me. I feel provides students. Okay. So, yeah, that's great. Absolutely great because that kind of goes into what I was going to say and I fear that I'm going to get into mode of whining. So let me try to change the whining into setting up more of a challenge. The documentation issue, everybody's been yelling at me. When I was running a program at projects, your documentation is terrible, your documentation is terrible. Then I'd have it and I'd say, yeah, yeah, we know. We want to work on it. We're dedicated to working on it. We try to work on it. I think it's much better than it was 10 years ago. And then a few people, 1% will come up to say, I'm going to help you with that documentation. I say, great. We start getting emails back and forth and if they're going to contribute to the code, even the documentation, get them signed up so they can contribute to the Free Software Foundation as a copyright holder, all that stuff and then they just disappear. I've probably lost like two dozen at least people who are like, I'm going to help you with the documentation and then a month later, I never hear from them again. And I think maybe it's because they don't realize how difficult writing this documentation can be to do it in a way that actually can convey information. So and I'll put myself here. I wrote all the polyphase filter bank stuff in GNU Radio and I wrote documentation for that. So the header files, and some of the header files are like pages of explanation of the basic theory of how the parameters work and all this stuff. And I still get people say like, you can't use those polyphase channelizers. You just can't use them. They're like, where's the documentation? I've shown them the documentation. They read through it and they're like, I still have no idea what to do. So again, that just proves that like, and I have an English minor, right? I think I'm a pretty good writer but I still don't know how to convey my deep, deep knowledge of the math and the theory behind those polyphase channelizers into something that somebody else can actually pick up that block and make use of. So it's a hard challenge and I really want to bring somebody into it. So here's the challenge. As Ben pointed out, Marcus has written like literally probably, I don't know, there's a Ph.D. dissertation somewhere in all of Marcus's mailing list posts. Be cool. Now yeah, but I am because if you don't know where to start, start with Marcus's and start collating them. I am going to be a kind of a cool project to like collate the mailing lists and the answers that have been on there. Not just like buying the mailing list together but actually like, actually curate it into a textbook. I think it's actually there. I think in the past 15 years of getting a mailing list, if somebody can actually figure out how to go through and curate that thing. And that's, you know, the theory's there. The math is there. The nature of getting a radio is there. It just takes somebody's mindset to go in there and actually pull it out for us. I think it'd be kind of cool. We're already five minutes over the time. You'll get the last question and then you'll get the last question. Yeah, concerning the textbook issue, do you think it's necessary to write a textbook concerning DSP specifically for GNU radio? Or do you think it might be better to just point people to something like the DSP guide? What are your thoughts on that? That's a great question. DSP versus the GNU radio thing. That is the trouble I got into. I tried to write, here's how you use GNU radio. Here's how you use a fur filter. Oh god, what if you don't know what a fur filter is? Here's the math behind a fur filter. One of the forks I went off on was I was starting to write an intro to columns textbook. And there's already 50 of them out there. Some of them are great, many of them are. But some of them are great. So I actually don't know the answer to that yet. I think that is a valid question to kind of keep in the air. Okay, so I just want to add what Ben said, I think. So just very quickly, I think universities should kind of introduce a student to GNU radio, tell them about that. There are so many cool small hacks that you can do like receiving your coffee key fob or the airplane stuff and then make them aware of the project and once they are on the website, this list that Ben mentioned of some low-hanging fruits that allow new people to see what can be done like the JavaScript or Python or Qt whatever. So to allow them to make a first small contribution and have a good experience because from my personal experience I followed open source projects for a very long time but didn't really contribute because I was a bit afraid of it. And then once I came into it they were very welcoming and everybody was nice. I think it's really have a good first step in the door and I think that's really important. Okay. This panel has been frustrating in the sense that we, I think we started a cool conversation and now I have to cancel it and I'll call it off because we have more presentations coming in. I would urge people to continue. So for example, if you could hang around, I'd like to talk to you and I'm sure Ben or Tom might also like to talk to you. You know, if there's any more questions, I feel like if this panel is the one thing, it sort of exposes a couple of people who are interested in various topics so we can talk about standalone apps so at least we know each other's faces now. I'm afraid that's all we can do for now. I'd like to thank the panel.