WEBVTT 00:00.000 --> 00:07.000 Thank you for joining. 00:07.000 --> 00:14.680 So my latest presentation will be about efficient USB for new Linux on a wide-band receiver. 00:14.680 --> 00:20.880 So today I put my affiliation as Associate Professor at University of France Conte because 00:20.880 --> 00:27.760 this project actually started last summer when I was asked by my colleague, can you prepare 00:27.760 --> 00:32.400 a new training for our master's students and, originally, my objective because I've always 00:32.400 --> 00:38.360 been using USB over RS or RS2 for two of emulation over USB and maximum you're going 00:38.360 --> 00:42.320 to get with CDC something like 100 kilo sample per second. 00:42.320 --> 00:47.360 And so on the one hand I wanted to learn how to have high-band with data transfer on Linux 00:47.360 --> 00:54.640 and well, you need a good reason to do this and I had for a few years on my desk this evaluation 00:54.640 --> 01:01.200 board of a GNSS receiver chip, it's called the Max2771 and I'll show you how good a paper 01:01.200 --> 01:08.480 weight it makes after you learn how to use it and afterwards I still wanted to prepare my 01:08.480 --> 01:12.960 master's students project so I continued I pursued the project and I'm going to show you 01:12.960 --> 01:15.120 what it ends up being. 01:15.120 --> 01:19.440 So what actually do we need high-band with data transfer? 01:19.440 --> 01:24.400 So my research activity is in time and frequency transfer and you might know they 01:24.400 --> 01:31.840 global navigation satellite systems are basically a set of 7080 atomic clocks in space that 01:31.840 --> 01:39.120 you can use for comparing your clock for sharing information between time and system. 01:39.120 --> 01:43.600 So if you look at the current constellations and this is stolen from the European 01:43.600 --> 01:51.760 state agency Navipedia webpage the legacy L1 GPS is your course average signal is about two 01:51.760 --> 01:57.360 megahertz wide already if you look at Galileo E1 you already see that there's something here 01:57.360 --> 02:04.560 that it's expanding frequency and now we have additional bands so we use to have the military 02:04.560 --> 02:11.760 band in L2 now we have civilian band in L2 and in E5 and L5 we have this huge band with 02:11.760 --> 02:17.600 allocated to navigation satellites in what they call lower bands so E5 and L5 is used for 02:17.600 --> 02:23.360 high-run notifications and so I wanted to be able to grasp these signals now of course 02:23.360 --> 02:26.880 you're going to tell me if you just get a B210 you're going to get the band with and that's it and of 02:26.880 --> 02:31.920 course I couldn't use 50 or 20 B210 in my lab sessions we just want to have a project so 02:31.920 --> 02:36.160 I needed to make something that was interesting to develop and that would meet the requirement. 02:36.960 --> 02:42.480 Secondly if you just look at the roll band with if you just estimate what you should be a 02:42.480 --> 02:47.600 theoretical band with that's one number it's the one on the left but when I play with my SDRs 02:47.600 --> 02:52.160 I can actually decode GNSS signals with such lower sampling rate and so I wanted to have a 02:52.160 --> 02:57.040 better understanding about the signals I wanted to understand how come that the 24 megahertz band 02:57.040 --> 03:01.440 with signal I can actually sample it 8 mega samples per second and get something so that's the 03:01.440 --> 03:06.720 real story about it and secondly you need to introduce some sort of iF band with because you're 03:06.720 --> 03:11.760 noisy on base bands well iF means that you need even more band with because you're going to shift 03:11.840 --> 03:16.480 your useful signal from radio frequency band to an iF signal and then you're going to sample the iF 03:16.480 --> 03:21.600 signal back to base band and so you need to have the band with plus the intermediate frequency as a band 03:21.600 --> 03:27.680 with so so these are really the challenge why we do want band with. I also show you that well 03:27.680 --> 03:33.120 it's a GNSS receiver but iRidium is just a few hundred megahertz or a few tens of megahertz above 03:33.680 --> 03:38.480 GPS and if you give a bit of flexibility to your VCO well we're going to get a region with it and 03:38.480 --> 03:44.000 an iRidium is as you can see here 20 megahertz wide so you need something of a band with to 03:44.000 --> 03:49.200 record a iRidium as well so so these are really the reasons for going for higher band with. 03:50.800 --> 03:56.880 So originally I was looking on the web I've been using GPS for quite a while GPS L1 03:57.440 --> 04:01.440 and one thing that I've been struggling with just because it's not the background of the 04:01.520 --> 04:07.600 lab I come from is Galileo Galileo is using a different modulation scheme BPS GPS is super simple 04:07.600 --> 04:12.800 it's a binary phase shift king so you just flip the phase 0 pi and it's super simple to look at. 04:13.360 --> 04:19.520 Now Galileo is using this binary offset carrier which is a bit well I'm going to show you I 04:19.520 --> 04:26.560 spend quite a lot of time waiting to realize how buck was working and since I did not know how 04:26.640 --> 04:31.200 buck was working I could not estimate what was the minimum bandwidth for receiving these signals. 04:32.240 --> 04:39.120 And I was looking at these at these slides from 10 for university of cyborg and cyborg tells 04:39.120 --> 04:43.840 that the minimum bandwidth is generally twice the chipping rate for simple codes and for buck codes 04:43.840 --> 04:48.560 it's twice the sum of a chipping rate and offset code so if a practical bandwidth for Galileo is 04:48.560 --> 04:53.200 eight megahertz but I can actually decode Galileo with two mega sample per second so what's the 04:53.200 --> 04:58.160 difference between what I'm saying and what cyborg is saying so so that was the reason why I wanted 04:58.160 --> 05:03.920 to learn how to do these things and I'm going to show you about this. So just as a quick reminder 05:03.920 --> 05:08.800 for the news of you who are not familiar with GNSS global navigation satellite systems I'm only 05:08.800 --> 05:15.120 going to focus on European Galileo and American GPS because Russian blown us is kind of different 05:15.120 --> 05:20.640 it's a frequency division multiple access it's not it's not usable for time transfer or hardly 05:20.640 --> 05:27.600 usable for time transfer and and Baydo is just a mess so I'm not looking at Baydo so so if we look 05:27.600 --> 05:32.880 at it very quickly you have all these guys broadcasting so so the Americans have been broadcasting since 05:32.880 --> 05:39.200 the eighties we've got a NAFTAR system everyone is broadcasting on the same kind of frequency of 05:39.200 --> 05:47.680 1,000 one gigahertz 575 to 42 gigahertz and so the Americans are flying 20,000 kilometers away 05:48.400 --> 05:54.720 with a period of period of the rotation period of 12 hours and they've been living happily 05:54.720 --> 05:59.680 until the Europeans said hey we want our constellation as well and when the Europeans said 05:59.680 --> 06:03.280 we want our constellation the American said okay you can broadcast with the same frequency but just 06:03.280 --> 06:08.640 blown above our signal just leave our signal alone and so the Europeans had to invent 06:08.640 --> 06:13.200 use a different kind of of modulation scheme and this is where we're going to see that the 06:13.200 --> 06:16.880 book modulation is going to be used actually when I looked at the literature I realized that book 06:16.880 --> 06:24.880 had been created by the Americans but it's the one being used by the Europeans so all these guys 06:24.880 --> 06:30.320 are broadcasting to the Europeans our 23,000 kilometers away the Americans are 20,000 kilometers away 06:30.320 --> 06:35.200 everyone is talking on the same frequency and so you need to differentiate these signals and so 06:35.200 --> 06:41.520 the classical approach is code division multiple access where each one of these guys is embedding each 06:41.520 --> 06:47.840 bit each message that is being broadcast in a series of chips so it makes a difference between 06:47.840 --> 06:53.520 bits and chips but actually binary states and so everywhere every satellite has been 06:53.520 --> 07:00.160 allocated a unique sort of random sequence which is the chip chip length and so we will need 07:00.160 --> 07:05.440 intensively cross correlations because assumption is you know what this code is if you don't know 07:05.440 --> 07:09.200 what the code is it's super difficult to decode you can get some signature as I'm going to show you 07:09.200 --> 07:13.440 but if you really want to get time stamping you need to know what the code is so cross correlation 07:13.440 --> 07:19.360 as a quick reminder is looking on the signal x of a pattern p with a time delay tau and you just 07:19.360 --> 07:26.000 slide the pattern p over the time delay copy of x and if you look it's energy accumulate and if you 07:26.000 --> 07:30.560 want to look at energy accumulate you take the integral over the duration of of a chip duration 07:31.200 --> 07:36.240 now one thing that is very important is that the cross correlation is a linear function and if you 07:36.240 --> 07:42.160 linear it means that if you get the signal from two satellites with weights a and b well 07:42.160 --> 07:48.800 satellite x with weight a and satellite b with weight y and you know which satellite is associated 07:48.800 --> 07:55.440 with which pattern then you will get each individual signature so even though you're 07:55.440 --> 08:00.160 on the ground you're receiving the sum of all these voltages you can see the recovery 08:00.160 --> 08:05.360 information from each satellite and if you flip the phase because you introduce a bit state or a 08:06.320 --> 08:10.880 well from the linearity the weight that you put inside the cross correlation can be extracted 08:10.880 --> 08:16.080 after cross correlation so the linearity of the cross correlation is very important and if you ever 08:16.080 --> 08:23.920 start reading either two multi-tacassus, a pocket as the arcode or genesis as the arc you will see 08:23.920 --> 08:29.520 that there's many many five four-inch fast-frequency forms and you need to remember the relationship 08:29.520 --> 08:34.240 between the cross correlation and the full-frequency form the four-inch form of a correlation is the 08:34.320 --> 08:39.280 product of a four-transformer the signal times a complex conjugate of a four-transform of a pattern 08:39.280 --> 08:43.920 this is very important because it transforms your end squared algorithm into the end log n 08:43.920 --> 08:50.720 and make your computation load much weaker so bpsk we have a total random sequence the phase 08:50.720 --> 08:58.720 is flipping and that's super easy and on the other hand your pins are using buck so as I was visiting 08:58.720 --> 09:05.440 last December my colleague Siddly Prontar at East Isaac I told him I'm desperate I cannot 09:05.440 --> 09:09.760 understand what this uh buck code is can you tell me something and he said no I'm not going to 09:09.760 --> 09:14.640 tell you anything just read the Bible and he gave me the URL of the Bible so if you want to know 09:14.640 --> 09:19.920 what Galileo it broadcasting and if you want to understand what buck is just read the dog and the 09:19.920 --> 09:25.280 documentation is super clear I took for you here information so binary offset code so if you just look 09:25.760 --> 09:31.280 at the raw data and I'm not going to talk about the pseudo random sequence generation I'm just using 09:31.280 --> 09:37.520 a very nice repository uh from University of Catalonia and Barcelona where they have all the codes 09:37.520 --> 09:42.320 as MATLAB file so you just load the MATLAB file you get all the code so forget about how we generate 09:42.320 --> 09:47.840 the pseudo random sequences but the pseudo random so the binary code is just you flip the phase so no 09:47.840 --> 09:53.920 frequency offsetting and you can just analyze the spectrum of these of these uh code after you've 09:54.000 --> 10:00.240 interpolated for a sampling rate so the GPS L1 is running at 123 mega sample per second you 10:00.240 --> 10:07.760 sample your data at FS so you just need to read resample your code at the rate right number of 10:07.760 --> 10:14.560 chips uh bits per chip a sample per chip now in buck modulation you're told that each one of your 10:14.560 --> 10:19.920 codes is actually multiplied by a carrier and this carrier frequency are given in the document 10:19.920 --> 10:26.800 it's 120 for megahertz and 60 megahertz so rather than having just one uh message that you want to 10:26.800 --> 10:31.920 modulate the pseudo random sequence and that you send on your BPSK output now you've got the second 10:31.920 --> 10:38.000 mixer here that will of frequency offset your your your your your carrier and this is actually the 10:38.000 --> 10:44.240 implementation I'm using in octaves to simulate my buck modulation and why is this useful because now 10:44.320 --> 10:49.680 you can actually plot the wave shape of the wave that you wrote class in the buck modulation 10:50.320 --> 10:57.040 and first of all you see that your buck modulation correlation is narrower than the uh BPSK 10:57.040 --> 11:01.520 correlation so that's a nice thing if you want to do timing analysis but most importantly you 11:01.520 --> 11:07.200 understand here why the American told the Europeans you have to use buck and not BPSK the Americans 11:07.280 --> 11:14.480 GPS is a red curve here and you know that if your BPSK modulated it's a given sample rate 11:15.520 --> 11:22.480 it's a given chip rate the first news here would be at chips megahertz so here we have the 11:22.480 --> 11:29.520 BPSK GPS L1 your broadcasting at 120 free mega cheaper seconds your first new year is at one megahertz 11:29.520 --> 11:36.240 and minus one megahertz the Europeans were said we're told to use buck and buck was shifted at a rate of 11:36.320 --> 11:42.480 120 free megahertz per seconds it was shifted by 120 free megahertz meaning that you're putting the 11:42.480 --> 11:47.760 new of a European signal right where the maximum of the American signal is and hopefully 11:47.760 --> 11:52.320 the Europeans are not disturbing too much the Americans in broadcasting their signal 11:53.440 --> 11:59.440 so this tells you also that you can live with a one megahertz sampling rate and remember we're 11:59.440 --> 12:04.320 working with complex numbers so one megahertz sampling rate is two megahertz bandwidth for GPS 12:04.400 --> 12:10.720 because you use most of the energy of BPSK but if you try to do the same with Galileo 12:10.720 --> 12:16.800 well you see that your lobes are hardly included in these bandwidth and so you will have a hard time 12:16.800 --> 12:23.280 recording Galileo with the same bandwidth when you're using for GPS L1 if you do this a bit faster 12:23.280 --> 12:28.560 so you simulate what's happening at 24 mega sample per second you see here the buck modulations 12:28.560 --> 12:33.040 key here you have a six megahertz sorry here you have a six megahertz offset here you have a 12:33.040 --> 12:39.200 120 free megahertz offset and here here here at the GPS L1 so all of these to tell you to justify 12:39.200 --> 12:45.040 why we want to have a fast sampling rate we want more bandwidth to record this data and so we 12:45.040 --> 12:52.240 have these chips from another devices originally from maximum which is a max 2771 and so my objective 12:52.240 --> 12:59.120 was to learn how to use the max 2771 and to interface to a USB to efficiently transfer data to Linux 12:59.120 --> 13:05.440 that's the outline of the project I wanted to complete now actually you might if some of you 13:05.440 --> 13:11.520 are investigating GNSS you might know Tomogita Casu for his work on the RTK lib and Tomogita Casu 13:11.520 --> 13:18.320 seems at least published since 2021 an amazing project which is called the Pocket HDR and since 13:18.320 --> 13:23.520 whenever since I've seen this project on the GitHub I've been dreaming of getting a Pocket HDR 13:23.520 --> 13:28.960 but Tomogita Casu is working at the University of Marine Lab in Tokyo and he's not just his job 13:28.960 --> 13:34.480 he's not to manufacture board so he's giving away over designs but I never went through all the 13:34.480 --> 13:40.480 hassle of reproducing in the lab so that was a good opportunity for me to learn how to use this max 2771 13:41.760 --> 13:46.720 so just to show you I did an exhaustive investigation I'm not going to get in the details 13:46.800 --> 13:52.720 but this is using a B210 preliminary investigation x-axis is a sampling rate y-axis is a 13:52.720 --> 13:59.520 constellation type and if you record data I value sampling rate basically because Galileo is 13:59.520 --> 14:07.360 sampled at 123 or is a book at 123MHz offset and you have a second offset at 6MHz 14:07.360 --> 14:13.040 all the sampling rate below 2MHz and each one of his colored dots sorry this in the x-axis you've 14:13.040 --> 14:18.960 got the satellite index the satellite number in the y copy you've got the frequency shifts of 14:18.960 --> 14:23.440 the Doppler shift and each one of his dots is the magnitude of a correlation so each one of his 14:23.440 --> 14:29.840 dots is a satellite now you see that on GPS the dots look broader than on Galileo that's because 14:29.840 --> 14:34.400 the code length of Galileo is four times longer it's four thousand chips instead of one thousand 14:34.400 --> 14:40.640 so the codes are narrower in Galileo and basically in the low sampling rate you don't get the six 14:40.640 --> 14:47.280 megahertz both offset but once you get above 10MHz you start see the Galileo satellite as well 14:47.280 --> 14:54.080 so I start looking extensively at the impact of the sampling rate and I was kind of disappointed 14:54.080 --> 14:59.680 that there was no real impact on the signal to noise ratio so the faster you go once you go beyond 15:00.960 --> 15:05.200 the low width well you just integrate more and more noise and the signal to noise ratio is not 15:05.200 --> 15:10.240 improving so much so so you just need to have enough bandwidth but not more than needed so that 15:10.240 --> 15:22.560 that was initial analysis before getting to the max 2771 so now I had this evaluation board that I 15:22.560 --> 15:28.400 had both just before COVID and initially I was thinking okay I have plenty of time during COVID 15:28.400 --> 15:35.600 I'm going to learn how to use this I plugged in the board hoping to see virtual zero port no 15:35.600 --> 15:40.320 zero port okay that's a bad start for Linux so then you've got this chip here this microphone 15:40.320 --> 15:47.280 controller that is provided by Max and I see this is a max 2771 you've got so they've got what they 15:47.280 --> 15:52.160 called the upper band and the lower band because the L1 band and L5 band that at one point 15:53.040 --> 15:59.360 2DHz and 1.6DHz are too far too far apart to be recorded by single HDR so you must select 15:59.360 --> 16:03.520 your HDR and you tune it either to upper or lower band so this is why you have more than a few 16:03.520 --> 16:08.720 SMA so this is the lower band this is the upper band that I'm sampling and then you go through 16:08.720 --> 16:15.680 a low noise amplifier and then you go through the mixer and you get your samples okay so no 16:15.680 --> 16:23.360 zero port okay that's a bad start so I download the I try to to look at the data I couldn't find anything 16:23.360 --> 16:30.000 so basically that's I put the way until I got this project work on and then the new thing is 16:30.000 --> 16:34.320 since I initially looked at there was this very nice web page explaining how you can sniff 16:34.320 --> 16:39.600 USB and how you can reverse engineer and unknown protocol so I started doing this and surely enough 16:39.600 --> 16:45.040 to just look at the debug functionality of the Linux kernel and you can very nicely see all the 16:45.040 --> 16:50.000 streams coming out of this of his guide here and basically you see that when you run the 16:50.000 --> 16:54.720 proprietary software from another device in the virtual box the Linux kernel is intercepting 16:54.720 --> 17:00.320 all the USB communication you see the stream the proprietary software is pinging the board every 17:00.320 --> 17:05.040 second the board is answering I'm here and when you want to change the register the software just 17:05.040 --> 17:11.680 sends what I now know is known as a vendor request so you send the stream for the USB telling I want 17:11.680 --> 17:17.680 to change this register with this value super easy to reverse engineer so I wrote the software for Linux to 17:17.680 --> 17:23.360 drive this max 2731 board I could read set the registers I could look with the oscilloscope 17:23.360 --> 17:30.000 at the i2 outputs and then I search for the button on the graphical user phase from another device 17:30.000 --> 17:40.000 that says stream data and there is no such button so I asked the other device support where is 17:40.000 --> 17:46.480 the stream data button and I didn't even expect an answer and surprisingly enough after a week I 17:46.480 --> 17:52.880 got an answer from another device remember this was initially done by maximise and another device 17:52.880 --> 17:57.280 both maximum so I'm not saying this is due to a lot of device but well it's a fact that I was 17:57.280 --> 18:02.160 to yeah initially we thought that we would stream the i2 data but we never went and we never 18:02.160 --> 18:08.320 finished a firmware so you do have a couple of registers that allow you to connect the i2 path to the 18:08.320 --> 18:13.680 macro controller but there is no software for reading so there's no need okay so that's why I'm 18:13.680 --> 18:20.320 telling you just save your 532 euros and don't buy a paperweight because what you buy here is just 18:20.320 --> 18:27.520 a USB to a SPI converter for 500 euros okay so I was quite disappointed I had wasted having 18:27.520 --> 18:33.360 euros of taxpayers money on these works why do I continue now okay so you throw away the 18:33.360 --> 18:37.520 micro controller you cut the traces you just throw it away you connect this and you take 18:37.520 --> 18:42.560 Tomoji Takasu who is much more efficient than maximise and other device because he did 18:42.560 --> 18:49.680 something with works and Tomoji Takasu taught me about about the fx12p so the 18:50.000 --> 18:57.920 fx12p is a cypress chip also known as uezy usb and this chip will hold a micro controller 18:57.920 --> 19:02.960 a big micro controller which I know quite well it's got the parallel to usb interface and because 19:02.960 --> 19:07.440 it's got a micro controller it's always a big bang SPI interface which is exactly what Tomoji 19:07.440 --> 19:14.000 Takasu did okay so let's throw away this stupid micro controller and let's take Tomoji Takasu's project 19:14.640 --> 19:20.560 so Tomoji Takasu's project is yard is made of two max 2771 19:20.560 --> 19:25.280 however if you want to do some spoofing analysis I'll show you in the end because you want to look 19:25.280 --> 19:29.360 with two antennas at the same signal or if you want to have one signal you have the upper band 19:29.360 --> 19:32.480 one signal to the lower band so then you set them to a different frequency band 19:33.360 --> 19:40.320 the output of these eight to three converter are two bits each two bits for IQ is four bits per 19:40.400 --> 19:46.960 max 2771 we've got two max 2771 we can feel the eight bits of the parallel commutation 19:46.960 --> 19:51.360 with the eight bits of the eight to the converter and these eight bits are actually interleaved 19:51.360 --> 19:57.120 so you know that they're exactly simple at the same time also because one max 2771 is a slave 19:57.120 --> 20:04.320 of the clock of the other one so we've got coherent synchronous acquisition up to 48 mega 20:04.320 --> 20:10.560 sample per second actually the max 2771 can go up to 44 mega samples per second but that's 20:10.560 --> 20:16.480 really nice I mean we get 40 mega sample per second I too interleaved from two boards so that 20:16.480 --> 20:24.000 that was looking very exciting so the first thing I did is I took Tomoji Takasu software and I 20:24.000 --> 20:29.920 learned how to use it so that was an opportunity for me to learn how to use sorry sorry so 20:29.920 --> 20:37.040 yeah these are interfaces of Tomoji Takasu sorry so yeah this board here on Tomoji Takasu's 20:38.720 --> 20:46.160 board he puts his own ethics to LP and when I was looking friends buying an ethics to help people 20:46.160 --> 20:52.320 cheap bear cheap was twenty euros from far now if I go on alley express I can get with no 20:52.320 --> 20:57.520 charge for shipping for less than five euros an assembled board from alley express so sorry for 20:57.520 --> 21:04.000 far nail but so I got twenty of these of his board and they have the ethics to LP it's they're all 21:04.000 --> 21:08.880 working very well actually so much for the pro quality of trans product they all work perfectly 21:09.600 --> 21:16.240 except for little detail actually in a second so what this board has is got the ethics to LP it's 21:16.240 --> 21:22.880 got a few GPU pins it's just got a regulator and so the first thing we learned was to very simple things 21:22.880 --> 21:28.960 toggle a GPU this kind of stuff now why did we have to learn how to use this 851 core on the 21:28.960 --> 21:35.120 ethics to LP because Tomoji Takasu is working on windows with a cable proprietary compiler 21:35.120 --> 21:43.120 and he's limited because kale gives you a free version which is limited to a firmware side and of 21:43.120 --> 21:46.800 course I'm not going to use a proprietary software there's no the way I'm going to do this so 21:46.800 --> 21:52.080 I need the first thing I needed was to translate Tomoji Takasu software to SDCC and to do this 21:52.160 --> 21:55.600 because you know that when you're translating from one compiler to the other the thing that never 21:55.600 --> 22:00.320 translate is interrupted so I need to learn how to work with interrupt vectors and how to 22:00.320 --> 22:07.040 how to get the basic operation on the 851 so it always very well I translated Tomoji Takasu 22:07.040 --> 22:13.920 software into the right language of SDCC so the small device see compiler for those of you who are 22:13.920 --> 22:20.560 not familiar and nothing was streaming and luckily for me Tomoji Takasu had the exact same problem 22:20.640 --> 22:26.240 that the Chinese board is working very well except that some of them they have made a mistake in 22:26.240 --> 22:32.400 writing well unfortunately it's the reading write pins that they miss marked so actually just 22:32.400 --> 22:37.200 have to be aware that if you take some of his cheap Chinese boards some of them have a write 22:37.200 --> 22:42.400 writing and some of them have the wrong one and unfortunately mine had the wrong one and once you understand 22:42.400 --> 22:48.560 this it works super well so we end up learning how to do a few things then we need to learn how to 22:48.560 --> 22:55.040 communicate and leave USB is now wrapped in Python so you implement what I now learn to be called 22:55.040 --> 23:00.640 vendor request which are basically commands that you send from the USB bus to be interpreted by 23:00.640 --> 23:07.840 the 851 this would be your commands for setting the GPIOs or for setting the SPI and you implement 23:07.840 --> 23:17.280 this talking in in USB sorry in Python so super easy to to implement so now we have something that 23:17.280 --> 23:23.360 is more or less functional which allows us to stream data but RV's data actually functional so I 23:23.360 --> 23:30.160 will be quickly took me a couple of months but the chip we've got the internals you have the 23:30.160 --> 23:35.840 local oscillator you've got some tutoring capability you can stream some real data so real data 23:35.840 --> 23:43.040 means even spectrum you can stream some complex data so that the spectrum is right and you see that 23:43.040 --> 23:49.680 if I shift the tire frequency by a few hundred kilohertz indeed the rate is shifting and this is 23:49.680 --> 23:55.440 made so much easier with Tomoji Takasu's pocket conf software that I'm going to show you in a second 23:55.440 --> 24:00.720 because instead of reading over registers and setting manual over registers Tomoji Takasu did 24:00.720 --> 24:06.320 all the hard work of telling okay I want this setting for the intermediate frequency I was this setting 24:06.320 --> 24:11.920 for the local oscillator and he just sets all the bits properly and that's working super nice 24:12.800 --> 24:17.360 now the problem with this is when I was plotting these charts I was recording plotting 24:18.000 --> 24:23.200 I made a mistake the setting so I do a new recording I play I plot again and I think 24:23.200 --> 24:28.960 Chronos is not fun I mean anyone who's doing MATLAB or new pie knows that I think Chronos 24:28.960 --> 24:35.200 processing is not fun so I wanted to do this with new radio of course and I think too many 24:35.200 --> 24:41.120 people are forgetting that the core of Unix varies the pipe now I was watching these videos 24:41.680 --> 24:46.880 from Brian Chronigan and then he's richy about the design original design of Unix 24:46.880 --> 24:52.080 and very reminded the very beginning of the video a core aspect of Unix is pipes where you have 24:52.080 --> 24:56.400 simple programs that talk to each other through the operating system and not a big bulk 24:56.400 --> 25:02.480 program that does everything wrong so let's do it like this let's say that Tomoji Takasu is right 25:02.480 --> 25:08.640 into a file it's a file I write to a file for and the file for is a file input from new radio 25:09.280 --> 25:13.760 so initially what Tomoji Takasu does is he decodes the data you know it's two stream 25:13.760 --> 25:21.040 for the 2017 and so I created two files and it happens that if you take one new radio flow chart 25:21.040 --> 25:27.760 with two inputs and one output from pocket SDR writing to two files there must be a raised 25:27.760 --> 25:32.560 condition somewhere that the flow chart never starts streaming because the file for only 25:32.560 --> 25:37.600 starts sending data when both ends are connected so I ended up doing two streams and I was 25:37.600 --> 25:43.520 really happy about it because I needed to run two times new radio to plot this chart which 25:43.520 --> 25:48.640 actually look really good I mean this this is the signal this is the auto gain control on the 25:48.640 --> 25:55.040 others input that was loaded on on a 50 ohm load and it looks good but okay I wanted to find a solution 25:55.040 --> 26:01.120 and the only way you can stream the pocket SDR output on a single file is to use the 26:01.440 --> 26:08.320 minus R the row output but if you send the row output well you get the row data so 0123 26:08.320 --> 26:14.160 which are not a bit state but are the row data so let's see if I can get this working so this is 26:14.160 --> 26:20.960 actually my flow chart and the novelty is because you've got four bits for each max 2771 26:20.960 --> 26:28.640 you're going to convert the 8 bits the byte input into nipples for bits then you convert the four 26:28.640 --> 26:36.560 bits iq so i0 i1 q0 q1 into the 16 possible states so if you want to have equities instead 26:36.560 --> 26:42.960 to the rate minus 3 minus 1 plus 1 plus 3 so this is what your chunks the symbol is doing 26:42.960 --> 26:49.440 and once you convert the row data into voltages you have your two streams that you de-interleaf 26:50.400 --> 27:02.000 so if all goes well I'm gonna configure the two max 2771 with the L1 then you can check 27:02.000 --> 27:07.200 that everything is going well by checking the configuration with no option it plots the output 27:07.200 --> 27:12.720 and we can check that both so this is actually the real value that can be read so they're both on the 27:13.680 --> 27:22.320 L1 then then I can run this guy so pocket dump is dumping the data from pocket is r minus r to get the 27:22.320 --> 27:30.080 row data and I send this to a cipher so I have to just show you that this is indeed a row a name pipe 27:31.520 --> 27:38.640 so this is your name pipe that was created using mpff and it's my dump is guy here and 27:39.200 --> 27:44.800 play my new radio flow charge with the same name pipe as the input over here 27:47.040 --> 27:52.800 okay some this screen over here so I need to get this on the way here okay so at the moment there's 27:52.800 --> 27:59.440 no input signal so this is just the rules stream now I connected a puto as r so the puto as r is 27:59.440 --> 28:04.480 just next to here I'm not limited by the same thing rate because this flow charge is going to change 28:05.040 --> 28:13.600 the local oscillator of the puto as r so here we go and you see that already the puto as r is a 28:13.600 --> 28:20.320 bit noisy and if I move around my frequency you do get real time output from your max 2771 28:20.320 --> 28:25.840 only one channel is connected the other one is loaded on a 50 ohm load so this makes the analysis 28:25.840 --> 28:32.800 so much easier because now you have an interactive interactive discussion with your system 28:32.800 --> 28:37.680 and if you don't want to have the funny little shape when you're changing frequency let's just 28:37.680 --> 28:44.480 because I had averaging on okay so that's that's how you can actually super easily interface anything 28:44.480 --> 28:51.600 that talks over as it's aside with new radio just use the name pipe if you want to reproduce 28:51.600 --> 28:58.880 this at home just make sure that first of all you put a this blocker because we are routing 28:58.960 --> 29:05.360 five volt to power the active antennas through the SMA here but if you look at the schematic of 29:05.360 --> 29:10.720 the puto as r the balloon over here is actually this is coupled to ground so the first time I did 29:10.720 --> 29:16.480 this of course the power supply collapsed because I chose to continue the five volt of my max 29:16.480 --> 29:24.560 2771 of a FX12P and secondly you need to make sure that you activate enough remember these are 29:24.560 --> 29:32.160 designed to receive GPS GPS nominal power is minus 130 dBm on the surface of earth now you get 29:32.160 --> 29:38.960 some margin and the compression point of this board is given at minus 100 dBm if you feed it anything 29:38.960 --> 29:45.200 above 100 minus 100 dBm you will start seeing compression the amplifier will compress and you will 29:45.200 --> 29:51.200 see nonlinear behavior so you need because the puto as the r the minimum power you can output 29:52.080 --> 29:58.240 so at full power it's 10 dBm you can have maximum 89 dB attenuation so your minimum output power 29:58.240 --> 30:04.400 of the puto as the r is minus 179 dBm so you must have here I have a 20 dB attenuation to 30:04.400 --> 30:11.840 avoid having unwanted previous modes right so now we are at the point where we know how to use 30:11.840 --> 30:20.000 the puto as the r with it's 2771 we know how to use the scripts from tomato tacaso and we know 30:20.000 --> 30:25.520 how to interface to be radio so now what is the well of course if you're working with GNSS you 30:25.520 --> 30:32.720 would like maybe to be able to position yourself so this is my board on the balcony outside my lab 30:32.720 --> 30:40.080 that's a GPS active antenna only connected to one side and well what makes analyzing this board 30:40.080 --> 30:46.480 when you don't know if it's working or not super complicated is if you remember a GPS satellite 30:46.480 --> 30:52.560 is broadcast in 50 watt and it's 20,000 kilometers away so if you just look at energy conservation 30:52.560 --> 31:00.480 you get something on the surface of your bed of minus 177 dBm but if you integrate turbo noise 31:00.480 --> 31:06.720 so just the fact that you have a 50 ohm load at room temperature your turbo noise is minus 120 31:06.800 --> 31:15.760 sorry your turbo noise is minus sorry this the signal you get is the 50 watt output minus 31:15.760 --> 31:22.640 182 dB losses and on the other hand you've got the turbo noise which is your noise flow minus 31:22.640 --> 31:29.280 174 dBm plus a bandwidth and so basically the GPS signal is 15 dB below the turbo noise so you 31:29.280 --> 31:35.920 cannot see it on a spectrum analyzer so you really need to process the data to see them so you 31:35.920 --> 31:40.960 got various means even if you don't know how GPS works you've got tricks where you can actually 31:40.960 --> 31:45.920 take the auto correlation by taking the auto correlation where the signal is frequency shifted by 31:45.920 --> 31:51.120 the Doppler shift but the Doppler shift if you look at yourself similarity is acting on both 31:51.120 --> 31:55.760 reference and the measurement signal so the Doppler shift will go away so the auto correlation 31:55.760 --> 32:02.880 will show you heat spaced by the chip rate so the rate at which the data are being broadcast 32:02.880 --> 32:08.480 by the GPS and the second trick that you can use that what's talked to me by problem is that if you 32:08.480 --> 32:14.480 actually square the signal because we're using bps k signal your phase which is 0 pi by squaring 32:14.480 --> 32:21.040 it's going to be 0 2 pi and you will see this nice cw signals and each one of the signals is 32:21.040 --> 32:25.360 satellite broadcasting at a different offset frequency because they all exhibit different Doppler 32:25.360 --> 32:30.400 shift so you can have codeless decoding that already tells you okay we're getting something I 32:30.400 --> 32:37.120 don't know if I can decode it but I can get something so you run the record and you run a 32:37.120 --> 32:42.720 pocket this is what my mobile phone was telling me this is what pockets are cost telling me 32:42.720 --> 32:51.680 and you've got gps signal 11 25 28 and you've got gps 11 25 28 so we got consistent measurements 32:51.680 --> 32:58.640 between the pocket SDR and our mobile phone you can do this for e1b you can also do this for e1c 32:58.640 --> 33:08.320 so yeah the pocket SDR seems to be working on the side notes because iridium is just a few 33:08.320 --> 33:14.960 megahertz above GNSS and maybe for those of you who attended CCC you might have seen the latest update 33:14.960 --> 33:20.160 of second Schneider about GR iridium well you just take a gps antenna you get rid of the 33:20.160 --> 33:24.480 past future they're showing how they have the XC antenna but I'm still using my patch antenna 33:25.200 --> 33:30.480 and actually you can change these to a pocket SDR it's not obvious because you've got not 33:30.480 --> 33:37.040 a two-bit quantization and iridium is not benefiting from the post compression of CDMA so it was 33:37.040 --> 33:41.520 not really obvious that the pocket SDR with it's too big I actually would be able to receive 33:41.520 --> 33:49.360 Galileo signals at iridium signals but what you do see is that you can tune the max 271 in the 33:50.160 --> 33:56.960 iridium band and these are 24 hours of if you look at how it works you've got the iridium ring 33:56.960 --> 34:03.520 access so IRAA messages that tell you where the beam is and where the satellite is in space 34:03.520 --> 34:08.960 this is a spectrum that you get from iridium and if you go decoding you don't get that many messages 34:08.960 --> 34:13.760 I must admit it's working much much worse than a B210 but I'm talking about a 20 euro board not 34:13.760 --> 34:19.280 a 2000 euro board so you get what you pay for and so that's for example a couple of 34:19.280 --> 34:25.520 archives messages that I got over 24 hours of recording iridium using the max 2731 and these 34:25.520 --> 34:32.560 match the flight radar tracks of a plane flying from Milado to Torino it's a remember well 34:32.560 --> 34:37.280 well basically over Italy and there's no way a plane flying over Italy in line of sight of 34:37.280 --> 34:42.160 the sun is the friend so that's obviously an archives message that was received through iridium 34:43.600 --> 34:49.520 okay so now we know how to post-process data with GenesisDR we know how to run this through 34:49.520 --> 34:54.720 iridium but maybe we would like to get something real time we want to have a real-time GPS and if you 34:54.720 --> 34:59.200 want to do real-time processing I'm sure pocketed the art and do it but I'm familiar with Genesis 34:59.200 --> 35:05.920 as DR from the Barcelona guys from Carlisle and his group in a technical diversity of Barcelona 35:06.080 --> 35:15.600 so just how do you interface the max 2731 of pocketed DR with with the GenesisDR you've got the 35:15.600 --> 35:20.880 you can read from the file you've got a byte to short that converts the input byte into something 35:20.880 --> 35:25.920 that's usable then you can eventually remove the frequency offset the intermediate frequency that 35:25.920 --> 35:32.240 you introduce to get rid of baseband signal and when you run this either you do it using the 35:32.240 --> 35:36.480 frequency translating feature filter or because we've just seen that we need to press with new 35:36.480 --> 35:43.520 radio you can actually take the outputs of the pocketed DR frequency translate using new radio 35:43.520 --> 35:50.800 and then output I tried outputting in a file using the might of a main pipe trick a second time 35:50.800 --> 35:54.880 and somehow it doesn't work well at all you can not somehow there's something wrong by using an 35:54.880 --> 36:01.040 input pipe and an output pipe so I use an input fifo and the output I took with 0m2 output and it 36:01.040 --> 36:08.000 actually happened the GenesisDR knows how to read 0m2 so actually this is my flow chart for real-time 36:08.000 --> 36:13.840 processing and if you run this you get your real-time processing after let's end two minutes you get 36:13.840 --> 36:20.080 your first position and then you got your output from GenesisDR which is a correct location 36:20.080 --> 36:27.200 Barcelona is located six degrees east 47 degrees north okay so now we are able to run GenesisDR 36:27.200 --> 36:32.400 on the pocketed DR and we get real-time messages so far we've just done the same as we did with 36:32.400 --> 36:41.440 all our other receivers now some of these data have been stored on IQ engine and very important 36:41.440 --> 36:47.600 whenever you're storing binary streams make sure that you time tag or that you tag what you did 36:47.600 --> 36:52.800 what was the data format what was the game what was the receiver otherwise I mean you're generating 36:52.880 --> 36:58.320 40 megabyte per seconds you're generating something like 60 gigabyte per hour so you don't want to 36:58.320 --> 37:04.160 feel your disk with data that you don't remember what they are so CIMF is providing a framework 37:04.160 --> 37:10.240 for making this so here we have complex integer 8 bits it's recording the E1 band and if you want to 37:10.240 --> 37:18.720 play yourself you will find on the IQ engine size that you can run for over processing I if at the end 37:18.720 --> 37:23.760 you someone wants to see it you can run the data to get an IQ engine I wanted to do a demo 37:23.760 --> 37:28.800 but I'm running out of time so you can actually do a cross correlation you can do the auto correlation 37:28.800 --> 37:33.840 you can do a squaring and everything I showed you using post processing in MATLAB you can do very 37:33.840 --> 37:41.120 easily in or nicely in Burego so as I was doing this I wanted to cross correlate the signal I was 37:41.120 --> 37:49.280 recording with the data stream that I collected on the MATLAB data set and then I wanted to 37:49.280 --> 37:54.800 upload these codes marklish man told me but I don't want to put some code that we can regenerate 37:54.800 --> 37:59.200 can to do the generation of a code by yourself rather than putting the data on IQ engine.org 38:00.000 --> 38:04.960 and surely enough because it's all written the generators are written Python and you can 38:04.960 --> 38:11.440 irrade your you've got the Python block well you can actually copy paste in the Python block 38:11.440 --> 38:19.040 the generator that you find on the guitar and if you just look at what it looks like 38:20.480 --> 38:26.000 I just took the I don't talk much Python but I can just copy paste and you take the Python 38:26.000 --> 38:32.160 block to generate the code and instead of keeping the streams as a binary file you actually regenerate 38:33.040 --> 38:38.240 so you can actually do all your analysis and gradient we generate the data and you can actually 38:38.240 --> 38:42.960 do because you've got access to the raw IQ stream you can actually do much more clever things 38:43.520 --> 38:49.040 for example when you're looking at the GNSS signal from two antennas well you know that in a 38:49.040 --> 38:53.840 genuine consolation all the signal should be coming from different direction so if you take the 38:53.840 --> 38:58.880 difference of the phases from the two antennas you should have all phases from all satellites 38:59.040 --> 39:02.880 detected by the frequency offset of a Doppler shift at different phases 39:03.680 --> 39:08.640 but if you're under spoofing meaning that you have a single emitter broadcasting all the 39:08.640 --> 39:13.600 constellation signals there is one thing you can spoof its physics the phase difference between 39:13.600 --> 39:19.280 two antennas is determined by the plane wave angle of arrival and so this is your spoofing detection 39:19.280 --> 39:24.800 using the max 2771 dual board you've got all the phases coming from the same place and that's 39:24.800 --> 39:30.080 makes really nice because it's low power really small as a spoofing detector so this tells you 39:30.080 --> 39:37.200 that you can use the two bits a two-week converter for spoofing detection now another thing is time 39:37.200 --> 39:44.400 transfer as I was visiting my colleague at a tech we were collaborating GNSS antennas and it came to 39:44.400 --> 39:50.640 me that what is a time delay of this chip can I reproduce on the chip what we did with 39:50.640 --> 39:58.240 he's on real data on real signal so you've got these two outputs you take your your max 2771 39:58.240 --> 40:04.400 you connect them to the same antenna so same location you feed them the same data you generate 40:04.400 --> 40:12.160 sort of random signal yes sort of ranges and my colleague GNSS and his friends from the 40:13.120 --> 40:20.320 juris project they made an amazing set of tools that allow you to manipulate Rinex files so you 40:20.320 --> 40:27.840 have the output of GNSS R whose tender format is Rinex and using the tools from the home you can actually 40:27.840 --> 40:34.320 operate do operations on these Rinex files for example you can make a difference between two files 40:34.320 --> 40:40.640 and if you take the difference between two Rinex files of a collocated system which also happens 40:40.640 --> 40:46.640 to be clocked by the same signal you just got something which is a time delay between one receiver 40:46.640 --> 40:51.120 with respect to the other basically we have something like six nanosecond and standard deviation 40:51.120 --> 40:56.080 of about five nanosecond between the two to the ranges you can do a lot of things you can actually 40:56.080 --> 41:02.080 generate using the Jill rest tools you can actually convert the Rinex into a CSV which allows me 41:02.080 --> 41:09.680 to do statistics to load them in octaves to do much more okay so this was done between two max 2771 41:09.920 --> 41:15.200 I actually did the comparison with a U-blocks receiver and somehow because the U-blocks and the 41:15.200 --> 41:21.760 genes in the max 2771 are not clocked by the same source you see that the total ranges are drifting 41:21.760 --> 41:26.720 over time but surprisingly enough and this I don't have the answer if anyone knows all of the 41:26.720 --> 41:33.520 total ranges from the U-blocks receiver with respect to the max 2771 all the satellites each different 41:33.520 --> 41:39.200 satellite was offset backends I don't know what the 16L second is and I don't know why but here 41:39.200 --> 41:44.400 you have one satellite so the range is super stable when to remove a linear drift and all the satellites 41:44.400 --> 41:51.200 are off by 16L seconds so I play but I can measure a time offset of six nanosecond plus or minus four 41:51.200 --> 41:59.040 nanosecond using these total random sequences am I right well what I did is okay then we can put a 41:59.040 --> 42:03.600 bit of cable between one and ten and the other and can we actually measure the length of the cable 42:03.600 --> 42:09.600 using the signals well yes you can actually you initially I had two SMA connectors then I took 42:09.600 --> 42:14.320 all the cable that could find the lab so two meter four meter five that eight meters and 42:14.320 --> 42:20.080 these are the measurements the crosses the bold lines are the mean value and you see that actually 42:20.080 --> 42:26.880 you get results that are consistent with speed of light in a quadro cable of 20 cm per nanosecond so 42:26.880 --> 42:33.920 yes you can measure a cable then using a dual GPS receiver so this actually concludes 42:34.720 --> 42:42.800 this project outcome we can actually assemble a high bandwidth low bit resolution dual frequency 42:43.680 --> 42:53.680 dual coherent receiver so many amazing paths one of them is all radios radios astronomy all 42:54.240 --> 42:59.920 telescopes it's something that you can reproduce and you can even do a university so this concludes 42:59.920 --> 43:03.920 everything I had to tell you if you are curious about some of the topics I still have to make a 43:03.920 --> 43:10.560 bit of advertisement so as of end of year we released some textbook about new radios some of the 43:10.560 --> 43:17.120 topics I discussed here are including the book so feel free to enjoy it as much as I enjoyed 43:17.120 --> 43:21.280 writing it and with this I thank you for attention