 I cannot read the schedule. Yeah, that's problematic. Anyway, I was fixing the LTE network here at the event, so hopefully it's all working now. Now, yeah, slight little bit of background about myself. I've been working on free and open source software and open source hardware for more than 20 years now. I used to do Linux kernel work, but that's a long time ago now. And I also did a bit of enforcement of the new general public license. But during the last decade, I'm primarily involved in various projects around open source mobile communications. And as part of that work, we see lots of people who also want to play, of course, with the Osmo Comp stack or with other software that works with software-defined radio. And we see lots of problems. And I thought I'll try to make a summary talk on what the limitations are and what the problems are to make sure people don't always fall into the same traps. So, first of all, software-defined radio. Well, lots of people will associate that term primarily with certain devices that are used in the hacker and IT security and research communities. But in reality, actually, almost all radios today are software-defined radios. And that's why I'm talking about so-called general-purpose software-defined radios, where the non-general-purpose SDR devices, for example, are your mobile phones. I mean, they internally use the concept of software-defined radio, but they don't expose the capabilities of that concept to the user. To you, it doesn't matter whether it's implemented in hardware or in software or in some combination thereof. It's a black box and you cannot really modify it in any reasonable way. And most of the software-defined radio devices that are not general-purpose, such as phones or DVB receivers or, as I said, virtually any radio, performs those essential signaling processing steps in software. That's why it's called software-defined radio, but that happens inside DSP cores, typically inside FPGAs, most often with proprietary bitstream or firmware. And then on the other hand, we have the so-called, or I call them general-purpose SDR boards, where you basically have some device that doesn't do much more than the up and down conversion from radio frequency and the analog digital conversion using ADC or DAC in hardware, and then you get baseband samples into your PC or whatever general-purpose computer, typically x86 or ARM devices these days, and you do all the software processing in the general-purpose software on the general-purpose CPU without the use of DSPs or anything like that. So, having said the terminology, if we look at a number of key projects related to general-purpose and software-defined radio, well, I would start it with in 2001 when GNU Radio was founded, launched by Eric Blossom at the time with a very generous grant or donation by John Gilmore to create a software suit, which is very popular even until today, even more so today, to use general-purpose software-defined radio devices. In 2004, Matt Atos, who is here with us at the camp, launched the first USRP device, the Universal Software Radio Peripheral, and then you can see in the last 10 years or seven years or so, lots of new devices or software that enables devices has been published. Many people will have heard about RTL-SDR devices, which is basically a USB DVB dongle, which can be used to not do the actual digital video broadcast demodulation in hardware, but simply stream you samples into the PC and you can use them to receive signals. Companies like Nuand have launched Blade RF by Kickstarter. Michael Osman, very well-known in this community, launched the Hacker F1 in 2014 and for example, 2017 fairly recently, Lyme Micro has launched the Lyme SDR device, the first one in crowd supply, and so on. So we have lots of projects in that area, some proprietary, some open hardware, free software projects, and the related tools have been more available and more accessible, which is great because it means everyone can play with the technology, the very low cost devices like RTL-SDR allow you typically to only receive, whereas more higher cost devices have receive and transmit capabilities, and a lot of people from IT security or pure software or networking background have looked at SDR devices in various different ways, and the leaning curve is still rather steep, unfortunately, if you don't have any RFR electronics background, there's quite a number of free and open source projects around, whether related or unrelated to GNU radio. Unfortunately, not many of them are very easy to use and there's still many, many, many different protocol systems, technologies, radio technologies which are without any or with highly incomplete free and open source software, so that's sort of the status quo, and now we will look at actually the details of what those limitations are that I've put at the title. So, yeah, it's great that all of this is accessible, and as I said, in reality, unfortunately, some people have misconceptions about the complexity involved, and if you think, or if somebody thinks that buying a random SDR and installing some free and open source software will enable you to run a cellular base station, for example, then, well, it's unfortunately not that simple, I wish it were, but in reality it's not, and it's particularly not the case if you're interested in cellular technologies such as GSM, GPR, UMTS, LTE, 5G, GNU radio, any of that. And why is that the case? Well, there's many different topics. I'm going to start with the topic around clocks, several different topics related to clocks. The cellular standards all have very strict requirements on the precision of the carrier clock. So, if a base station is to transmit on a certain frequency, then it has to transmit on that frequency to a very high degree of accuracy. Typical requirements in this area are about 30 parts per billion, and that's unfortunately about a factor of 1,000 off the accuracy that the normal crystal oscillators or the normal crystals have that you find in inexpensive devices. So, a normal crystal may have 20 ppm parts per million, whereas the requirement actually says something like 30 or 50 parts per billion. Some devices have so-called TCXOs that's temperature compensated crystal oscillators, which then have around 280 ppb stability, which is nice. It's much closer to what the spec says, but still it's a factor of 10 or something like that off. And having a clock that's off means all kinds of strange effects. The most commonly known one is that phones may not detect your network, even though it's broadcasting or it may not reliable detect the network, or they may even drop off the network, though the last part is less likely. And this is the number one problem that we see when people play with cellular technology with SDRs. They see some unreliable behavior or they cannot make it work at all. And the number one question is, well, do you have a proper clock? And if the answer is no, then basically it's sad to say, but one can stop even trying to assist or to help at that point because there's so many problems that can follow as a result of that. So that's the accuracy of the clock. The next point is stability of the clock because calibrating the clock once to be precise, to be calibrated is nice, but then the clock's drift, that's due to temperature, to aging, all kinds of effects. And that means you would need to calibrate the clock against a proper reference quite frequently because it depends on how stable the clock is from that point of calibration to a point in the future, how quickly it drifts from that calibration point. And in receive-only use cases where you're just receiving some signal, you can basically do all that with some fancy math and post-processing. You have to track the carrier clock anyway and you have to make the window a bit wider to follow that, that's fine. But it also only works because the transmitters typically are required to be highly precise. So the receiver clock can drift, but the transmitter at least is known at a fixed frequency. But as soon as you start to transmit, particularly in the cellular area, you need this high-precision clock as precision and stability. Another aspect about clocks is phase noise, which translates into jitter in the digital domain. And it's a problem because the phase noise can distort basically any part of the signal. And in some devices, that's even a problem where there's no proper or no decent PLL loop filtering after the reference clock that you feed into a device. And then basically your sample offsets, when you sample the signal from the analog to the digital domain, it's required that your sample times are in precisely equal distant points in time, so that the digital representation of the signal actually represents the analog signal. But if your sample times are jittering around, then you get completely bogus results and all kinds of mess in your signal. So there's some devices that we have seen that are more exposed to this, such as the LIME-SDR mini, which doesn't really have an external clock input anywhere you have to solder it and change a resistor and put, I think, a UFL socket on it and so on, so it's maybe not the intended use case. Options, what kind of options do you have to fix this? Well, you can go for so-called OCXOs, that's an ovenized crystal oscillator. Ovenized means basically you put a crystal in some enclosure and you heat that to a defined temperature inside of the enclosure and you have thermal insulation to the outside of the enclosure. So the point being that if your room temperature and your environment temperature changes, the crystal inside stays at a constant or almost constant temperature and thereby you can basically avoid all the temperature-related drift of oscillators. And good OCXOs, it's sufficient to calibrate them once every six to 12 months and then you can run with stable frequencies. That's nice, but still you need to recalibrate and yeah, so an option that's relatively inexpensive that many people use is the GPS Discipline Oscillators. The GPS Discipline Oscillator basically has an oscillator that can be an OCXO or a VCTCXO, that's a Voltage Control Temperature Compensated Crystal Oscillator, which is disciplined or steered by the clock reference that is derived from the GPS signal. You can do that also with other satellite navigation systems. They're also receivers that can do it with Galileo or GLONASS or something. Well Galileo had some trouble this year, but most commonly it's the GPS DO that people use. And that's extremely stable, but of course it requires you to have permanent GPS antennas, which may be inconvenient if you don't, you're not near a window or something like that. And it also requires permanent GPS coverage and what if people are jamming it or your antenna is broken or depends on your environment and your circumstances, whether that's a choice. The more exotic choices are then Rubidium Oscillators, which are very stable, much longer stable than OCXOs. You don't need any external references. They're rather large and power-hungry devices. And you can find them relatively inexpensive secondhand on eBay or ham radio circles. But yeah, it's bulky, power-consuming, large, not really something that you would want to carry around. A fancy option are so-called chip-scale atomic clocks. They exist, but they're too expensive for most use cases, even in professional sphere. So not really something for the general hacker playing with SDR. It's also important that there are some parameters so that the reference clock must fulfill in order to be compatible with your device. The most important part is the frequency. Well, they're actually all important, but the frequency is sometimes problematic, especially if you have a zoo of different SDRs. Like I have someone to 10 megahertz reference, others one to 30.72 megahertz reference, some others one to 14 megahertz reference. I'm sure there are other reference frequencies that they want. And so you cannot just buy a single GPSDO that outputs a single frequency, but then you may need some other devices that can actually have some PLLs that can actually generate the frequency that you need from the frequency that your GPSDO generates. Another question is whether you need a sine or square wave that depends on the clock input of the device. Some can, well, typically if the device accepts a sine wave and you have a square wave, it's rather easy. You just need a low pass filter and then the sine wave is everything that remains. But if it's the other way around, then it's problematic. So if the device wants a square wave input and you only have an oscillator that provides sine wave, then you need a special device to convert from sine to square with as little jitter as possible because that, again, the jitter causes your problems. And last but not least, the voltage must match. Also, something that you have to keep in mind, almost, well, actually all SDRs that I have worked with require you to actively select the external reference frequency input. It's not sufficient to just connect it, but it needs to be selected and that selection typically is some parameter that might not be easily exposed and you might have to teach whatever application that you're using to pass this parameter down through the driver chain into the hardware so that actually the external reference is selected and used. Some devices provide the luxury of having an LED next to the input to indicate you that this is the clock input now active, but unfortunately it's not yet industry standard to do so. One important factor also to consider if you want to work with cellular technologies, almost all of them require full duplex operation. Full duplex means receive and transmit must be active at the same time, simultaneously on different frequencies. And that, yeah, well, it's sort of obvious, but it means that, for example, you cannot use the HackRF as a GSM-based station or as an LTE-based station because it's not a full duplex device. It's only capable of either receiving or transmitting. And then some people say, oh, why cannot I combine two of them? Yeah, in theory, but then we have some other requirements that we will look into later which require that both of them are synchronized to a large extent. And yes, in theory, you can do that, but I think by the time you're done with making that successful, you won't have any time to actually work with what you originally wanted to do. One other important requirement when it comes to SDRs is time-stamped commands or time-stamped transmit or receive. And that means that it's not sufficient that you can just, you know, you create some samples on your PC and you stream them out over the radio, but you actually want to precisely define at which particular point in time a given sample or which represents the start of a burst is transmitted over the radio. And vice versa, if you receive signals, it's very important to know the precise time at which a certain sample or the first sample of a block of samples has been received because that is important information. For example, in GSM and LTE, that information determines, among other things, from which phone that is actually transmitted because there is time division multiple access happening. So it's important to have this functionality. And despite the fact that many people want to play with cellular technologies in SDRs, it's unfortunately still not a standard feature when new products are introduced. So quite often when new devices come on the market, they lack this functionality so you cannot use them at all with cellular technology. And that needs support basically across the chain from the SDR hardware to the gateware or whatever runs on the FPGA that's in the device. If there is one to the firmware of the device, the host software and the driver stack everywhere, these timestamps need to be passed around back and forth in both receive and transmit side. And you also need sync between Rx and Tx, which means that you need to be able to relate the clocking of the receive and transmit samples. And you need to know that a certain moment in time represents the receive signal at the antenna input and not the receive input at your ADC. So you have your antenna input and then you have some low noise amplifiers or whatever kinds of blocks, even PCB traces, which all causes delays in the signal propagation. So you actually have a delay between when your ADC, sorry, your DAC is outputting an analog signal until it appears at the antenna interface and vice versa, a delay between when the received signal hits the antenna and until it is actually digitized by your ADC. And those delays need to be measured and you need to know them and your software needs to know about them because the software needs to compensate for those analog delays. And these values are different from every board, not every unit of a given device, but let's say if you have a USRP2 or USRP1 or a USRPB200 or a LIME-SDR, each of those boards or products has a different value that needs to be measured and which the software needs to know to compensate for this analog delay that's in the signal chain. And if you attach additional external devices, then actually that also needs to be compensated for in order to be compliant with the required specifications. And sometimes that's sort of a bit of a problem because new products try to emulate all driver interfaces. So let's say a new product comes on the market and it's compatible with the driver infrastructure that existing products had. But then of course, the compensation value or this delay value that you use is not known yet. So the value for another board is used and that of course is wrong at that point until somebody actually sits down and measures that delay and sends a patch for the software and so on. Which brings us to the topic of vendor drivers where if you're buying a general purpose SDR, what you're buying or obtaining must not be buying, but in any way you're getting not just hardware, but of course, lots of software, software that runs on your host PC, software that runs in the FPGA, in the gateway, in the controller, whether it's a microcontroller or a soft core on the device. And all that software, unfortunately, often at least initially has a quality that may be much worse than the hardware quality and then lots of vendors have their own, well actually every vendor I would say have their own different driver stack and APIs to talk to the SDRs. And the APIs often are not stable across releases. So every couple of months something breaks subtly in the APIs, which doesn't make things easier. So that means that software in general needs to support all those different drivers and follow up with all the changes that they introduce in the interfaces. It's not particularly nice. And unfortunately, there's also non-technical reasons. In this case, I think one of the well-known examples is that the UHD driver stack, which was the universal host driver or USRP host driver originally, is maintained by Atos Labs, which is now part of native instruments. And they won't merge drivers for competitors. So if somebody else produces a product, I mean, this is an open source project, UHD, right? But in the official tree, they will not merge drivers for other products from other vendors, which I think is unheard of if you look at other software projects. I mean, as I said, I have a bit of a Linux kernel background and I've never heard that somebody who is maintaining a given kernel subsystem and might be on Intel's payroll is refusing to merge drivers that are produced by AMD or made for AMD hardware. So I think it's quite a bit of a strange attitude in the context of free software here. Of course, somebody could just come around and fork it and merge all those drivers. But yeah, there are forks, but everybody has their own fork. And then you have additional layers like SoapySDR, which try to unify all these different APIs. But then the stack gets deeper and you have another layer of abstraction and the layer of abstraction might make it more difficult to control some aspects of the hardware. So yes, it's good, but it all has its positive and negative sides. And sometimes one thinks the world could be much simpler and in other areas of software development, I think there has been more standardization on common APIs and common interfaces rather than everyone rolling their own and all these compatibility issues. Another important topic is related to so-called overruns and underruns. So in the end, what you have is that when you run an SDR is the transmit side expects a continuous stream of samples to be transmitted and the receive side generates a continuous stream of samples that are received. And your entire system, hardware, software, peripherals, whatever needs to be capable of sustaining that at any time. So every time one component, whether it's a software or hardware component, is not capable of consuming or producing the samples in time, you get dropouts leading to buffer underruns, buffer overruns. You may know that from audio related work, maybe not today with today's computers, but if you've been around 10, 15, 20 years ago and you were playing with digital audio on PCs, then you may know some of those problems that you get overruns and underruns and the speed is not sufficient to keep up with the real-time requirements of such use cases. Well, that was audio with, let's say, 44 kilohertz of a sampling frequency. Now we're talking about SDR. We're talking about mega samples. So we are talking about millions of samples that need to be processed. So the requirements are much stricter and much more demanding. And all of these different devices, they all have buffers because they're not really designed for continuous streaming of transfer. And those buffers, then again, a buffer containing 100 samples means your stuff gets delayed by 100 samples. So you introduce latencies and the aggregate number of buffers you have all over your software and hardware stack determines what kind of systems you can implement because some of them may have rather strong requirements on what the maximum latency must be between receiving something and transmitting something that depends on whatever you have received before. So you cannot implement a 3G base station, for example, a real one with an SDR that's attached over USB because USB is just the latency is way too high. You can never do the timings. And even for LTE, it's actually rather amazing what projects like SRS LTE are doing that they can do this within the string and requirements of LTE despite wasting so much time of moving data over USB back and forth. One thing that can help a little bit is using real-time scheduler priorities, get RR on Linux. And you also have to pay a lot of attention to dynamic power management systems which may change your CPU speed and frequency and so on at runtime. So better disable all these things if you want to have a reliable operation with an SDR-based system. And also we see problems from biases sometimes where you know, let's say you attach an external screen and then some system management code on an X86 box tries to do something and meanwhile you're dropping millions of samples, right? Or you put your system into a docking station or you attach a power supply and then something happens in the deep down in system management mode that interrupts your normal processing and again, some samples are gone and you get overruns and underruns. Another topic to look into is the transmit gain settings because well, thinking an SDR is just an ADC and the DAC is too simplistic. Of course, you have all kinds of analog components next to it. And that's the up-down converter and you have maybe some filters or whatever and you have gain stages. So in the transmit side you convert from digital to analog and then you have different gain stages and all those gain stages you can configure normally from software. And you need to configure all those gain stages properly in a way that they operate with linear characteristics and they don't distort the signal because if you have a too high signal at the input of the next stage you will get clipping or all kinds of weird effects and that distorts the signal, introduces harmonics, introduces out-of-band interference that you then start to broadcast. And so you need to basically twiddle all these settings again for each and every SDR device that you want to support from software and basically tune all those settings manually until the signal looks best and you hit a sweet spot where the signal looks best and with some devices you may not get to the point of the signal ever looking the way how a professional measurement device for the given telecommunication system would actually expect a signal to look like. And then of course all of those settings about the gain stages, they depend on the frequency and or the band in which you operate. So you've tuned all those parameters and figured them out correctly and then you change the frequency and you start again to fiddle with all those buttons in order to get all of them set up properly. Which brings us to other things on the transmit side which is the power level. So a normal general purpose SDR device typically outputs only what's zero DBM, maybe four DBM, 10 DBM, that's very little power which is good if you just do lab testing on a desk but if you actually want to do real operation then of course you need some kind of amplification. Simply needs to be amplified. So while you go on eBay and you find lots of inexpensive power amplifiers for the band that you're looking at and so why is that not a good idea? Well the output signal of the SDR already contains normally quite a significant amount of harmonics that's basically twice, thrice, four times and so on the frequency of that you're transmitting and if you just put an amplifier behind that the amplifier will transmit, will amplify also all those harmonics. So you normally want to put proper filtering before and if necessary also after the amplifier so you then have your SDR and already three additional blocks on your desk and the clock and so on. And then actually it's more complicated than that because an amplifier is not in general a linear part meaning it does not amplify any signal the same way like another signal or part of your signal. And then particularly the more affordable amplifiers are not so linear and they're trade offs between power consumption and linearity so you can build highly linear amplifiers that consumes tons of power or which then means you need to cool them and so on or you can have less linear amplifiers and particularly signals that have a high peak average peak to average power ratio that means they change the amplitude while transmitting get distorted a lot by non-linearities in the amplifier and if you look at commercial base stations that actually implement all these systems you have what's called digital adaptive pre-distortion to compensate for the non-linearities. So basically you output a signal you put it in your amplifier and then you digitize that again from the analog into the digital domain you measure what's the difference between my intended signal and the actual signal at the output of the amplifier and then you do all kinds of math to pre-distort your actual digital signal before you convert to analog and feed it into the amplifier and you do that as a continuous loop because all of that of course depends on temperature and aging and all kinds of other nice effects. And I've heard, I mean I'm not involved in those kind of projects but I've heard several times that at least a couple of years ago several times that the pre-distortion actually is more computationally complex than the system that they implement in the first place. So there's a lot of math that goes into this pre-distortion in order to have proper signal at the end of the amplifier. So yes you can use an amplifier for very simple waveforms for constant envelope things like GSM for example but if you wanted to LTE or something like that you need a very linear amplifier. Yeah, then the next topic is that the level somehow normally should be calibrated because well an SDR doesn't give you a defined output, right? You have your analog digital converter and you can output from let's say zero to whatever 4096 if it's a 12-bit DAC and that's your basically your scale but you don't really know to what that corresponds in terms of an absolute output power at the end of your board on a socket. And then again if you change the frequency your output level will be different. So basically on the digital domain you do everything the same but then you change the frequency and your output power level changes because again there are non-linearities in all these parts and unlike base station hardware or other professional radio hardware that's purpose built for a certain purpose the general purpose SDR boards are not calibrated or don't come with calibration tables. The vendors could do that but it's a lot of effort to calibrate those units and ship calibration tables so they don't. So you don't have any absolute value and the absence of known absolute values means you don't actually know how much you transmit at any given point in time which means that you create problems if you really want to operate let's say a cellular network with that because if you don't know how much how strong you transmit you may create interference you cannot really do proper network planning and so on. And I have to catch up a bit in terms of time. So on the receive side we also have harmonics not just on the transmit side and that basically means well your SDR fronted is an open mixer and let's say you want to receive 900 megahertz but it unintentionally will also receive 1800 megahertz because that's you know twice the amount and that's the first harmonic. So you need to put filtering on the analog side otherwise you will receive all kinds of things that you don't want to receive so you need an analog band filter between the antenna and your RX input and ideally that band filter should only cover the band of interest and should filter out everything else outside of the band. Next topic which is related to that is the dynamic range on the receive side because again your SDR front end is a wide open receiver and any energy that is present at the input of the receiver whether it's near or far will pass at least to the first stage LNA that's the first amplifier in the receive chain and then may propagate even to the mixer input depending on the detailed layout of the device or the chip and then possibly even further down to the ADC and any energy that is outside the signal that you're interested in is just going to create a problem for you particularly if it's a strong signal because a strong signal means that it might clip and clipping means distortion and distortions means you won't receive anything useful and in the end then basically your all the entire receive gain chain must be tuned to accommodate the highest signal that you receive the strongest signal you receive even if it's a signal you're completely not interested in let's say you want to receive GSM but there's an FM station nearby an FM transmitter you might have that FM signal in there unless you have filtering before your SGL device at the input otherwise that might saturate your LNA and basically you lose all the sensitivity and all the dynamic range and then also on the receive side you want to know absolute power levels in cellular systems they're specified to use receivers that are calibrated that tell you exactly well exactly roughly plus minus 2 dB is actually a very large tolerance it's not a measurement device right meaning that a received signal receives with a certain value and that receive signal level in turn will be input to power control loops which tells the phone how much to increase or decrease the transmit strength to be received at the proper level but if you receive level it's not calibrated and it's just some random guess or some arbitrary value that's not calibrated to anything like such and such amount of dBs of full scale but yeah how do I convert it to an absolute value you cannot unless you calibrate the device so again you have trouble there which brings me to the end so I'm sorry to rant about so many topics I'm not saying that people should not play with SDR to the contrary it's very exciting technology and everybody should be working with SDRs but you have to understand the limitations of the system you're working with if you want to have proper results and it's not as easy as just getting a general purpose SDR device from whatever vendor and then playing with software if you don't have other accessories like let's say a proper clock source or a spectrum analyzer to actually look at what you're outputting or some other tools and like filters and so on LONOS amplifiers maybe power amplifiers antennas, splitters, attenuators so it's much more likely that you will end up collecting an entire zoo of devices and accessories so the SDR board may be the start but it's unlikely to be the end of working with SDR devices so be prepared that there is other things that you may need to obtain beyond the SDR board and as I said it's important to understand those limitations and to make sure that at least the most common error sources are excluded before trying to debug systems that have seven more layers of stack on top of them and something doesn't work and you have no idea what's actually the cause if your layer zero is not even behaving properly so yeah that was basically what I wanted to present I hope it wasn't too boring and I hope there will be some questions or challenges or contradicting statements or whatever else so thank you I'm very impressed do we have any questions from the audience hang on I'm gonna do this again here we are remember one sentence no comments just a question so I assume that the cellular phones don't have very accurate clocks so if the transmitter basically why does the transmitter need an accurate clock if the receiver doesn't because if the transmitter is off wouldn't that be equivalent to the receiver being off so in short the transmitter must be accurate so that the phones don't have to be accurate because the phones calibrate the receiver or the calibrate their internal clock to a reference signal that is specifically crafted in the transmitted waveform from the base station so they can calibrate their clock to what the transmitter is sending now you may or may or may not know that but now the problem is yeah well part of your question why is it then important that the transmitter is accurate well the problem is the transmitter is not the only transmitter on the on in your coverage area normally it's transmitting so you have multiple of them and the phone clocks it's internal or calibrates its internal clock against the first signal it sees and that for example means if you have a base station on your lab desk which has a wrong clock but you have a real network with a proper clock like a commercial network around you switch your phone on it sees the by coincidence or by whatever it sees the commercial network first it locks it's it calibrates its internal clock to something derived from the commercial network and then it will no longer see any other transmitter that doesn't have an accurate clock and then they have exactly that effect you operate everything the signal is there you may even see it in a spectrum analyzer but your phones don't even see list the network because it's not at a frequency that they can understand I have a question about computational power asking because I don't know are you aware of the Pluto SDR little cheap device with a zinc processor if you get the clock figured out the analog chain in front of it do you think it would be computationally feasible to do LTE with such a device or is that way off? Well the clock I just heard I always complained about the Pluto SDR not having an external clock input but I just heard like 10 minutes before this talk that it's actually one that just didn't expose it on the socket so if you open it there is like a socket or something where you can put a reference clock into several reasons why right now you cannot do LTE with the Pluto SDR and the prime well I would say personally the first reason why it doesn't work is because the entire driver infrastructure that this device uses does not do any form of time stamping neither on TEX or RX so I think it's primarily a bad choice of software architecture that constrains it in that way I mean there may be other restrictions but that alone is the reason but I think it can be fixed Is there a question wait a minute you'll be right there is there a question from the internet do we have a question from the internet? I'm sorry but no No, okay your question please just one sentence no comment Well it's very difficult to not comment very good good talk thank you very complete as well and also very dense information but what I did miss group delay a few things antennas and VSWR yeah that's correct I mean for sure it can be expanded in other topics thanks for that maybe we can do a workshop or something on those topics if somebody's interested so which steps would be required to build a full duplex capable SDR of two radio batches to be honest I cannot respond immediately I would have to check the schematics again I think at the very least I mean you would have to start of clocking them of the same reference and then yeah well yeah I don't want to try to make an answer without looking at the facts but I think I mean people have shown that things like this can be done as a proof of concept but yeah it's it's a lot of effort and a lot of hackery and yeah I mean you can just use a proper device instead rather than spending a lot of time solving a problem that other people have already solved but yeah that's my opinion hi Arl do you have any recommendation on where to find the filters because I remember I searched on ebay but they are rather rare or expensive any recommendation it depends a bit on what kind of bands if you work with cellular bands most often you can actually find the filters that are used in the phones themselves they are surface acoustic wave filters saw filters and you can typically find them on ebay and other component distributors the problem is they come in such small packages that you need rather how can I say good SMD soldering skills and then also sometimes the problem is that they might not have 50 ohm matching but some you know 100 ohm symmetric or something like that so some balloon or some whatever might be needed to use it in a 50 ohm system and for the transmit side if you have real power then the only real option at the frequencies in the cellular domain is to use cavity filters or cavity duplexers and yeah there are some sources but I don't want to make advertisements here in this talk can contact me privately two more questions please two more only one question one sentence yeah so first thank you for the great introduction so from experience I know that rubidium clocks have terrible face jitter did you ever try rubidium clocks and if you did so what did you do to clean them up to be honest I don't use a rubidium clock I bought one once because it was so cheap but I never really used it so far so yeah I have a GPS discipline I have an OCXO that's this GPS discipline so it can run for quite some time even without a lock and that's what I use in my setup and I have some 10 megahertz distribution in my lab via coaxial wire so that I can attach devices to the reference at different locations different desks okay thank you for a good talk you said calibration of the boards is a hard problem are there good enough sets for each kind of board that we have and if not is it maybe a business opportunity to help people calibrate their SDRs okay so the question is about what kind of calibration are we talking is it the receive and transmit signal strengths I don't really know what the whether it would be sufficient to create let's say one set of default calibration and then assume that more or less most of the products are in in the same range I don't know what the spread is for those SDRs I think only the excuse me only the manufacturers would know if they ever checked about what the spread is I think I wouldn't think if in terms of business opportunity but I think there's a large opportunity for an open source project that can help many SDR users is to basically design software and describe a hardware setup using which you can do all these calibrations in a fairly automated way with any SDR virtually as the device under test and then that could be something that hackerspaces for example could operate to help other people calibrate their devices thank you okay one last question if you had one no okay that is thank you thank you very much Jordy