 All right, so good morning, everyone. I'm going to start right away to keep in time. So this is actually work that was done by one of my students, Ricardo, who did a very great job on implementation. I really want to advertise this because it uses a lot of things that's been around on software-defined radios for a long time, but it's heavily underused for the moment, which is the FPGA part of the radio. So what we're actually going to do today is make a spectrum scanner on a software-defined radio platform. So why did we need to do this? Well, it was originally a demand from the Belgian regulator. So every country has its regulator, which one of its mission is to make sure that no one is transmitting on frequency bands, they're not allowed to. And in our country that's in Belgium, that's a BIPT who is in charge of making sure that whoever uses spectrum has indeed paid for it, otherwise you get a fine. So what do they want to do? Well, they have a bunch of technicians driving all around Belgium on all kinds of missions, going to Sol and Tennis, check and Tennis, whatever. And they want to have something in the back of the van of these technicians that's going to run continuously and do opportunistic spectrum scanning. So whenever this guy is driving around, there is a setup running in the back of his van that's going to detect all the signals that are around. And if any of these signals is not supposed to be there, then it's going to send an alert to the BIPT headquarters. So what are the constraints that these guys imposed on us? Well, first of all, they want to use USRPs and 2-10s, which is not the most recent model, but they have a bunch of them lying around in their offices and they don't know what to do with it. So they want to use these ones. They want to have the host controller to be a single board computer, something with a form factor of a Raspberry Pi. So that's actually posing some constraints in terms of computation power. If you want to start doing FFTs and stuff on a Raspberry Pi, you're going to get a dreaded overflow all the time. So you need to somehow offload the processing from the host controller. And they want to have no user intervention. The guy who is driving in the van should be solely focused on driving the van and not on tinkering on the radio on the site. All right, so when it comes to spectrum scanning, it's not exactly new. There's been a lot of code around, just listed a few that I could see here, but what is the main limitations with all of these codes or at least all the one I know of? Well, first one is very often the scanning bandwidth is limited to the bandwidth of the USRP. For N210, that's 10 megahertz. So we are talking about scanning hundreds of megahertz, maybe even gigahertz. The second problem is that most of these solutions for all of them are software based. And if you want to do something that's sort of real time on something like Raspberry Pi, then it's gonna run very slowly, all right? You're not gonna be able to do that fully in software. And that's why we go to the FPGA part, all right? There's been some effort on the FPGA front, especially with the radio RF knock. Well, one of the problems is with this model of USRP, RF knock is not backwards compatible. So you have to kind of dig in the FPGA code, which fortunately is available online and do the tinkering yourself. All right, so talk is gonna be structures as follow. First, general introduction about what the system looks like from the outside, bit of details about the FPGA, bit of details about software. And then if everything works well, hopefully the demonstration show how well it works. All right, so who here is a bit familiar with FPGAs? All right, that's roughly half of the room. So I'm gonna go with one slight version of what an FPGA is and how it's different from a microcontroller, right? If you have a microcontroller, you remember from computer engineering 101 that you have something like this. You have a CPU, which can do typically about a few dozens of elementary operations, all right? So whenever you write to high level language source code, you compile it, it's gonna make a long list of micro-instructions, which are gonna be executed one by one by your CPU, all right? The crux being that if you have a code that needs to do a lot of operation, it's just gonna take a longer time to execute. So an FPGA is different how? Well, an FPGA is made of a whole bunch of small elementary blocks, all right? And each of these blocks can implement just a handful of logic functions. And FPGA programming is essentially deciding how you want to connect those blocks to be able to do more complex operations, to be able to do more complex computations or yeah, more complex processing, all right? So you basically decide which blocks are connected to which other blocks and how these are connected. Now, when you write, when you want to work with FPGA, you typically write, I'm gonna say high level language, which is VHGL or Verilog, these are really hardware description languages and they're actually much lower level than C. So it's really still a step below C programming. And the big limitation that you have in FPGA is the size of your FPGA. If you want to do a lot of operations, you need to have a lot of logic functions and eventually you're gonna run out of these logic blocks. So that's the main limitation of your FPGA. If you want to do a lot of operation and you run out of space, you need a bigger FPGA. All right, so what about FPGAs on the USRP? Well, there is an FPGA on the N210. It does a bunch of elementary things that are required for receiving and transmitting signals, but if you look at the hardware resources, so this is all the hardware resources of the FPGA, you can see that there's still quite some space available. We're using anywhere between 20 and 80% of some resources, but that means there's still some space left to add your custom blocks in between. So going back to spectrum scanning, what do we want to do in our system? Well, this is basically your USRP. You get your RF signal, you don't convert it, go through the ADC, and then we want to do an FFT. Take the square magnitude of FFT and then for each frequency bin, see whether it's higher or lower than a given threshold. All right, if it's higher, there is a signal. If it's lower, there is no signal. We sent the result to the host controller and the host controller is then going to check with the database or just post-process it or store it for offline processing. The second task of the host controller is also to retune the front end. We want to scan hundreds of megahertz, so you need to retune the carrier frequency every so often. All right, so going into a bit of detail, so by the way, all the very low level details are in Ricardo's thesis, which I put on the FOSDEM webpage. So if you're interested in going into really fine details or in modifying the code, I suggest you take his thesis, it's very complete and he explained every single wire that's been implemented in the FFGA design. So the FFGA design is basically composed of four blocks. The first one, FFT, second one, taking a square magnitude, then the energy detection and then a data sync model, which I will come back to. So the key point of FFGA is that all these things are working in parallel, all right? Unlike a microcontroller, which is first going to do the FFT, then do this, then do this, then do this, in FFGA, all these things happen in parallel, all right? So that's where you get the big speed improvement. So each input and output has, well, each module has two inputs and two outputs, one for the actual data streaming to, and one that's just a control signal that indicates to the next block whether the data is valid or not. All right, so this is fairly standard in FFGA design and we have two versions of this energy detection block which I will come back to a bit later. So I'm not gonna go through the internals of each block because it takes way too much time and the screen resolution is just not fine enough to show every wire that you have in there. So I'm just gonna give a few of the key elements that we use in each block. So the first one is the FFT. So that's probably the most critical one. The FFT block does 1024 point FFT and that's fixed. That's not something you can change. So if you want to change the resolution you have a frequency, you have to change the USRP sample rate, all right? The size of the FFT is fixed for practical reasons in this case. The second block is just taking square magnitude of each frequency bin, very easy, two multiplication, one addition. In FFGA, you can do this in hardware and it takes three clock cycles. In microcontroller, this would typically take several dozens of clock cycles in the best case. All right? So the next big block is the energy detection module. So basically this block implements the following equation. You're gonna take the energy of a certain amount of frequency bins and you're gonna compare them with a threshold, all right? So if you have an endpoint of FFT, you're gonna look at the size M sub window and you can change this M from the software, all right? So this allows you to consider different type of signal whether you're considering CDMA signals that might have five megahertz of bandwidth or FM signals that have much lower bandwidth. And we have two versions of this block and two different FFGA images. One where you have a fixed threshold where you just set this lambda manually and one where you have a semi-automated threshold which takes into account the overall energy in the band so I'm not going into the details of this equation but the key point is that it makes it much more robust to noise spikes, all right? If you have a big noise spike, it's not gonna be detected as a signal. All right, and the last block that we have in the FFGA is data synchronizer module. So the key idea is that in these three blocks we mess up the signals and the time of the signals a bit and this block is basically gonna re-adapt the signals and especially the time of the signals to what we had at the input. And the big advantage of this is that we don't need to rewrite all the drivers of the USRP, all right? We're mostly electronic engineers in my lab, we're not that much software wizard so we don't want to mess too much with the drivers, right? And this block allows us to just leave everything standard. The only constraints that we have because of that is that the ratio between the USRP sample rates and the clock rate of the FFGA which is fixed to 100 megahertz should be integer value, all right? So you can set one, two, five, 10 megahertz, we cannot set 3.2 megahertz for example. All right, so let's look a bit at resource usage, so this was the default FPGA image. You could see what we have in terms of hardware resources and you can see that the two versions of our image just add a handful of percents to each of these resources. So we still have, we've been quite economical on the resource usage, we can still add a bunch of things. So typically in real spectrum scanner you also have IF filters that you put at the front so we still have some space to add those blocks in here. All right, so moving on to the software. So the software is actually very, very simple, right? It's very lightweight because it needs to run on a single board computer and it does very little things but it needs to do those things very well. So I'm just gonna give a few examples of low level commands that we have used that are maybe not so well known in the community. So the first one is how to set an FPGA registers from the software side. So there is actually a command in the USG drivers that allow you to do that. Very simple, very easy to use. The second command we're gonna use quite a lot is setting the command time. So you can specify at which time in the future certain commands should take place. For example, if you want to set the carrier frequency you want to change it exactly one millisecond from now you can use this set command time to do that. All right, so this allows you to change your carrier frequency at very regular intervals. All right, so this is basically what the software does. All right, as you can see it's very simple. Your infinite loop is here. You're basically gonna receive sample, reset the carrier frequency if you're sweeping over a wider bandwidth and then receive sample again and so on. The only smart thing that we do here is actually sending a bunch of commands in advance of the USRP. So if for some reason your host lacks a bit the USRP knows what to do for the next immediate few milliseconds, all right? So that allows your host to catch up a bit. And when we're running it with a standard laptop so this is, you know, four gig of RAM stuff like that so nothing too fancy. We're able to scan one gigahertz in two 50 milliseconds without running into any overflow problems. All right, and this is continuously so we can leave it on for half an hour and no problems on that front. All right, I'm running a bit ahead, that's good. So we also have a small GUI. So it's just for field testing. You want to first verify that all your settings are done well, that your antenna is connected properly, things like that. So there is a very lightweight GUI. It looks like this. We're gonna see it later in the demo. You have your frequency spectrum and then here you have the detection result zero. If there is no signal one, if there is a signal and both of these results are written to a data file. So currently the data file is just overwritten at every sweep. This depends a bit on what you need to do exactly. All right, you can store data for a bit longer but of course eventually your data files are gonna grow quite rapidly so you want to manage that a little bit. All right, so just some few results from the lab before I do the actual demo. So this is when we generate signal with a signal generator. This is roughly over a 100 megahertz band. We have a Bluetooth signal here and then a multi-carrier signal with 20 carriers. And you can see that all of these signals are detected appropriately. If you would zoom in here, you would see that the bandwidth of your Bluetooth signal is roughly compatible with the bandwidth we set at the transmitter side. So this is with a cable between the USRP and signal generator. You're not allowed to transmit whatever you want, especially at these frequencies. This is just detecting FM radio stations. So while you can see that you detect a bunch of stuff between, this is over 20 megahertz band and Ricardo was very patient and able to match every detection result with one of the actual FM broadcast stations that we have around here in Brussels and match them to the different transmit towers. So we are here at the university and a bunch of transmit towers all around Brussels. We're able to detect, well, all of them up to, we could see up to 12 kilometers of range. So before I move to the actual demo, all the code that we did is available on GitHub. So what do you have in the GitHub folder? You have the FPGA source codes. So unfortunately, to turn it to something that you can put on the USRP, you will need silence. So this is preparatory software. It's not cheap, but if you're working at university, most of the time people have it and you can use it. So we also have the FPGA images, which you can flash straight on the FPGA on the USRP. And of course, all the hosts, C++ code and a C mix and some junk we used while making the software. All right, so let's move on to the demo. All right, so this is basically the command that you need to execute to call, to start the function. So you can see some classical stuff like the USRP sample rate, the carrier frequency, the gain. And then you have a bunch of more precise parameters. So threshold is the level of your threshold. Window size is the size of the sum window that you're accumulating energy over. And this end parameter is just a number of 10 megahertz windows that you want to accumulate over. So in this case, we're gonna look at two times 10 megahertz or 20 megahertz bandwidth. All right, so we're first gonna start by looking a bit at what we have in the GSM band. So we just preloaded the command. So these are basically the different GSM signals that you see and the different signals that are detected. So you can see a few things here. So you can see some of these are always present. These are the GSM broadcast channels, right? So those are signals that are always present that your cell phone used to lock themselves on to. And some of these signals pop in and out. So GSM is TDMA, time-based. So signals are there for a short span of time and then disappear, right? So here, the refresh rate is very low because we don't want to overload the processor. It's one hertz, but the system is actually running, you know, it's doing full scanning in five milliseconds behind here. All right, so, well, GSM is a bit 90. So let's try something a bit more recent. So this is looking at 3G signals. So I'll set the frequencies to one of the 15 megahertz of bandwidth that's allocated to one of the operators. I think it's a base in this case. And you can see they have 15 megahertz to use for 3G signals. And, well, it's not always so clear, but what they did is they basically split their 15 megahertz into three bands of five megahertz, right? So you can more or less see this represented here where you have chunks of five megahertz being detected. Yeah, so sometimes the full signal is not visible. So yeah, that's basically the ID. All right, so that's about it for my talk. So I will be happy to answer any question. I just would like to also shamelessly take the opportunity to say that we are hiring some people to work on this kind of stuff. So if you guys know of someone who would be interested, well, please get in touch with me. Thank you. Yeah. I see you're scheduling a lot of oscillator changes using some time stamps. But if you also consider maybe a hardware change, we'll be using two PLLs. And actually, we'll lock the one PLL in one time and then switch to the other PLL using a red switch so that you have even more time to take in your samples and taking it easy. Yeah, so the question or the remark is whether we could do the carrier sweep by using hardware solutions instead of doing software. So there is one possibility. Now, the main idea of this is to have something very quite low weight that we can put in the back of the van. So expensive hardware, every piece of hardware you add in my experience is a potential cause of problems that you add into the loop. And it would be a solution to even speed up more the scanning that we currently have. So that would work indeed. I don't think it would make the overall system much simpler. And actually most of the issues that we have are more in terms of SNR than in terms of scanning speeds. So that's a bit of the limiting factor here. So the FFT is a fixed point multiplication. That's something that we want to improve on in the future. So you lose quite a lot of resolution in the lower bits in your FGA. So that device only has one pillar in there, right? So building something. Unless you take two. Well, that doesn't have a. No, no, but for the 200 and 210. No, it doesn't. OK. But there is a, you can purchase a more expensive device that has up to four PLLs. And then you can do exactly what you say. But I don't want to hydrate, yes. Or the 210, the hardware on that supports 30 microsecond of lock time. Like, we lose five times as fast as that on some of the hardware we have. We can have more questions. Yeah, yeah. In terms of signal to noise, are you averaging over each frequency channel before you go into the spread? Would that help? No, we don't. Oh, yeah, sorry. Are we doing any averaging before we do any processing behind? So currently not. No. So that's something that we also want to add in here. So we still have a lot of space left, whether it's on the FPGA. We can also do it on the software. But I think the first priority is increasing the resolution of FFT and then going to add additional functions such as averaging or max hold or anything that you can do that would kind of make the whole system more robust. Yeah, so this is generated with a signal generator. So we set the carrier frequency ourselves. Yeah, it's random. It's random. So the question is whether we tested this on frequency hopping transmitters. So currently not, no. So we always track signals or static. Frequency hopping is certainly something that would be interesting. It roughly depends on how long it takes to scan. So that's one of the reasons that we want reasonably fast scan times. Sorry? Is it Bluetooth that frequency hopper? Well, not the one we generate with a signal generator. One more question. Well, thank you very much.