WEBVTT 00:00.000 --> 00:18.000 This presentation focuses on the use of a low-bit resolution, software EF, software EF, 00:18.000 --> 00:24.000 and the receiver initially designed for global navigation satellite signal reception, which was 00:24.000 --> 00:31.520 last year's presentation. The big benefit of working with low-bit count is you can have very high 00:31.520 --> 00:38.160 data rates. So when you have a finite bandwidth channel, the fewer bits you put, well, you can 00:38.160 --> 00:43.360 pack more bits and you can sample faster. So in the case of this chip, we can go up to 40 00:43.360 --> 00:49.840 mega sample per second, like it varies to all this earlier, that for the previous year, 00:49.840 --> 00:54.240 he has a hard time going about 4 megahertz, I have a hard time going about 6 mega sample 00:54.240 --> 01:01.360 second with a B210. So 40 megahertz open new perspectives, and what I want to show you is that 01:01.360 --> 01:08.320 maybe you don't always need all that bits, these 12 or more bits, they might just be useless. 01:08.320 --> 01:16.080 And so I want to use the opportunity as a sequel to last presentation where I was showing 01:16.080 --> 01:23.920 how ideal suited this hardware is to GNSS reception, that it's also an opportunity to get familiar 01:23.920 --> 01:30.080 with this field that I initially found a bit awkward still to actually about low-bit count 01:30.080 --> 01:38.400 A2D converters. And this will lead me to talk about NISAR, so in the introductory talk this morning, 01:38.400 --> 01:43.840 I told you it's been 10 years that we've been waiting for Israel and NASA to launch NISAR, 01:43.920 --> 01:51.440 which is an L and S band, and surprisingly enough, NISAR is broadcasting a few kilowatts of power 01:51.440 --> 01:57.520 right in the L band of GNSS. So on the other hand, it means that if we have a GNSS receiver, 01:57.520 --> 02:01.680 we have over hardware for receiving NISAR signals, and I'm going to show you, 02:02.480 --> 02:07.680 it's not going to be a passive radar image of the moon, sorry, it's not going to be on the radar image of 02:07.680 --> 02:13.680 moon, but I'll do what I can with hardware, I have, and the location I am in. So the two 02:13.680 --> 02:23.280 GitHub repositories, NISAR passive binary radar, and the FX12P, running the max 2771. 02:24.080 --> 02:37.040 So we've just been shown that regular astronomy, these guys are working with signals coming from far away, 02:37.520 --> 02:43.120 at 12 billion light years, so these guys here actually, I don't even know how to calculate the 02:43.120 --> 02:49.680 link budget because I'm missing the PEE, the aim is power equations. So where am I working with low 02:49.680 --> 02:54.960 bit-resolution A2D converter? The first one is the obvious one, it's one of the ones designed for 02:54.960 --> 03:00.560 its GNSS, just to recap if some of you are not familiar with the fact that GNSS is working 03:00.560 --> 03:06.000 below the terminal noise, it means that if you take a spectrum analyzer, you will not see the GNSS 03:06.240 --> 03:10.000 actually you're going to see an ugly little bump that you will cannot detect if you don't 03:10.000 --> 03:16.000 know where to look for. The reason being that if you just quickly do a link budget calculation, 03:16.000 --> 03:22.880 it's known that the GNSS satellites are broadcasting something like 50 watts at 1570 yards. 03:23.520 --> 03:30.800 So that's 47 dBm, from 20,000 kilometers away, and the reason why enjoy teaching space communication 03:30.880 --> 03:36.480 is that everything works as in theory, so you don't have any medium, you don't have any bounces, 03:36.480 --> 03:43.040 you don't have any, you just have energy conservation. So energy conservation also known 03:43.040 --> 03:51.040 in free space propagation loss or free situation tells you that you're losing 180 dB just by 03:51.040 --> 03:56.960 energy conservation by spread of energy over sphere, and then the antennas on the GNSS satellites 03:57.040 --> 04:04.240 are 13 dBi gain because they're not beaming all over the space, but somewhere towards the earth. 04:04.240 --> 04:09.360 So at the end of the day, due to the calculation, you get something like a GNSS power 04:09.360 --> 04:16.400 around minus 122 dBm, and if you integrate the terminal noise, so Boltzmann constant KB multiplies 04:16.400 --> 04:23.440 by TV temperature 300 Kelvin of the ground, multiply to that dBm per hertz, and you multiply this 04:23.520 --> 04:29.600 by the bandwidth because you know that your noise, your terminal noise is a flat over all bandwidth. 04:29.600 --> 04:35.680 So you multiply the terminal noise density by the bandwidth of two megahertz for GNSS L1, 04:35.680 --> 04:43.120 and you end up with minus 11 dBm. So the GNSS signal is 10 dB below terminal noise. 04:43.680 --> 04:50.480 Now what's, no, I must not skip that. So we're going to see later how you can extract the information 04:50.560 --> 04:56.240 from this noise. So this is one example where the energy, the information that you're looking for, 04:56.240 --> 05:02.560 is one tenth of a noise that you're recording. Another example of this is we were just told that 05:02.560 --> 05:08.240 in the radar equation, the link budget of a radar, you broadcast and your energy conservation says 05:08.240 --> 05:15.680 that you spread over a sphere of four pi d squared, so you have a one over d squared low, 05:15.840 --> 05:22.160 and then any target acting as a source is itself decaying as one over d squared, hence the 05:22.160 --> 05:28.320 one over d fourth power in the radar equation. So now in the free equation, you don't have a 20 05:28.320 --> 05:34.320 log of d, but you have a 40 log of d, the 20 log of f, the medium is not dispersive, it's just because 05:34.320 --> 05:39.360 the aperture of the antenna that you're receiving is one of the wavelength, so this is what you 05:39.360 --> 05:44.560 have a frequency coming in here. But if you look at a passive radar application where you have a 05:44.640 --> 05:52.240 television, a DVBT broadcasting station, which is something like, say, 500 megahertz as I have in 05:52.240 --> 05:57.440 in business on some, and I look at the target, which is 5 kilometers away, you receive something 05:57.440 --> 06:03.120 which is minus and 26 dBm, where the eight megahertz bandwidth of the broadcast stations for 06:03.120 --> 06:09.760 a television integrated noise, the noise integrated over this bandwidth will be something minus 06:10.000 --> 06:17.600 and 5 dBm, so even also on radar signals, you will get a signal that is 21 decibel below the 06:17.600 --> 06:23.920 terminal noise. So the question is, okay, I have something that is between 100 and 110th 06:24.720 --> 06:30.480 the signal that I've interested is 100 to 110th of the terminal noise, how am I going to 06:31.440 --> 06:37.040 get something useful out of this? And the core element, the core idea is correlation, you leave 06:37.040 --> 06:42.320 for correlations, because you know what you're looking for, it's a core aspect, for we just saw earlier, 06:42.320 --> 06:47.840 you have two radio telescope, looking at the same emitter, whether it's a quasar or something 06:47.840 --> 06:52.320 that's standing energy, because you know from one radio telescope what you're looking for 06:52.320 --> 06:58.000 on the other telescope, you can extract this information because noise is not coherent, 06:58.000 --> 07:02.640 so noise will average out because it's a random effect, and if you know that you have one 07:02.640 --> 07:09.760 common component in the signal, then these will accumulate. So looking for a known pattern in 07:09.760 --> 07:16.640 a noisy signal is called correlation. Correlation means I search for a time delay when the 07:16.640 --> 07:24.480 pattern matches in the signal that I'm looking for, and what happens is let's take the case of a 07:24.480 --> 07:29.840 GNSS signal or sort of random sequence where we say we broadcast plus and minus one, it's just 07:29.840 --> 07:36.000 easier to think of plus and minus one, that's zero and one, and this pattern that you broadcast 07:36.000 --> 07:43.840 is received on your receiver 10 or 20 decibel below the terminal noise, but you see that usually 07:43.840 --> 07:49.120 these quantities, this guy is mean value zero, this signal that you receive, if it's noise, it's 07:49.120 --> 07:53.520 mean value zero, so usually these will average out of zero, because you have some positive and 07:53.520 --> 07:59.360 some negative quantities. Except when all the positive overlap positive and all the negative 07:59.360 --> 08:05.680 overlap negative, then the square of the pattern that you broadcast, adds up as all ones, and when 08:05.680 --> 08:12.640 you sum these, you get accumulation over the n-chips that you broadcast in GNSS, you call beats 08:12.640 --> 08:18.160 the navigation, the chips are the absolute random codes. So at the end of the day, this means that 08:18.160 --> 08:25.040 by accumulating the n-chips that you broadcast the n random elements that you broadcast, you have a 08:25.040 --> 08:32.640 gain of 10 log of n and the number of chips. In the case of GNSS, the chip length of GFGNSS L1, 08:32.640 --> 08:39.280 the chip length is 1000 chips or 2023, meaning that you raise the energy during the correlation 08:39.280 --> 08:47.360 by 30 dB, and you were initially 11 dB below, after a correlation you rise 20 dB above, and this is how 08:47.360 --> 08:54.320 you gain the 20 dB range resolution between the chip rate and the actual resolution of GNSS. 08:55.040 --> 09:02.240 So you can do this a bit more analytically, but it's simply saying that you broadcast a single with 09:02.240 --> 09:10.880 unity amplitude, you receive a single with amplitude, you shrunk the amplitude due to the losses 09:10.880 --> 09:15.920 of the pattern plus some noise, and when you run the correlation, the mean value of this guy 0, 09:15.920 --> 09:23.440 the mean value will be 8 times n, because all the chips accumulate as 1, and on the standard deviation, 09:23.440 --> 09:28.640 this guy here will be sigma squared, the standard deviation of the noise multiplied by the n 09:28.640 --> 09:33.520 patterns here, because when you do the standard deviation, you take the square of the argument, 09:33.520 --> 09:38.720 and the square of p is 1, as we've stressed in earlier, so you have n times sigma squared, 09:38.720 --> 09:45.280 the standard deviation of the noise. So you take the t-netto noise ratio before you run the 09:45.280 --> 09:52.160 correlation, your signal is amplitude squared divided by sigma squared, and after the correlation, 09:52.160 --> 09:59.520 you see that we have now n times a times a squared n squared, because the amplitude has been 09:59.520 --> 10:06.160 magnified a times divided by sigma squared only n times. So the n squared on the numerator, 10:06.160 --> 10:11.360 does not cancel out with the n at the end of the day, but seems another ratio has magnified, 10:11.360 --> 10:17.440 where it improved n fold n the number of chips. One thing that was not completely clear to me, 10:17.440 --> 10:22.640 and this presentation of good opportunities to get deep into the topics, is, okay, this is 10:22.640 --> 10:28.800 when I know the pattern that I broadcast, and I'm listening, correlating the received signal 10:28.800 --> 10:35.360 with the ideal copy, local copy. But what about passive radar? In passive radar, you don't know 10:35.360 --> 10:40.320 what the guy is broadcasting, you have one antenna facing the reference, and one antenna facing the 10:40.320 --> 10:46.960 surveillance of the environment that is reflecting the echoes. And actually it happens that in this 10:47.600 --> 10:52.160 case, it's exactly the same story, except that instead of knowing the pattern, you observe the 10:52.160 --> 10:58.960 pattern, and because you observe a noisy copy of a pattern, you have a penalty due to the 10:58.960 --> 11:04.240 standard deviation that you add now. So you have a received signal, which is amplitude times 11:04.240 --> 11:09.440 pattern plus noise. But now the new thing is that pattern is not perfectly known, but is itself 11:09.440 --> 11:15.040 polluted with some noise. And I will not go from a details again with you, you can follow on the 11:15.840 --> 11:20.400 equations. But at the end of the day, instead of having an SNR, which is just the amplitude 11:20.400 --> 11:28.080 squared n squared divided by cglass squared, the noise power. Now you've got the sum of the 11:28.080 --> 11:35.040 listening noise, the reference noise, and the cross-product between the two. If there's physicist in 11:35.040 --> 11:41.040 room, if like me, you're shocked by the fact that we're having some fourth power and second power 11:41.040 --> 11:46.560 element in this equation, remember that this is because there is a unity that is hidden somewhere, 11:46.560 --> 11:51.520 I put it over here, because we said that the reference signal is unity amplitude. So actually 11:51.520 --> 11:56.640 you have one volt that is hidden somewhere. So this is not incorrect in terms of units. So at the end 11:56.640 --> 12:02.320 of the day, you see that even in a passive radar or in a regular astronomy, interferometry measurements, 12:02.320 --> 12:07.920 where you have your monitoring the observation of a reference signal, and it's a noisy copy of what 12:08.000 --> 12:14.080 you want to detect, you still get something that is proportional to n, despite the loss due to this 12:14.080 --> 12:21.760 questionnaire. And this is where actually if you're in a low signal to noise ratio context, 12:21.760 --> 12:27.760 which I'm interested in, where you see that instead of having a squared divided by cglass squared, 12:27.760 --> 12:34.400 now you have a squared divided by cm4, and that of course significantly degrees your capability. 12:34.480 --> 12:39.360 So this means a low signal to noise ratio means I'm looking at a reference, and this reference 12:39.360 --> 12:46.960 is itself heavily degraded by noise, which is not an ideal condition. So this is a context. So 12:46.960 --> 12:52.240 you have this poor thing to noise ratio, and you can get the signal out of the noise by correlating. 12:53.200 --> 12:58.880 But what about the idea? And if you want to try by yourself, I took a bit of time 12:58.880 --> 13:04.160 figuring this story out, and I'm not going to go through the octaves creep with you. But just to 13:04.160 --> 13:12.160 show you that, so these are examples where I take the L1000 chip loan code, this is the Galileo 13:12.160 --> 13:18.560 4000 chip loan code, this is L1000, which is 10,000 chip loans, actually plume, and I run exactly 13:18.560 --> 13:24.160 what I just told you. So I create a noise, which is a random and it's important to be a Gaussian 13:24.160 --> 13:29.600 distribution. Don't use I did the mistake, so I avoided it for you. Don't take the uniform 13:29.600 --> 13:38.320 distribution, take the motion distribution, you magnify the noise, you take the signal to noise ratio, 13:38.320 --> 13:42.400 then you run across correlation, and one thing that took me a bit of time to figure out 13:42.400 --> 13:47.280 between the units is whether you take the maximum of a correlation, because a correlation is the 13:47.280 --> 13:51.440 product of two voltages, so you think it's voltage squared, but actually it's like a projection. 13:52.320 --> 13:56.560 So you ended up having voltage, and you still need to take the square to have a power, so 13:56.560 --> 14:02.720 so you take the maximum of a cross correlation, you divide this by the variance of a correlation 14:02.720 --> 14:07.440 out of a correlation peak, and this allows you to demonstrate, so here I did it experimentally, 14:07.440 --> 14:15.680 you see here, this is the case of the minus 20 dB, so I would challenge you to tell me that in 14:15.680 --> 14:21.760 this noise there is a signal in the first 10,000 chips here, and yet on the cross correlation 14:21.760 --> 14:26.080 you really see nicely the cross correlation peak coming out, and I repeated the signal to 14:26.080 --> 14:32.400 noise ratio gain for various signal to noise ratios, for various chip length, so the various 14:32.400 --> 14:38.320 Galileo code and you see it matches, I'm still not clear why GPSL5 is not matching exactly, 14:38.320 --> 14:44.160 but you see it for the 1000 chip loan and 4000 chip loan, it matches perfectly, so you can try this 14:44.160 --> 14:49.760 if you want to get familiar. Okay, so we got the 100 capability of getting the signal out, 14:49.760 --> 14:57.200 but why isn't everyone just using a comparator, a comparator, a bit being, a 1 bit, a 2d 14:57.200 --> 15:03.760 converter, so in your traditional A2d converter analysis, you know that if you have a uniform 15:03.760 --> 15:10.160 window, if you have a rectangular window, you say between the two quantization bits, so between 15:10.240 --> 15:14.560 two and two pieces, one tubing, the bits of a quantization of the A2d converter, 15:14.560 --> 15:20.480 you say you have a uniform rectangular window, you calculate the variance inside this window, 15:20.480 --> 15:26.800 and you get quantization caused by the divided by 12, and if you take the logarithmic 15:28.000 --> 15:33.200 expression of this guy, you can go into the, into the tutorial from another device, which 15:33.280 --> 15:39.840 explains it's very well, you know that the signal to not ratio in A2d converter is six times 15:39.840 --> 15:47.280 the number of bits plus 1.676, and actually in the other way around, if you put a 60-ohm load 15:47.280 --> 15:52.800 on an A2d converter and you look at the Gaussian distribution, the width of Gaussian distribution 15:52.800 --> 15:58.240 will actually give you the effective number of bits in the B, which is the quantity n that matches 15:58.240 --> 16:02.800 the width that you observe on your, on your, on your gain. But when you have a very low 16:02.800 --> 16:10.640 things in other ratio, what is the point of quantizing the amplitude when all the amplitude 16:10.640 --> 16:16.000 in forms on the noise, there's hardly any information in the amplitude, and you have to think 16:16.000 --> 16:21.360 about, at least the way I think about the comparator of a little bit noise is that the information 16:21.440 --> 16:28.880 is held in two information, the amplitude and the time, the time, for example, where is very 16:28.880 --> 16:34.880 transition, and when you throw away the amplitude, you actually only throw away half of information 16:34.880 --> 16:38.400 because okay, if we don't care about the amplitude, we have a lot of things on other ratio, 16:38.400 --> 16:43.120 but we still have the time information, and this is actually where you get the information from, 16:43.120 --> 16:48.560 so if you were just to take this very, very rough analysis, we throw away the amplitude, we keep 16:48.560 --> 16:54.720 the time information, you would say I lost in my sense of not to issue 3 dB. If you actually 16:54.720 --> 17:02.080 do the detailed analysis and point at me to one flag, but I also find another one which was 17:02.080 --> 17:09.120 really good over here, which I found a bit easier to read, if you do a final analysis of this 17:09.120 --> 17:17.200 demonstration, you will end up having a 2 dB loss due to keeping only the time and throwing 17:17.280 --> 17:23.840 away the amplitude. I was wondering what does it mean when people say low as an hour, how do you 17:23.840 --> 17:31.440 define low as an hour? And if you look at the demonstration, how it's done, actually the assumption 17:31.440 --> 17:36.320 that is made is that on the denominator, when you do the signature noise ratio, you take the standard 17:36.320 --> 17:42.160 deviation and you need your standard deviation of a signal to be more or less equal to a standard 17:42.160 --> 17:50.320 deviation of a noise. So the actual detailed demonstration is a professor from MIT who publish 17:50.320 --> 17:58.240 this as a bus gang theorem, which apparently is the prequel to the Vomvlek paper. So these are 17:58.240 --> 18:04.080 all papers, you see from the 50s and 60s, as we were just told earlier, we were just reinventing 18:04.080 --> 18:10.560 what people knew, but in the context of SDR in this, in this, in this star here. So from, from this 18:10.560 --> 18:15.280 analysis, what you see is that when you have a high signal to noise ratio, obviously you will 18:15.280 --> 18:23.280 lose a lot by taking one bit or two bit to the converter, because six times 8 bit is 48 bit SNR, 18:23.280 --> 18:31.600 whereas with a one bit, I cannot get anything beyond 8 dB SNR. But if I start with very low SNR, 18:31.600 --> 18:37.120 what you see is that actually there is no benefit in adding BN, and the benefit of actually 18:37.200 --> 18:44.560 shrinking N is that if you have a given data rate, Bits per second times N, where you can put 18:44.560 --> 18:51.920 many more samples in a given data in a given pipe, if you have a small big number per sample. 18:53.280 --> 18:58.880 So that's a big analysis about this story, and what I want to show you now that people have 18:58.880 --> 19:04.320 not run away from the room after the theoretical introduction is that all these stuff, you can play 19:04.320 --> 19:10.400 with them, and you can actually use them in real life thanks to this chip. So this max 2771 for 19:10.400 --> 19:15.840 the remainder for those of you who are not here is an analogue device chip dedicated to L band 19:15.840 --> 19:22.640 reception, so L band 1.25 and 1.57GHz, because you either have to work, you must work, 19:22.640 --> 19:28.480 either in the upper or lower L band, it doesn't continuously cover the above upper and lower 19:28.480 --> 19:34.960 L band, initially it is a project developed by Tomoji Takasu of the Marine University in Tokyo, 19:35.680 --> 19:40.800 whose next purchase also the offer of RTK lip, and what Tomoji Takasu did was develop a 19:40.800 --> 19:46.720 pocket HDR, which this project is very much inspired from my only contribution has been to to use 19:46.720 --> 19:52.080 a cheaper Chinese board with the FX2 LP and to replace his proprietary compiler with an open source 19:52.080 --> 19:58.400 compiler. So that's a little bit of a story, so what I did is I assembled this max 2771 19:58.400 --> 20:06.080 board, and whenever you want to do radar, in radar you will connect one input here to a reference channel, 20:06.080 --> 20:13.840 one channel here to a surveillance channel to detect a time delay between echoes, but you can also 20:13.840 --> 20:20.560 do, you can also do with these spoofing analysis of genesis signals. For example, if there is a 20:20.560 --> 20:28.240 point like a meter that generates a signal that mimics a GNSS signal in a real GNSS constellation, 20:28.240 --> 20:33.600 all satellites must be spread over the celestial sphere, but if you have one spoofing source, 20:33.600 --> 20:37.360 then the direction of arrival for all the signals from all the satellites will be coming from 20:37.360 --> 20:42.080 the same direction, which is of course physically not possible. So there's a lot of reason why you 20:42.080 --> 20:46.720 would like to compare the phase, and this is all included the phase, so there's a lot of reason why 20:46.720 --> 20:52.400 you would like to compare the phase between these two inputs. And last year when I was presenting this, 20:52.400 --> 20:58.480 I was trolling thinking that it would be super easy to do this because you've got 2771, 20:58.480 --> 21:05.440 they're both clocked by the same oscillator over here, so this oscillator distributed to the two 21:05.440 --> 21:12.240 chips, why wouldn't they be running at the same rate? Well, simply because you go from the clock 21:12.240 --> 21:18.960 here, the quartz which is 24 megahertz to the L band by using a PLL phase lock loop. A phase 21:18.960 --> 21:27.440 lock loop compares the two input oscillators and locks the VCO on the input signal divided by N. The 21:27.440 --> 21:33.280 problem is that the set point, the phase of the set point is varying with environment, it's varying 21:33.280 --> 21:40.720 with a warmup, and in this case, for example, what's happening is that as the max 2771 is heating, 21:41.440 --> 21:45.040 you're going to see that the phase is actually drifting, so even though you have the same clock, 21:45.040 --> 21:50.400 the set point is shifting, so that the closed loop is actually shifting the phase of a PLL, 21:50.400 --> 21:54.400 so actually in a PLL, you know you're at the same frequency, but you don't know what phase you're at. 21:54.960 --> 22:00.000 So to demonstrate this, I took a putwise yard, now you know perfectly what it is, 22:00.000 --> 22:04.640 and on the putwise yard there, now it's a change name, it's no longer called putwise GPS, 22:04.640 --> 22:13.200 it's a SDR GPS. A very, there is a software for generating synthetic GPS L1 signal, 22:13.200 --> 22:20.560 the trends of the putwise yard. You run this on between two paths, so you split it between one path, 22:20.560 --> 22:26.240 you put a phase shift term, so just a piece of cable of our links. The other one is reference channel, 22:26.240 --> 22:31.840 and you see this to the pocket SDR. The pocket SDR sends you iQ streams and what you're going to 22:31.840 --> 22:38.160 do is compare the phase between these iQ streams. So initially I was super happy because I could 22:38.160 --> 22:43.920 measure, as I was shifting the phase between the two channels, I had a really good match between 22:43.920 --> 22:49.600 the observed phase and the expected phase from the phase shift term, manual phase shift term. 22:50.240 --> 22:53.840 And then I sent this to some colleague who tried to repeat the experiment and told me, 22:53.840 --> 22:57.200 yeah, I tried to repeat the experiments, I cannot get twice the same phase, 22:57.200 --> 23:02.000 well, how did you do this in the lab? And it's a fact that when I did this, it took me like 23:02.800 --> 23:09.680 10, 15 minutes, and probably I had the hardware running for a while before running the experiments. 23:10.240 --> 23:15.440 Because what happens is that if you look in the very beginning, how is the phase evolving? 23:15.440 --> 23:21.360 Well, the phase initially, this is, these are our terminal cameras images, so initially when you 23:21.360 --> 23:29.680 wake up the system, you're at 23 24 degrees, 28 year, and you start streaming your data, 23:29.680 --> 23:34.960 and you see here the phase is actually warming up. I don't even know why, but at some point 23:34.960 --> 23:40.240 it's suddenly jumps, it's always as much as one shot, it's always the same pattern. And then 23:40.240 --> 23:46.000 I get back to my phase and only after something like half an hour, do I see my phase stabilizing 23:46.000 --> 23:51.840 as the chip temperature reach 50 something degrees? So you see that you really need to get 23:51.840 --> 23:57.120 a phase reference to analyze and to measure the phase difference between the two receivers, 23:57.120 --> 24:02.400 which is exactly what I did here. It happens that when you're working at the L band of GPS L1, 24:02.400 --> 24:10.480 you write 1.57GHz, and you take one of these very low costs, 312.5MHz oscillators that you can 24:10.800 --> 24:18.160 find for a few euros, the fifth harmonic is at 1.56GHz, so write in the GPS L1 band. So what I'm doing 24:18.160 --> 24:25.680 is I'm periodically switching on this local oscillator, reading what's happening at 1.56GHz, measuring 24:25.680 --> 24:33.040 the phase, and it happens that I experimented very fast that when you reprogram the PLL, you don't 24:33.040 --> 24:38.400 lose the phase information that you detected. So now this is actually how this curve was observed, 24:38.400 --> 24:45.040 is that because now I have a reference phase, I can retry the phase of the max 2771. 24:46.160 --> 24:51.040 So this, why am I talking? Why do you even care about me caring about the phase? 24:51.600 --> 24:56.080 Well, because if you're attending here in the title, I put passive radar. So this is what I'm doing with 24:56.080 --> 25:00.880 passive radar, and this is where the phase is important. Because in passive radar, this is a 25:00.880 --> 25:05.280 experimental set up on my balcony. So my balcony, you cannot see it, but there is a TV 25:05.280 --> 25:10.720 transmitter that is illuminating the city of besong. It's something like 20 kilowatt from 5 25:10.720 --> 25:17.280 kilometers away, and I have one antenna, which is my reference antenna facing the TV transmitter, 25:17.280 --> 25:21.280 and the other one, what you want to do, ideally, you want to put them in opposite direction, 25:21.280 --> 25:26.160 but this is from my balcony. So if I look at opposite direction, that's inside my apartment. 25:26.160 --> 25:31.600 So here what I did is I basically tried to put 90 degrees and tried to put a null of a 25:31.680 --> 25:38.640 dipole in the direction of a TV transmitter. And what you see here, this is really recorded with 25:38.640 --> 25:45.440 the max 2771, except I needed to put a first frequency transposition, because I told you this guy 25:45.440 --> 25:52.080 is working at the max 2771, he's working the L-band, but TV tower is broadcasting at 600 megahertz, 25:52.080 --> 25:57.280 so you just need to make a frequency transposition with a local oscillator. So this is the reference 25:57.360 --> 26:02.800 channel, the surveillance channel, you've got a few artifacts, but overall you see the signal, 26:02.800 --> 26:06.960 and when you cross-correlated these two guys on a single measurement, you would have a hard time 26:06.960 --> 26:11.840 seeing anything else, but the direct signal, but as you accumulate more averages, you start seeing 26:11.840 --> 26:18.800 these guy coming out. So the difficulty in bi-static radar is it's bi-static, so the emitter is not 26:18.880 --> 26:26.800 collocated with receiver, so how do you analyze the location of this echo, and you can easily 26:26.800 --> 26:32.800 demonstrate that in a bi-static configuration, when you get an echo, it's not like in a 26:32.800 --> 26:38.240 monostatic just a sphere where you have your transceiver is at the center, and you look at the 26:38.240 --> 26:45.440 targeted at a range. So in a bi-static configuration, you have an ellipse with the emitter on one focal point, 26:45.520 --> 26:50.400 a receiver on the other focal point, and you get an ellipse, which is given by the time delay. 26:51.120 --> 26:57.120 And I actually would claim that the echo that you saw earlier is a building located over here, 26:58.160 --> 27:04.480 because when I look from my balcony, I just see here this, you can hardly see it, but it's a large building, 27:04.480 --> 27:13.360 with a large flat area facing the transmitter, so it matches pretty well, the distance and 27:13.360 --> 27:18.720 the shape, whatever I'm seeing from my balcony, but I cannot prove this unit, then a synthetic 27:18.720 --> 27:22.880 aperture, to ahead the asymmetric solution if you want to demonstrate this uniquely. 27:24.400 --> 27:30.480 So that's for passive radar, and when you're doing range resolution, when you're doing radar, 27:30.480 --> 27:35.920 you want to magnify the range, you want to improve range resolution, and the range resolution 27:35.920 --> 27:42.800 is the inverse of the bandwidth. So again, you have a lot of TV transmitters, we have a finite 27:42.880 --> 27:48.080 bandwidth, and no one said you need it to measure all the frequencies at the same time. 27:48.080 --> 27:52.960 If you have multiple broadcasting stations for the same location, you can very well measure the 27:52.960 --> 28:00.560 first spectrum, the second spectrum, and stack all this one over the other, which is exactly what 28:00.560 --> 28:05.440 I'm doing with the demonstration, but an assumption that you need to remember in your mind, 28:05.440 --> 28:11.440 when you're doing frequency stacking is the phases must be coherent. If the phase rotates, 28:11.440 --> 28:16.480 as you are accumulating the most of the successive spectra, then the energy doesn't accumulate 28:16.480 --> 28:20.960 anymore. So what I'm demonstrating here is these are all numerical simulations that you can do 28:20.960 --> 28:26.720 yourself. The blue curve is when I accumulate spectra at different frequencies, adjust and 28:26.720 --> 28:33.120 frequency ranges with coherence, so keeping the same phase. And if I start changing the phases as I 28:33.120 --> 28:37.680 accumulate the spectra, the energy doesn't accumulate coherently anymore, and you've got side 28:38.080 --> 28:42.240 loops. So again, another reason why these phase stability is so important. 28:43.600 --> 28:49.200 So I quickly earlier mentioned that you would like to move the antenna to get synthetic 28:49.200 --> 28:54.320 aperture radar, because with one point like radar, even in passive radar, you only have range 28:54.320 --> 29:00.080 information, and if you want to have azimity information, you need to move the antenna. And again, 29:00.080 --> 29:04.240 when you do azimity compression, azimity compression is inverse for a transform, 29:04.240 --> 29:10.720 along the position of the antennas, and if the phase rotates as you're moving the antennas, 29:10.720 --> 29:16.240 then the energy will not accumulate in the bin corresponding to the phase of the slope of the phase 29:16.240 --> 29:21.920 as a function of position of the antenna. So all the reasons justify why you need a phase that is 29:21.920 --> 29:30.800 table over time. Finally, these phase, we've seen a linear phase drift, but as I've been struggling 29:30.800 --> 29:39.520 for years about how to use the phase information in terms of radar performance. So one, one output 29:39.520 --> 29:44.400 that comes quite obviously is that when you're doing the cross correlation, if you have a cross 29:44.400 --> 29:52.800 correlation, which of a single that carries a copy of a code phase shifted, then the linearity 29:52.800 --> 29:58.240 of a cross correlation takes the phase out. So that is enough, and then you're going to try to see 29:58.240 --> 30:04.000 how this phase impact for cross correlation. Now, first of all, if your phase is not a constant, 30:04.000 --> 30:10.000 but it's something that is time-bearing, it's quite easy to see that the frequency of set integrated 30:10.000 --> 30:17.040 of a duration of a code must lead to a sine wave that is short with respect to the code duration, 30:17.040 --> 30:21.760 simply because the mean value of a sine wave is zero, and you can accumulate all the energy you want 30:21.760 --> 30:28.480 in the code, if a phase of a sine wave averages out to zero, then you will not accumulate energy. 30:28.480 --> 30:34.800 So first of all, what is traditionally known in GNSS acquisition phase is the frequency step 30:34.800 --> 30:39.520 must be much smaller, the frequency correction of the Doppler sheet, for example, must be much 30:39.520 --> 30:44.560 more than the inverse of the duration of the analysis. So this is when you have a systematic phase 30:44.560 --> 30:51.200 of set, but what about a random phase situation? And this is where Paul pointed me to the right 30:51.200 --> 30:58.080 place, which is how do you analyze the impact of the phase? I'm going to skip a few things 30:58.080 --> 31:02.400 because I'm running out of time and you don't really care about the relationship between phase 31:02.400 --> 31:09.840 and validation. I'm just going to go here to this point, which is this coherent function. 31:09.840 --> 31:17.280 So what I was pointed to in this textbook on the radio astronomy is that, okay, you've got 31:17.280 --> 31:22.560 a term, I just told you that if you just have a phase shift, then you want to avoid this a 31:22.560 --> 31:27.600 sine wave from averaging out to a correlation accumulation, but what about a random phase? 31:27.600 --> 31:34.080 Well one way of analyzing this is what is the integral of the phase situation over the duration 31:34.080 --> 31:39.120 of a code, and actually you take a standard deviation of this guy, because by doing this, 31:39.120 --> 31:45.760 when you get the phase differences between your receivers. And if you generalize this story here, 31:47.760 --> 31:54.240 I would be hard pressed to run the demonstration for you, but you will have these phase fluctuations 31:54.240 --> 32:00.080 here are actually described by a quantitative that is traditionally shared with you by oscillator 32:00.080 --> 32:07.040 manufacturers, which is called phase noise. A phase noise spectrum is how does the phase fluctuate 32:07.040 --> 32:14.720 at the given frequency offset from the oscillator of the carrier oscillator? And this is, 32:14.720 --> 32:21.680 if you replace the previous expression, the exponential of j phi minus phi prime, you get here 32:21.680 --> 32:29.360 the phase fluctuation of your oscillator, and you can put this inside your equation, and what I did 32:29.360 --> 32:35.360 here is I did numerical integration. So I know what is this quantity here, because I got it 32:35.440 --> 32:41.440 from the manufacturer of the oscillator. I can calculate the phase noise, I can calculate the 32:41.440 --> 32:46.720 given deviation, and the big novelty here with respect to the people doing radioastronomy is, 32:46.720 --> 32:51.920 when you're doing, we just saw radioastronomy are interested in integration times between second 32:51.920 --> 32:57.680 and hours. When I'm doing radar, remember your broadcasting at free, you're propagating at 300 32:57.680 --> 33:04.720 meter per microseconds. So a target, which is 1.5 kilometers away, is only 10 microseconds away. 33:04.800 --> 33:09.280 So the big difference between with the people of radioastronomy, radioastronomy people, 33:09.280 --> 33:14.080 they think in alien deviation, because they think in duration of seconds to hours. 33:14.080 --> 33:20.640 But when you're doing the radar analysis, you actually don't use this sentence from the 33:20.640 --> 33:27.200 radioastronomy textbook that says, SY is not of not available. It is to us, because we're not 33:27.200 --> 33:32.640 looking at carrier offset of the fraction of the millihertz, but we're looking at frequency of 33:33.280 --> 33:37.840 kilohertz to megahertz, which are the inverse of milliseconds to microseconds. 33:37.840 --> 33:43.520 And so you can actually integrate numerically this quantity, and this is the coherence loss. 33:43.520 --> 33:49.760 So someone asked me earlier, how high infrequency can you operate your wiretrabbit story 33:49.760 --> 33:54.560 where the wiretrabbit will generate phase situation, and what you see is that as long as you're 33:54.560 --> 34:01.760 working in the DHF, the UHF, or even up to C-band, this phase situation will hardly have any effect 34:01.760 --> 34:06.800 on your correlation capability. It's only when you start going into very high, so this is 100 34:06.800 --> 34:12.880 gigahertz, this is 200 gigahertz, then you have a cutoff frequency when you start really losing coherence 34:12.880 --> 34:18.560 due to the phase situation. So this is really the end of a story that I wanted to renew is 34:18.560 --> 34:26.640 the max 2771 allows you to test experimentally some sort of rather awkward mathematical 34:26.640 --> 34:34.000 concept that might otherwise be less fun to analyze. So let me finish with whole story 34:34.000 --> 34:40.480 by telling you, I started by saying we wanted to receive Nissan. Nissan has been launched in July, 34:41.120 --> 34:47.040 and actually as opposed to the European Space Agency, which broadcast the flight plans and 34:47.040 --> 34:53.600 the observation plans, so you can download the KML file and just watch when is a Sentinel one going 34:53.600 --> 34:58.720 to eliminate your area, Nissan, you have no such information, so you need to go back to basics. 34:59.040 --> 35:09.360 What do we know from Nissan, Nissan is flying 747 km high, the beam, so the radar beam is emitted 35:09.360 --> 35:16.240 on the side at an angle of about 40 degrees plus or minus 7, and it took me a bit of time to figure 35:16.240 --> 35:23.040 out why I was not receiving anything, and Nissan is the only space-borne radar, which is not right 35:24.000 --> 35:29.840 Nissan is the only satellite beam into the left, and actually took me some time to find this, 35:29.840 --> 35:35.520 it's not even an article, it's just a natural opinion, and it was written in this natural opinion, 35:35.520 --> 35:40.480 it was really looking for a story, why can't I see anything, and you've got this opinion that says, 35:40.480 --> 35:46.400 all the synthetic upper radar are facing to the east, because all the countries manufacturing 35:46.400 --> 35:50.800 radars are in the northern hemisphere and are interested in North Pole, and if you look at how 35:50.880 --> 35:56.160 the orbits are going, when you beam to the right, you beam towards the North Pole, and so 35:56.160 --> 36:00.640 it's sure that NASA decided that there was already so many satellites looking at the North Pole 36:00.640 --> 36:04.480 that there would be looking to Antarctica, and to look at Antarctica you need to beam to the left, 36:04.480 --> 36:08.640 so that's the reason, so it took me a bit of time to figure out why I was not reaching anything, 36:08.640 --> 36:17.920 and then there was a recently published, this is IEEE 2020, so June 2025, 36:18.000 --> 36:23.040 because the frequency plan of news are it's very misleading when you just look at the 36:23.040 --> 36:29.200 east row and NASA websites, this is written the first offer is one of the principally disgear, 36:29.200 --> 36:34.400 so you can trust this frequency plan, and basically what they do is they have this 36:34.400 --> 36:41.120 frequency plan, because it's not bothering too much GNSS, but still split enough to be allowed 36:41.120 --> 36:47.520 to measure ionosphere today, so to make a long story short, you calculate the orbit, 36:47.600 --> 36:53.040 you calculate the angle, you predict that in order for my location in Paris to be eliminated 36:54.240 --> 37:01.840 two sites that are at the right angle, at the right time are over Britain and over Germany, 37:01.840 --> 37:07.440 and half of the paths are useless because you're being on the wrong side, so you must be 37:07.440 --> 37:13.120 ascending, beaming to the left, or you must be descending, beaming to the right, if you're descending 37:13.120 --> 37:18.080 and you're to the east, then you're illuminating Germany, and I'm not interested in Germany here, 37:18.800 --> 37:24.560 so you do the calculation to where when these are going to fly, you check on heaven's above 37:24.560 --> 37:30.960 and heaven's above tells you, indeed, Nissan will be at the maximum altitude with one second 37:30.960 --> 37:35.920 resolution, that's important because Nissan is illuminating you for only five seconds every 12 37:35.920 --> 37:40.800 days, when you miss it, you have to wait another 12 days, and it tells you what is the elevation, 37:41.760 --> 37:49.040 so you get this, and well actually that was not my Christmas gift because on the day of Christmas 37:49.040 --> 37:55.360 I looked at the beam in the wrong direction, and that's actually when I discovered, so I actually 37:55.360 --> 38:00.720 had discovered the nature paper in the evening of Christmas as I had just spent half an hour outside 38:00.720 --> 38:05.920 and not getting anything, and so I repeated the measurement on the 27th of December, and with this 38:05.920 --> 38:13.280 new information that will beam on the wrong side, this is actually Nissan, it's a 10 minute long 38:13.280 --> 38:18.400 record because I was not completely sure that we would be beaming at the maximum elevation we are, 38:18.400 --> 38:24.000 so here you can see this is actually the signal magnitude and auto correlation, if I zoom into 38:24.000 --> 38:30.720 this region, this is when Nissan for four seconds is illuminating my region, now one of the challenges 38:30.720 --> 38:35.520 of Nissan, and I will not, this is just a teaser for my next presentation, maybe by the end of the year, 38:35.600 --> 38:42.320 one of the challenges is Nissan is using a non-uniform non-constant pulse repetition interval, 38:42.320 --> 38:47.840 it has to do with their very broad beam, I don't understand the details, why they did it, but it's 38:47.840 --> 38:52.720 a fact, and the first offer of the paper I cited earlier confirmed to me that this is a fact, 38:52.720 --> 38:58.720 I repeated the measurements, it's just not just one shot, this was repeated in January 3rd, 38:58.720 --> 39:04.320 on January 3rd, and here you see the chirp that was recorded as Nissan was illuminating, 39:05.200 --> 39:09.520 now, I'm very disappointed because I saw you that I would be listening to Nissan using the 39:09.520 --> 39:16.800 maximum 1771, this is all done with a B210 SDR, I did the measurement with a maximum 1771 39:16.800 --> 39:22.880 any failed, so I will not show you the failure, I don't know yet why it failed, but just to show you 39:22.880 --> 39:27.360 what we can actually get, and I will not get in the details because I'm well beyond the time, 39:27.360 --> 39:33.120 but again as another teaser for my next presentation, if you've got two antennas, one facing 39:33.120 --> 39:38.000 towards Nissan, one facing the opposite of Nissan, then you can look at the backscattered 39:38.000 --> 39:43.840 echoes from the surrounding, and this is a passive radar image, that was acquired in B210 39:44.640 --> 39:49.920 on the 7th of January, this is, so when you're doing passive radar, you have no degree of freedom, 39:49.920 --> 39:54.240 the range resolution is determined by the bandwidth, the asymmetric resolution is determined 39:54.240 --> 39:59.120 by the post repetition interval and the speed of a satellite, and what you see here are all the 39:59.120 --> 40:04.320 echoes I detected over a digital elevation model of the region I live in, these are 40:04.320 --> 40:09.360 cliffs, large cliffs, that reflect very well, and you see that all the reflectors match the 40:09.360 --> 40:14.080 heels in the surrounding areas, so this will be for my next presentation, I'll get in the details 40:14.080 --> 40:20.080 of how to do passive bastardic radar using the Nissan satellite signal. So as a conclusion, 40:20.080 --> 40:27.280 I wanted to show you how we addressed the loss or the benefits of low resolution A2D converter, 40:27.280 --> 40:33.360 I tried to show you how we addressed phase situation, whether we are due to low-collocillator 40:33.360 --> 40:40.240 drift or random situations, and I showed you how we could collect Nissan signal and we have yet 40:40.240 --> 40:46.560 another signal source. If you want to extend to even higher frequencies, everything I told you works 40:46.560 --> 40:53.600 exactly the same in the KU bands, you just put one of these LNBs, I tried to doing this with 40:54.240 --> 40:59.440 a starting, someone asked that I was starting, now I have a very hard time receiving the 40:59.440 --> 41:05.040 starting beacons, and on the internet you see all these people receiving starting, and I believe 41:05.040 --> 41:10.320 I might be wrong, but I believe that most of these reports of starting measurements are from 41:10.320 --> 41:16.240 Eastern Europe close to Ukraine where we know that starting is very popular, and the starting footprint 41:16.240 --> 41:21.440 is only 20 kilometers wide. So what I believe is that in my area and there's some 41:21.520 --> 41:25.680 so few people are actually using starting that there is hardly any time that the satellite is 41:25.680 --> 41:32.000 been in my direction. I believe this is one of the beacons that was recorded, I did many recordings 41:32.000 --> 41:37.040 that's the only one that looks more convincing, but yeah you can actually use the same set 41:37.040 --> 41:43.840 set for receiving starting or geostation satellite. In this space with this, I thank you for 41:43.840 --> 41:55.920 attention, and I conclude this presentation. Thank you. 41:55.920 --> 42:01.600 This also concludes the last session of the SDR Devroom. Thanks to all of you for coming 42:01.600 --> 42:04.800 so numerous of the whole day.