 Alright, I'm done here. Everybody clap for Bolin. Should I? No, no. I don't suppose Anders is here again. I like to call him out every time, every DEF CON. Now Anders very kindly lent me his pre-paid cellular phone when he was visiting from overseas a couple of DEF CONs ago. We had word that I think we needed to switch on one of the science instruments on that space probe and I was here and so I headed to his phone and then SSH'ed into a laptop. We left it at the Arrasiba Radiate Holoscope and they powered it up and then using some software that we wrote we sent the command while I was watching the talk because the talk was pretty good too so I didn't want to leave that. But anyway, today thank you very much for coming and watching. I hope this is going to be informative and you'll be able to learn some tips and tricks from this. I just want to talk about some suggestions I might have and I'm going to be biased because it's just using some tools that I've been working on for quite some time. But how to basically use some tools to get good captures, IQ captures in a manner that you can use to make sure that you record sufficient metadata under certain circumstances if you're doing lots of captures. And then once you have all that IQ, some tools that you can use to actually review it and see whether signals that you're looking for or anything interesting may actually be in those captures. So capture and analyze like a boss and I just want to do a shout out to Nate and there's Nate, Nate Temple Dev-Knowing. Stick your hands up Nate. That's boss number one. Where's boss number two? Where's Neil? Neil Pandy or where are you? There he is. Hand out there, there's boss number two. They've been very helpful with all my efforts. Thank you guys. So anyway, the first one is, let me just get these slides up here. There we go. Who's heard of Kitchen Sink? That's great. Then I have something to teach you. Kitchen Sink is I'm probably the only one that uses it in the entire world now but it also might be a little bit daunting because it has three pages of command line options. So it's highly flexible but Kitchen Sink is a tool that I originally wrote when I was at its research and I've been sort of extending a little bit its open source so I forked the repo and I've been adding features to it. It's basically a Swiss Army knife for capturing and in this particular case also testing some of the more advanced features of USRP. So I've got one plugged in here and the thing about this is that I haven't tested it with Kitchen Sink but if you wanted to use this with other hardware like an RTL or any other SDR you can imagine, what you can do actually is either modify the source code to use another API or Josh Bloom made SOPE SDR who's heard of SOPE SDR? Yeah a couple of you. So SOPE SDR is supposed to be a totally vendor neutral API that allows you to access a whole lot of different types of software defined radio hardware. It has been very comprehensive. It has a very very wide support for hardware. I highly recommend you check it out. It's also a really slick API but one of the things he added to SOPE was the ability to have SOPE talk to usurps through SOPE but then also he made a loadable module for UHD to access SOPE devices. So you can install SOPE SDR and any application that uses UHD will then hook into SOPE and then you have every other SDR available to use as well. So if you wanted to use Kitchen Sink with something else, install SOPE, install the UHD module and then you can access whatever you want. So Kitchen Sink is a command line utility. It's a single C++ file that you can compile and you basically can tell it to do all sorts of things. I've mainly been using it to do captures. So the command line ends up getting pretty long if you need to do more advanced stuff but let's break it down. So here's an example. You just run Kitchen Sink. You tell it how many RX channels you want to capture on. If your SDR supports one then obviously it's just going to be a single channel but if you're using an SDR that does multiple channels like a B210 or what have you then you can have it capture both channels at the same time. You tell it how fast you want it to capture the sample rate, RX rate. Progress interval is not, and I'll show you this in a demo in a minute. Progress interval is nice because you can either have it just sit there silently doing its thing or every second or however long you want it'll print out the time stamp and how many samples is captured and so on. That can be good for testing. Interestingly enough I've found that if you're really pushing the limits of capture these things operate over USB3 nowadays and you can do 56 megahertz worth of usable bandwidth you can stream that to RAM disk. You can create a RAM disk on OSX or your Mac or whatever you want and then stream it directly into RAM and then you can support that capture rate which is great if you want to do really high bandwidth captures. But I found interestingly that depending upon your system configuration if you end up having the program print out the progress interval however long there's maybe a system call that happens or there's a little bit of overhead there and sometimes you can drop a sample if you're really at the limit. So sometimes you want to have that off. Obviously then you set the frequency that you want to capture at the antenna and then I'll talk about this in a minute but the CPU format that you want the samples in, the gain, the capture file and then comes the cool stuff which is about time synchronization so I found myself recently needing to do captures at specific times for a specific length and it has some options depending upon your timing setup with your SDR about when you want to start because if you're going to RAM disk or you only have limited drive space and you're capturing a whole bunch of things simultaneously you don't necessarily want to supervise it and let it go on forever. Another thing that I'll talk about is the timing file which is important. So who's done captures where you've ended up dropping samples? You try and capture a bunch of data and then your SDR is producing samples quicker than what your computer can record to disk. This doesn't happen obviously when you're doing quite narrow captures, slower rates but if you're doing really fast stuff like 50 mega samples per second you can overflow very quickly. So what the timing file does is it actually stores in a sidecar file the hardware time stamp and the number of samples that have been received so that if you do in fact have any overflows you can go back and just a CSV file and see the time at which the next sample came in after you had a discontinuity which means that if you need to you can actually recreate a continuous stream because often what happens is when you take your capture and then you put it into some decoder if you're tracking a digital signal then if you have a discontinuity it might screw up your clock recovery. Your decoder will lose lock on your signal and then you won't know what happened because it's assuming that the sample stream is continuous. You haven't dropped anything. There's something else that I'll show you that will take in that timing file and then pad the missing data and then whatever is consuming this won't have any problems. Another thing for example is you can add an RX start time down the bottom. So if you have the ability to set the time, if you have the ability to set the time in your device like on this one you can actually tell it that the time is now this or I'll show you how else you can synchronize time but then you can actually say I want you to start streaming it at this time. I'll come back to that in a minute and explain why that's important. But if you're doing multi-channel stuff this can be part of a MIMO experiment or if you've got two different antennas pointing in two different directions and you want to capture at the same time or you want to look at two different frequencies but make sure that you record in a time-aligned manner then you can actually tell it to do multiple channels so you can give it a list of frequencies and a list of gains and what's nice is that you can use this formatting option in the RX file so that instead of just spitting out one IQ file it'll spit out two. Or if you wanted one but you want interleave samples you can tell it to do that as well depending upon whatever is consuming this would require. And then some tips if anybody is using say a B210 if you want to decrease the chance of overflows you can increase the num receive frames in your UHD arguments just another thing that you add to the command line options and people try different values and talk about different values but I found that actually depends upon the hardware you're using and the controller and what have you. So you need to use and experiment with some different values there because some will just crash the app some will crash the controller you'll get corrupt data so it's always good to experiment with those values. And then there are other ones that if you have a device like this it has an A side and a B side so if you want to use the B side instead of the A side you can set that as well. And then important thing about the CPU format when you capture IQ samples they're usually in one of two standard formats floating point or fixed point. And floating point is usually FC32 or CF32 in soapy land and then you got SC16 so you got pairs of 16 bit short samples or pairs of floats and obviously if you have pairs of floats they're going to be twice the amount of data than two fixed point short values so if you're trying to fill up your RAM disk at 50 mega samples per second obviously you want more bang for your buck so you can tell it to use the short samples. And what's interesting is that commonly when you actually stream from a device it actually ends up coming off the FPGA in a fixed point format anyway so there's no point in having the host convert it to a floating point format which is good when you're using it in various applications but if you're just trying to store it you can get twice as much in there. And the other feature that I added recently was this rx file loop size and that's important where you have a finite amount of storage let's say RAM disk let's say you've got 32 gigs there you leave like 500 megabytes to your OS and if you want the system to just keep capturing and then you stop it when you want to once you've seen some other external event occur maybe you're looking at another monitor or maybe you're listening for something or looking at something then and you manually stop the capture it means that it will store the last 31.5 gigabytes worth of data so in this case it'll just keep basically recording into a circular buffer in RAM and if you specify the loop size it'll tell you how big you want that circular buffer to be and then when you do that it'll create a dot loop file as well which is another sidecar file that will store the file cursor and the sample count every time it loops and then at the end so that once you end up with your final capture file if you think in terms of a circular buffer the beginning of the file will be somewhere the beginning of your last 31.5 gigs is not at the beginning of the file it's somewhere inside the file so it stores the offset there and then you can loop that through to recover your continuous recording so what's cool is once you do these big recordings you can capture a lot of data this is a waterfall here captured around I think 437 megahertz and you can see there are a lot of different signals in there and it's a very large bandwidth so lots to see and explore but the thing is if you want to actually go in and analyze these signals there's a lot of them and so it'd be nice to have some tools to sort of zoom in and look around and look a little bit closer so I'll show you some interactive stuff in just a second this is an example where you can zoom in with this little tool called BazFFT it can read in IQ and it'll plot it you can have a text file that lists frequencies and you can give it names and then there's this different app that uses GNU Ready called the multi-channel runner that I'll show you and that will take in this massive IQ on all these frequencies that you specify and then extract the various channels and then decode them in whatever way you wish and then it'll take that metadata out and then overlay it back on your waterfall so you can see these are transmissions and it's got those dotted lines around the transmissions to indicate that's when the squelch opened. If you're dealing with P25 transmissions then you can do a big capture, analyze it put it through the multi-channel P25 decoder and then who's familiar with the different frame types in P25 where you've got your header data unit and the tail and the two voice packets so when you transmit P25 there are different frame types that transmits, there's a header and then when it's transmitting voice traffic it actually alternates between these two voice packets, voice frames and as you can see there you can identify voice traffic by the cyan and darker blue alternating rectangles if you look at each of these channels in the waterfall so I'll show you that in a sec too but it's basically the OP25 decoder with the modification to spit out the timestamp at which each of these frame types are decoded in each channel so let's take a quick look at that I wonder whether I can, where did that here it is, so I'll do some command line demos of kitchen sink in just a second but these are just some captures that I did with it and not working okay here we go so let's have a look at the whole capture so when you run the program it looks like like this so sorry it's difficult for me to see you run the program you give it your capture file, you give it a frequency list and then you give it the event list which basically contains the output from once you've run it through the multi-channel decoder and then it shows you all of the channels that you've put into your text file it's just a list of frequencies and then it'll draw the lines to show the channels and then once it's gone through and analyzed all those channels then you can just zoom in and you can see that you have the IQ that's been represented in the waterfall and you can see the energy there, the red there but then because it's gone through a narrow band FM decoder and with a squelch in front of it it's identified with that white line around it saying oh I actually found something here and when it does that then it actually demodulates using narrow band FM makes a wave file and then you end up with all these wave files here so you can click on it there in your OS and listen to them or you can also just double click them in the waterfall like this and then it'll play it back so anything that you like to you know that's of interest to you you can just click the button here click it inside the area of any of these signals that it's found and then review it so that can be quite a powerful tool if you're sort of hunting around searching for a signal that's a trunk in control channel there or maybe that's tetra so this is kind of nice because you can record you know very very wide band with captures and then run it through this multi-channel processor it takes a little bit of a while to you know process all the channels per your channel frequency list but once it does that then it'll spit everything out and then you can use that tool to analyze it and then let's see here so you can also do the P25 and similarly I won't show you the actual interactive view but with that you can also have it output let me find a good example here also have it output just static images if you want to render it to an image file like a PNG so this is the same example instead of you know being in that interactive mode spits it out to a picture and you can zoom right in and again we can see those individual transmissions with the data individual data frames color coded there so in a way there's also good diagnostic tool to determine how well your decoder is actually working so this is found voice traffic here and then on the side this um these series of pink blocks are actually trunking control blocks on the trunking control channel that's used to coordinate traffic on this particular network so you can see all the individual P25 packets and then if this was an interactive mode um if you ran it through the multi-channel decoder with P25 then you would get out all the P25 traffic so just as an example of what that looks like here um I've talked about this in the past but I had this notion of the multi-channel decoder block in Guru radio and the way that works and I should say that it's not optimal because you can use polyphase filtering and all sorts of advanced DSP techniques to split off multiple channels in an efficient manner and pass them through some decoder but in this case fundamentally you just give it a list of frequencies and you have a template flow graph and it instantiates a bunch of those flow graphs and links the original uh capture file into each of them at the frequency so they all just operate in parallel so the way it works is that you make these templates and in this flow graph this is the P25 channel template and you have a an input here which gets linked up to the original file at a particular channel offset and then it goes through a bunch of blocks um squelch and what have you but the import one's down here in the bottom right where it um can't quite read what's going on there I think this is I'm not sharing my screen so I can't can't see uh the baseband signal gets pumped through the OP25 decoder just down the bottom here uh and then it produces um the symbol stream for the channel and that goes into the audio decoder the first port here outputs the decoded audio which will then get put into a wave file and in addition uh it also outputs messages oops I didn't want to delete that it also outputs messages uh they get output from this instance and then aggregated in the uh in the controller class in the parent class and that all gets output to a file so every single time the decoder sees a new frame in a transmission it'll output what that frame is and the time to produce an event list and that's the event list that gets pulled in um and you know rendered out in this tool that I was telling you so this one is the conventional FM version so if we were to not look at the OP25 one but look at just the narrow band FM one then similarly um this outputs uh the FM demodulated audio down the bottom here but also you get this message from the power squelch coming out that the time stamp of when the squelch opened and closed gets logged into a central file for all of the channels and then you know the script is able to uh know that in actually there was a transmission here and then it it it indicates that with the with the box so you can click on that again and then you know listen to whatever transmission is going on there so it's a good way to review this sort of stuff offline and by the way if anybody's got any questions then please please ask um so let's talk a little bit about time synchronization this is important where you're trying to capture things um either at the same location but using different devices or capture things at different locations at the same time um or capture things in a very precise manner where the signal that you're capturing is also synchronized and you want to be perfectly locked to it so usually you know when you when you do your average old capture you just say right give me samples now and I'm going to store them to a file but sometimes you need to make sure that for example the time that you end up setting in your device is accurate and in the same time domain as say GPS or some golden difference time so you could have as an example on this board there's a GPS do so you plug in a GPS antenna this GPS do would synchronize to the GPS constellation and then give you a very accurate time base for this um radio you can have other radios where you have a house sync where 10 megahertz and one pps is distributed through some um location and you just plug it in there and then you get your time uh information so time this time information is usually uh split up into two elements one is pulse per second and the other one is a 10 megahertz reference clock reference frequency uh the pps is important because it demarcates exactly when a new second starts so commonly with the GPS receiver you might see a little light blinking who's seen a light blinking on a GPS receiver before that light blinking indicates the precise time when a new second has started and then the other element is this 10 megahertz sign where 10 megahertz is just a commonly used de facto frequency and it basically gives you the clock reference for how quickly time should be advancing so commonly the way it works is with a sdr you give it both signals and you say on the next pps edge the time is going to be you know however many seconds pass the epoch and then when the software defined radio sees that pulse it latches that time and makes it active so just it sits there waiting for the pulse and then as soon as it comes it knows this is the precise time at that instant but then that only usually happens at the beginning before you start capturing so what happens after it sets the time and then gets going well these sdrs have their own internal oscillator right they have their own internal clock and they're all slightly different if you're talking about very very large uh bandwidth captures or high bandwidth signals you will very quickly start to see a difference in the timing of the signal that you captured and what the actual transmitter is using and commonly that's why you need to use clock recovery mechanisms in a decoder because your oscillator in here will not be synchronized to the oscillator at the transmitter and so clock recovery will take into account these slight frequency differences that are produced by manufacturing differences in the crystal so when you buy crystals they actually come with a tolerance that tell you oh it's you know this frequency plus or minus whatever ppm parts per million and you can then calculate out at a particular frequency how far off that frequency you might be within the tolerance of the crystal however if you use an external reference like 10 megahertz and plug that in and share that amongst devices you can use that 10 megahertz to discipline the oscillator on the sdr so the way that works on this for example is you feed the 10 megahertz in to a special chip and that 10 megahertz will then be used to discipline and synchronize the whatever oscillator or hardware clock is running on here so it's basically saying this is the reference this is how fast 10 megahertz is really going you need to sort of tune and discipline your internal oscillator on there and sync with it and once you feed it this 10 megahertz you can then you know capture or and capture any rate to any frequency and that will be precise with respect to this reference so then going back when you get the pps you set the time at that point and latch it and then once you've got the 10 megahertz then from that point on your radio will be capturing at exactly the rate that you want so let's keep it easy and say we want to capture the rate of 10 mega samples per second every second we expect to get 10 million iq units per second once we have the 10 megahertz discipline that we'll get exactly that and then we don't need to worry about anything else and we'll be perfectly synchronized so let's say we have a couple of these at different locations with gpsdo's they can all be synced up with a gps antenna they all listen to the satellite constellation and if we need them to start recording at precisely the same time which helps to use the gpsdo which produces a pps and 10 megahertz and then they can all be locked on and running at the same rate and this is also important because a lot of systems out there that actually transmit use gps as a means to provide an accurate reference so who can name some of them give me some examples fm broadcasts, lte, digital tv they all use gps as a reference if you look at a cell tower you can usually see sort of a white upward it's called bullet shape gps antenna and that basically sits there and provides a very hopefully stable and accurate reference and I won't go down the rabbit hole but it's really interesting if you consider how potentially vulnerable systems are if you're able to somehow spoof or disable gps because once you do that in those cases you don't care about position it's purely used for time and they're all advanced systems are able to detect that and warn against that but still it's kind of a problem when you have that as a reference yes no no please ask questions don't be afraid so that's a very good question what's providing a 10 megahertz reference so with this gpsdo actually there is a 10 megahertz oscillator on the gpsdo which is much higher quality than the one whatever reference is originally on the board the gps is providing both 10 mega and pps so you know if you're not using gps but you're using a house sync you know just as an example when we were at arasibo we needed to have very accurate time information on when we recorded everything so there they had a I think it was a hydrogen mazer clock that was very accurate and local on-site and it provided pps and 10 megahertz but they had that routed through the entire facility so you could just go anywhere plug your 10 megahertz and pps into the wall and you would get super accurate time and that's what we did with the gps there and what it meant was when you set the time and I'll show you that in kitchen sink in a minute when the samples come back from the sdr each sample then you can calculate the precise time at which the you know sample entered the antenna port if you I mean there's a bit of latency there through the hardware but ignoring that you know very accurately when your samples were recorded question so the question is how does the coax effect sample delay and what have you it does affect it so if you're using multiple channels in a system you need to make sure that your coax is all the same length you know these signals travel at a finite propagation rate through that kind of medium so if you need that kind of accuracy you need to measure it off but also you need to consider you know the bandwidth of your signal and that sort of thing maybe it doesn't matter too much it depends upon you know how precise you need to be in the overall characteristics of the system any other questions I'm glad that there have been some keeping coming if something's not clear then you know let's keep it interactive and I can try and clean it up for you so just to demonstrate this a while back I wrote this script called ppsdiff and what it does is it sets the pps and sets the reference information on the SDR and then it checks whether the samples that you're getting are actually at a rate that you expect so let me demonstrate that to you here so if you look I'm going to can everybody read that is that alright so what I'm doing is I'm starting up this ppsdiff and I'm telling it to use the gpsdo so this only works if you have a reference that it can lock to and a pps that it can detect if it can't detect the pps it'll say you know there's something wrong with your pps so it's a good way to diagnose if everything's connected properly and the way it does that is it basically UHD has an API where you can say get the time the last time you saw a pps edge and it just keeps asking for it and if more than a second has elapsed or you know you can configure it more than two seconds or whatever I can't remember has elapsed on the host if it hasn't seen two different times at the last pps then obviously it's not getting pps so you can use that to diagnose what's going on so it looks for that it checks it asks the SDR the usurp whether the PLL that I was telling you about on there has actually locked to the 10 mega hertz that you're providing it because sometimes if you give it a two week signal it won't lock and then you might think it might be capturing and locked to your external reference but it won't be so it's always important to check that it's locked and once it's got a pps and it's locked then it starts printing this out every second and what I want you to look at here is on the very right hand side it says tix diff so tix is another way of thinking about samples I think here the default sample rate is 16 mega hertz and so what you expect is if you have a precisely tuned 10 mega reference coming in and the usurp synchronized to it every second we expect exactly 16 million samples to have come out of the usurp every second so this is happening at you know printing out every second and it's detecting when the pps edge comes and then I think it uses that to calculate stuff and then print this out but it's basically saying from the time at the last pps to the next one count the number of samples and then you can check that it's correct so watch what happens now when I trick it by saying I want to use the 10 mega hertz reference is now going to be the internal clock so don't use the 10 mega coming out of the gps but use the pps coming out of the gps just to trick it and then we don't care about the lock so if I run that then the pps is still coming out of the gps right at its own you know more correct rate because it's high quality even though we're not synchronized in gps here the pps and 10 mega still running and you can see now that the tix diff is not quite 16 million it's a little bit less because the oscillator on the sdr is not being disciplined by the same source as what's in the gps that's providing the pps so you can see how there you can get a slightly different capture rate and if you need very very precise timing in your captures that's obviously a problem and then you need to work out why that's happening so in practice if everything's wide up and working correctly we would see 16 million all the time and then this also can be used to dump out some additional timing stats and what have you so that's pps diff handy little tool there now what about the timing file the timing file is important because say if you want to record something and you need to know when the samples are coming in relative to real time kitchen sink can output this timing file and you can go back and say oh you know it was exactly you know 3 33 p.m. and 6 seconds and microseconds and nanoseconds all the way down so you can very very precisely identify the point at which you're looking at in a capture file the obvious way to do that ignoring all this is you just you know note the time on the wall clock on the computer when you started recording but there's going to be some latency between what the wall clock on the computer is and what you know when the samples actually arrive there because you've got the bus latency you know network USB what have you and other factors so if you're willing to live with that that's fine but if you need very very accurate timing then you know you need to have these references there as I said you can use this to synchronize captures across frequencies across devices across locations now once you have actually recorded your IQ and you have a timing file then in GRBAS I added this block which is the BAS file source and it lets you open up an IQ file as you did before but it also lets you tell it about timing information as kitchen sync wrote it to that timing file and that's important because you can either have well it will output time tags if you're familiar with GNU radio you can send metadata along with your samples so when the time takes a jump or start streaming you know if there's an overflow it jumps it'll produce time tags and send them along with your sample stream there is already a block that does this I think it's the metafile sync and metafile source and that works really nicely but they have a bit of an odd file format that it saves everything in and this is just nice and simple you know line delimited common delimited text file and the other nice thing is that it can automatically load a whole sequence of files so for example who's using SDR here or yeah a couple of you so HDSDR is a Windows based application makes it very simple to use your SDR and receive signals and look at a waterfall and demode you know AMFM single sideband when you hit record there it actually splits files every you know 4 gigs if you recall with that 32 you can't store more than 4 gigs in a file so it'll automatically split them and if you end up using that to record data for a very very long time you'll end up with a lot of files and if you want to process them all as one big batch in GNU radio then it's going to be pain to have to run your flow graph load up the next file run it again and so on so with this this will automatically detect a sequence and then load them all at the same time so you just basically treat all of your split files as one big one if you need to seek around in there you know this has a python API as you can call and it will load the right file and seek to the right point in that file I'll show you that in a minute and it could automatically get the sample rate out of the file depending upon if it's in the timing file or if it's a wave file and the header and so on so it's nice if you've got stuff downstream of that and I'll show you that as well now regarding the overflows remember I was telling you that an overflow is a discontinuity you have lots of continuous samples your computer can't write to disk fast enough it'll drop some samples and then it'll start going again so with the timing file you know the time at which it started streaming again continuously but with this block you can change the pad mode so you can turn padding to on and it'll actually produce filler samples zero samples to pad out all those missing blocks so if you've got something downstream that's assuming that your sample stream is continuous without any discontinuity this can fill those holes so I showed you some of the things that Baz FFT can do it'll produce a nice waterfall it'll annotate it with events that are produced by decoder it'll draw lines through the frequencies that you're interested in but now I want to show you the interactive playback mode and that'll round out the talk I think the interactive playback mode is a system where you can load up a bunch of capture files it'll load them all automatically and then you can interactively review do I have it loaded already no I do you can interactively review everything in the file so I'm just going to start it again one thing there are some more features to this that I won't discuss now but Baz FFT has another feature I showed you where instead of just going to a matplotlib window you can have it dumped to a PDF or to a PNG it also has one where it'll compute all the FFT data because when you run it by default it needs to go through read all the IQ, compute the FFTs, average them etc if you don't want to do that every time because you're dealing with tens or hundreds of gigabytes worth of data you can have it compute it and then store the result to a separate file which is like a cache version of all of the FFT data and that's usually much smaller and much much faster to load if you need to reload it later so I have this HDSDR file just to illustrate what I'm talking about I'm going to copy that so I don't lose it and then you'll see here I have to wait for my drive to spin up maybe hello there we go so there are a lot of capture files here right so these were recorded with HDSDR they've been split at whatever the split I think it might have been two gigs actually and there are a lot of files so you don't want to have to open all of these up individually it'll automatically load them you don't want to have to recompute the FFT every time you want to view something so it'll do all that and then store it as this intermediate file so if we load that up it will open that up and then you see here I've also added this XML address this is going to use XMLRPC to talk to a GNU radio flow graph and then we can interactively that's just being read from my hard drive if you do this make sure you use SSD because using mechanical drives is much much slower so as you can see here that's actually a list of all of the original files that we use to build this composite there are a whole list of them that were automatically detected in sequence when I ran it before now it's rendering the plot out here we go so if you can see there you've got these horizontal lines that run across the screen at regular intervals that demarcates which capture file was used at that particular point and if you look over on the left hand side you can actually see each of the capture files that were loaded to produce some data and then when you ran out of data in that file it moved on to the next one and then again we have a lot of signals in here so you can zoom into them and look around in this case I didn't run it through the multi-channel decoder that I was describing before so it hasn't gone through I haven't given it the frequencies to look at and decode and separate but now we can do that interactively and I'm going to run not that one I'm going to run this so this is the playback and what I do is I just give it the first file and that's the file that gets given to that GRBAS file source block and then the file source block will automatically load everything else so when I run it if you watch you'll see it load the first one and then load each of the other ones in succession and this is just unautomatically because the metadata in the HDSDR file has a war clock time stamp of when it ends so it looks if there's a file in existence that would match the time stamp that it should continue at so let's see what happens and now you'll have to pardon the breaking in the audio because it's a very very high bandwidth file and it's reading off my mechanical drive it's slow but it's also going to the disk cache when I load it up and replay in a minute from memory it should be faster so this is the channel that we're looking at but if you look somewhere there is the frequency offset so there's some frequency offset that I've set in the file let me just change the squelch here so that we don't have this annoying there we go sound so this is all well and good we want to explore the file interactively so we can bring this up and now these two applications are actually talking to one another so if you scroll here see the white line that white line is the time cursor in the file that's actually being played back from the GNU radio application so the GNU radio applications loaded up all this stuff and this is showing us you know the play cursor for the file so let's say we want to actually listen to some of these transmissions here I can't remember what's in this file let's see if there's anything interesting this looks like some audio here so I can have this here and then let's say I want to listen to this point in the file you can just click it'll load that file seek to that position and then select that frequency in the channelizer for the playback and then so again it's because it's reading on mechanical but if we start it again and then you know maybe that's uninteresting so you click over here and then it'll seek to that point you know pick the right file seek to that point start replaying and demodulating that file so in that respect it's I think a pretty powerful tool to review individual signals if you're looking for a needle in a haystack in a large capture file and you know if nothing's interesting there then you would just zoom out in time of frequency zoom out in time of frequency and then have a look at somewhere else in the file and then you know if you're interested you just click there who can tell me what that signal is yeah some sort of paging system so that's a good way to do it and then once you find your candidate signal then you can isolate that channel pull it out and do continue your processing on it but this is kind of a neat kind of visualization search tool so the last thing that I'll show you then is just a little bit of kitchen sink so as I was saying it has quite a few command line options as you can see there quite a few options did I already surely there aren't that many no that's actually all of them yeah it looks it looks like it's more because I'm not used to seeing in such a large font so if you just run it with no arguments then it'll just start testing the streaming on tx and rx and then you know you can do things like rx channel 0 progress interval 1 and then this will just do rx only and then every second it'll print out the rate that it's going at and it's on purpose quite verbose so it's telling you what it's doing what it's setting at every step so that if you need to check your logs or copy and paste that your console outputs you need to have a record or what have you then it's there other enhancements might be adding this to some other metadata that's output alongside all the timing information but again with all those other command line options you can sort of tell it exactly what to do again and store metadata so that you have all the information that you need later on to perform analysis with a really good notion of the time that was used at that point so I think I'll wrap up there questions the question is what kind of maximum sample rate can you expect with usb 3 when using hard drives in ssd it really depends on a lot of factors it's sort of a default answer in ssds you can as long as your system is performant I mean I think I can do 15 mega samples per second usually I go to ram the problem is if you want the best performance you need an intel chipset intel usb controller and you need to run under linux and you can play around with the kernel and if you want to e-cat a little bit more performance I love OSX you know all this is running on OSX obviously but OSX as I think we all know is designed to give you really slick UI performance and good response time there which means it comes at the sacrifice of scheduling in like a capture program so when I if you want to do it on OSX you need to reboot your system make sure nothing comes up and then capture like that and I've actually done I have spent so much time trying to figure out how to optimize performance on here turns out when you run instruments and you look at the call stack and what's the heaviest it's the Darwin system call that's submitting the USB request so everything else is pretty lightweight so there's a neat program called ram disk creator and you can use that to make a ram disk and it'll just pop up as a volume what I found finally enough is if you use disk utility and then reformat it as XFAT instead of just HFS plus which is a default you get a little bit of extra and then if I have my web browser running I need to use kill and then run a regex to like stop every single thing to do with any web browser that I've got because they're just so heavy and cause the scheduler to context switch so you know all these little things yeah the question is what's the feasibility of doing custom processing and decoding on the FPGAs that's a whole topic unto itself there are lots of possibilities if you want to talk to Neil or Nate they gave a talk yesterday about using RF knock on the FPGAs a lot of people have done some amazing custom stuff and there's all sorts of frameworks to do it in so there's a lot of options out there this is a USRP B200 but you know as I mentioned if you use SOPE SDR then all this stuff can apply to whatever radio you might have any other questions no alright yeah one more for like timing stuff and all that kind of jazz oh one of the good places they've got lots of stuff there the RTL SDR blog has you know a long running series of all sorts of really cool projects on all sorts of platforms and yeah I mean they're the two other main ones they've just come across any other good resources lately please yeah I think they're two good ones other people might have some other suggestions that they've used recently but anyway thank you for coming thanks for your attention if you have any other questions please find me afterwards thanks a lot