WEBVTT 00:00.000 --> 00:14.000 A sequel to Tristan's presentation about white rubbit, and one reason I wanted to complement 00:14.000 --> 00:22.640 what he says is not everyone has access to certain and to a high-energy accelerator. 00:22.640 --> 00:29.760 And I've been involved more or less in this white rubbit stuff for a dozen years now, and 00:29.760 --> 00:34.000 I got obsessed because part half of my activities research, but the other half of the 00:34.000 --> 00:39.840 activities teaching, and I got obsessed with how can I get students or how can I get people 00:39.840 --> 00:46.840 outside of this very dedicated team of certain researcher and developers to use this 00:46.840 --> 00:48.840 white rubbit. 00:48.840 --> 00:55.680 And so what I want to show you is a path towards using white rubbit on general purpose 00:55.680 --> 00:58.600 as the arts and engineering purpose of PGA. 00:58.600 --> 01:03.600 I should emphasize this work I'm presenting is the work of my colleague and student 01:03.600 --> 01:11.760 Emilia Duku, who's working for the last 18 months from this topic at our 10-20 01:11.760 --> 01:16.720 institute, and I should emphasize also the invaluable work when has been a colleague of mine 01:16.720 --> 01:18.560 for more than 10 years. 01:18.560 --> 01:23.920 Now he's joined the company in Brittany, Western France, and they worked in the company 01:23.920 --> 01:29.120 and joined the institute on a high level abstraction language, which is called Leitex, which 01:29.120 --> 01:35.200 tries to wrap hardware description in Python Leite language, and he's wrapped white rubbit 01:35.200 --> 01:36.200 in Leitex. 01:36.200 --> 01:38.360 So that makes what they've opened so much easier. 01:38.360 --> 01:42.800 Emilia has actually come from computer science, and I realize that computer science 01:42.800 --> 01:47.920 people are much more valuable than electronic engineers in white rubbit because obviously 01:47.920 --> 01:54.360 the problems are more on the computer science side than on the electronics. 01:54.360 --> 02:00.600 So just as a quick outline, I would like to mention why I'm using white rubbit for software 02:00.600 --> 02:05.840 fan radio, just a quick application example, so you know what we're talking about, what 02:05.840 --> 02:11.600 are the requirements, why would you not be able to just take any board of a shelf and use 02:11.600 --> 02:17.920 white rubbit and how we can actually can with degraded performance. 02:17.920 --> 02:23.640 I'll show you what are the current status of these developments that Emilia did and some 02:23.640 --> 02:27.200 of results that we obtained. 02:27.200 --> 02:33.720 So Tristan just showed you these white rubbit switches, so this is one white rubbit switch, 02:33.720 --> 02:37.960 this is another white rubbit switch, and the context in which I'm using these white rubbit 02:37.960 --> 02:40.400 switches is in distribute radar. 02:40.440 --> 02:46.320 So in the case of Tristan, he's interested, like all the third people, in knowing where 02:46.320 --> 02:51.040 the beam, and I think one part that maybe Tristan forgot to mention, maybe it's obvious 02:51.040 --> 02:59.320 to everyone, but the speed of light is 300 meter per microseconds, and this means that 02:59.320 --> 03:04.600 if you've got two places separated by more than 300 meters, unless you have time of flight 03:04.600 --> 03:08.680 compensation or two-way time of flight measurements, you will not get better than the microseconds 03:08.680 --> 03:09.680 compensation. 03:09.680 --> 03:17.120 And Tristan just said we wanted to have a subtense of picoseconds, so in the case of distributed 03:17.120 --> 03:22.760 radar systems, it's the same story you have a radar array, but since what is incoming 03:22.760 --> 03:28.700 on these antennas is light or electromagnetic waves, the only way you can have a coherent 03:28.700 --> 03:33.880 analysis is if you know what is the phase of these two locations. 03:33.880 --> 03:41.600 So in this example, you've got two high-end HS research x-rethens, and what's so this is 03:41.600 --> 03:47.840 what I use for my VHF radar, I happen to be leaving close to the French grav radar, which 03:47.840 --> 03:52.640 is the one that's going to add up to the space surveillance radar, and it just happens 03:52.640 --> 03:59.240 to be at 143MHz, very easy to get with HS researchers x-rethens, so what I have here is 03:59.240 --> 04:06.180 four antennas, it's four monopole antennas on the roof of a lab, directly going into these 04:06.180 --> 04:09.640 radio-frequency amplifiers and feeding VDAs yards. 04:09.640 --> 04:13.400 Now here you might say, okay, you've got your two SDRs, one next to the other, why do you 04:13.400 --> 04:14.400 need synchronization? 04:14.400 --> 04:19.000 Because this is a mock-up setup where at the end of the day I want to separate these 04:19.000 --> 04:25.680 two antennas by more than one kilometer to make an aperture, an equivalent aperture of 04:25.680 --> 04:29.200 one kilometer, and so this one is going to universe. 04:29.200 --> 04:32.800 First TV is one thing over here, one of the SDRs going to university, the other one 04:32.800 --> 04:39.840 is saying the lab, and this two location will be separated by 10 kilometers, by one kilometer. 04:39.840 --> 04:44.800 So what you don't see here is that you've got two optical fibers, one feeding this switch, 04:44.800 --> 04:49.320 the other is feeding this switch, and there's a really already two kilometers going from 04:49.320 --> 04:53.200 the lab to the university and the actual lab, so this is, so why do I say this is 04:53.200 --> 04:54.200 to be stupid? 04:54.200 --> 05:01.360 Because you've got these X3-tens, they take its inputs, 10 megahertz and one PPS, one post-perseconds, 05:01.360 --> 05:05.520 and these wide traffic switches, they generate 10 megahertz and one PPS, so my interface 05:05.520 --> 05:10.280 between the SDR and the switches is one PPS and 10 megahertz. 05:10.280 --> 05:14.880 But so first of all, these are not completely cheap, there are something like 2500-year-old 05:14.880 --> 05:16.880 piece. 05:16.880 --> 05:22.880 The SDRs that you can synchronize on one PPS and 10 megahertz are insanely expensive for 05:22.880 --> 05:28.720 no reason, but just because you can very, very high level, the X3-tens they used to be 5k 05:28.720 --> 05:34.120 euros until a few years ago, last time I looked at very 11k, I don't know where the two 05:34.120 --> 05:39.680 fold appeared, and so what you really would like to have is to integrate wide traffic 05:39.680 --> 05:47.200 inside your SDR and hopefully do this with a sub-k-urror SDRs and not with, so I had 05:47.200 --> 05:51.360 to look on the National Instruments website, National Instruments, of course, they understand 05:51.360 --> 05:55.600 the benefit of wide traffic and they did implement wide traffic in some of the hardware 05:55.600 --> 06:00.360 and your entry level is 30k and then you go for the N3-tens which is 20k, then you go for 06:00.360 --> 06:06.640 N3-21 which is 27k and then you go for the X4-tens, okay, then you add more and more zeros. 06:06.640 --> 06:12.160 So it's really stupid because who's going to use a 20k SDR in this room, I mean most 06:12.160 --> 06:18.720 certainly you want to be running this on more accessible hardware, so this is really 06:18.720 --> 06:24.400 my objective, how can I get this running on affordable hardware? 06:24.400 --> 06:30.600 Now you might know the red pitaia, we're using this very much in the lab, one reason it 06:30.600 --> 06:36.680 can be obtained of a shelf, we have a at the moment reliable source of red pitaia, secondly 06:36.680 --> 06:42.960 is your familiar with the red pitaia, everything's clocked by, so we have a temperature control 06:42.960 --> 06:48.560 simulator at CCXO which clocks the FTA and to stay on the same clock domain in the FTA, 06:48.560 --> 06:55.120 the A to D converger is feeding the clock to the FTA, but what you can do is unsolder two resistors 06:55.120 --> 07:00.520 and feed 125 megahhertz through two pins and our cage we feed 125 megahhertz for 100 07:00.520 --> 07:05.400 and meters, so we can have our red pitaias driven by the common clock, ultra-sable clock 07:05.400 --> 07:07.880 that's driving all the experiments in the lab. 07:07.880 --> 07:13.320 Unfortunately, the red pitaia does not, we have not found a way of plugging in an SFP to the 07:13.320 --> 07:18.760 best of my knowledge that pins needed for a service connecting the SFP are not exposing the 07:18.760 --> 07:25.760 red pitaia, so it's not an easy target to connect to, so what can we try to use to disseminate 07:25.760 --> 07:30.080 white rabbit to a broader audience, so first of all why do you actually need to govern 07:30.080 --> 07:37.440 and do something, so to start show you a high level description of white rabbit, so what 07:37.440 --> 07:44.000 you would like to achieve is something that generates high timing resolution and if you remember 07:44.000 --> 07:50.480 time and phase are closely related for a carrier frequency, phase equal to FTAO, so if you 07:50.480 --> 07:55.320 want to have a high timing resolution you need a high phase resolution and if you want 07:55.320 --> 08:00.800 to have a high phase accuracy and high resolution measurements, the trick that was proposed 08:00.800 --> 08:04.400 is the white rabbit, so this is the paper by Raviye who is sitting at the end of the room 08:04.400 --> 08:10.520 here, so the trick is to do time stretching, time stretching means to try to generate 08:10.520 --> 08:16.200 a bit note and the bit note will be affected by the same phase effect, but you magnify 08:16.200 --> 08:24.520 this measurement, it's called DMTD and this DMTD technique requires two oscillators, I'm not 08:24.520 --> 08:28.720 going to tell you why, I'm not even the best person to explain you why, but the fact 08:28.720 --> 08:34.520 is that you need two oscillators and if you look, you put here n equals two to the 14, 08:34.520 --> 08:39.520 two to the 14 divided by two to the 14 plus one, create two bit notes which are a few 08:39.520 --> 08:45.800 kilohertz apart, so you're feeding this clock with 62.5 or 125 megahertz input and you have 08:45.800 --> 08:52.840 two copies that are offset by a few kilohertz, a ratio of a carrier frequency to this offset 08:52.840 --> 08:57.680 gives you the magnifying capability and thanks to this magnifying capability, you have 08:57.680 --> 09:01.600 a fine phase measurement, so you have a fine time of flight measurement and you've got 09:01.600 --> 09:07.960 the fine compensation capability, so what does this mean if you take from the same publication 09:07.960 --> 09:12.280 but you take any of the hardware that is white rabbit compliant, you need here, it's a 09:12.280 --> 09:17.320 bit blurred but you need external oscillators, you need this external voltage control 09:17.320 --> 09:22.080 crystals later, this is XO's, which will be driven by the white rabbit algorithm to 09:22.080 --> 09:29.400 find one of them will be tracking the incoming frequency that you want to replicate and 09:29.400 --> 09:34.720 the neighbor will be tracking the same frequency slightly frequency offset, so it means 09:34.720 --> 09:40.960 that at moment white rabbit is limited only to hardware that is fitted with these two 09:41.000 --> 09:47.600 external oscillators, now for a lot of years, for quite a few years I've been using ordering 09:47.600 --> 09:53.120 and using some of this hardware and I've grown very frustrated because I think there's 09:53.120 --> 09:58.000 maximum 12 people in the world using this hardware, this means that one of the hardware 09:58.000 --> 10:02.120 is not maintained, basically when I figured out how to use it I was to this one is outdated 10:02.120 --> 10:06.720 you need to learn how to use the new one, so now I have a whole pile of paper weights, 10:06.720 --> 10:13.680 which are the generations of this pegboard and what ended up driving the final name, the 10:13.680 --> 10:18.200 coffin of the pegboard was when we finally get this two-pin-fim working after four or five 10:18.200 --> 10:23.280 years of work we realized that the daughter board was running on the free running oscillator 10:23.280 --> 10:32.280 which was not locked on the white rabbit, that was a long time to discover this story, 10:32.280 --> 10:38.320 so to tell the complete story completely I'll show you the time line, so this is the 10:38.320 --> 10:43.360 time line, just to show you that this is not a 10-minute experiment, we started using white 10:43.360 --> 10:48.720 rabbit a 10-to-ST, around 2014, I'm not exactly sure what was the exact date, but around 10:48.720 --> 10:55.120 this time we were consumers, so we basically have two sites in the Zonson area in France where 10:55.120 --> 10:59.560 we have seasoned clocks and we have hydrogen mazers and they're not colocated, so we wanted 10:59.560 --> 11:03.720 to compare them and it was decided to use the white rabbit for comparing a seasoned clock 11:03.720 --> 11:11.640 and hydrogen mazers, so this was a consumer, great users, but I wanted to learn how to use 11:11.640 --> 11:15.240 this device and how to develop this device from the very beginning we wanted to become 11:15.240 --> 11:20.840 developers, so basically when I said five years from 2018 to 2023 we started learning how 11:20.840 --> 11:25.320 to use this stuff and when you're not sitting at sure next to Tristan or not his next 11:25.400 --> 11:32.440 who is developing team, the learning curve is a bit steep, they love branches, they spread 11:32.440 --> 11:36.120 branches in their gate, they repository everywhere and when you're not sitting next to them 11:36.120 --> 11:42.080 to ask them what is this branch, it's hopeless, and so then in 2023 we got this white 11:42.080 --> 11:47.960 rabbit tree distribution functional and we realized that this 8-to-deconvertor was free 11:47.960 --> 11:54.360 running and to tell you the first story, the really game changer was when the certain 11:54.440 --> 11:59.320 team hosted us for a week, they were really kind, as we were changing emails and we said 11:59.320 --> 12:02.840 it's hopeless, we cannot figure out why this 8-to-deconvertor is not being locked when white rabbit 12:02.840 --> 12:07.240 is being locked and we went to certain and Tom looked at our board and he said of course 12:07.240 --> 12:12.600 so your oscillators are free running, how what do you expect and after a couple of days Tom 12:12.600 --> 12:17.960 and Tristan managed to get the second oscillation locked on the white rabbit so it made 12:17.960 --> 12:22.920 created a new phase lock loop and then eventually when we went back to business soon we tried to 12:22.920 --> 12:26.520 reproduce because they created a new branch of course and when we went back to business 12:26.520 --> 12:30.840 soon we tried to reproduce and we never managed to and I must admit this is a point where 12:30.840 --> 12:36.040 I said okay we give up because we're never going to get there, okay so we gave up that Tom 12:36.040 --> 12:41.640 and Tristan gave us a very precious information when we visited certain of this time and 12:41.640 --> 12:45.960 and maybe they don't realize how important what they just said at the coffee break at the end was 12:45.960 --> 12:52.040 maybe there's a trick where you can use a general purpose FPGA and some of internal 12:52.600 --> 12:57.480 capabilities we're not doing this at all because it's going to get you a crappy white rabbit 12:57.480 --> 13:01.480 but if you just want to play with it maybe it's going to be just good enough to get white 13:01.480 --> 13:06.280 rabbit running and this really got me thinking can we put white rabbit in a general purpose 13:06.280 --> 13:11.160 if you are because we're not accelerating 7 giga electron volts a proton we're just listening 13:11.160 --> 13:18.200 at radar signals it's 143 megahertz it's good enough for us so that that kept on on on on 13:18.200 --> 13:23.960 on speeding on the back of the head and then the second breakthrough every year Ravi and his 13:23.960 --> 13:29.960 group organized white rabbit workshop at CERN and in 2024 there is a German company called 13:29.960 --> 13:35.480 missing link electronics who demonstrated that they could run white rabbit using the internal 13:35.560 --> 13:42.680 phase lock loop of the recent FPGA and that gave us the missing step that we're an 13:42.680 --> 13:46.840 interestingly enough missing link electronics did this initially to integrate white rabbit in the 13:46.840 --> 13:53.640 X310 so so this gave us the little key that we needed to actually get white rabbit running 13:53.640 --> 14:00.920 into our own FPGA and then went and flew on at Android Digital happened to be funded by 14:01.000 --> 14:06.600 Crayotech, Polish company manufacturing white rabbits which is to wrap white rabbit into 14:06.600 --> 14:11.880 light text language and now we've got all this working because they also built SDR so that's a little 14:11.880 --> 14:18.760 bit of the timeline so that you know how how long it took to get there so this is this is the N2SDR 14:18.760 --> 14:26.200 from light from Android Digital this is a very cheap acorn you might know it it used to be 14:27.160 --> 14:33.240 sold over the internet for Bitcoin mining and Android Digital has a few of them for sales 14:33.240 --> 14:39.960 the N2SDR is basically a B210 but where the B210 has inflated to 2000 euros now this 14:39.960 --> 14:45.640 is 2700 euros and it's an N2S M2 format so I really encourage you to have a look at this 14:46.280 --> 14:52.280 and what you see is that Android Digital is providing in addition to their FPGA boards 14:53.240 --> 14:58.120 a daughter board PCI Express with 2SFPs so we've got everything that just 14:58.840 --> 15:03.640 three staunch orders with got the SFT with got the FPGA and let's try to see what what we get 15:03.640 --> 15:10.760 running so just if you would like to get into this story here you have to realize that white 15:10.760 --> 15:16.440 rabbit is made of gateware parts running on the FPGA it's called white rabbit cores and then you've 15:16.520 --> 15:21.960 got the soft core which is now reached by CPU soft core and you've got the white rabbit 15:22.760 --> 15:29.960 ptp core software which is plain c I'm only understanding the plain c the white rabbit 15:29.960 --> 15:34.600 port is a part that immediately I'm working on so if you want to get started you actually 15:34.600 --> 15:39.880 start by taking one of the examples from white rabbit cores and wait at least this is what 15:39.880 --> 15:46.360 immediately I did and you tune so most common FPGAs are there is one board that is waiting 15:46.360 --> 15:51.160 being supported either by certain of one of the other accelerators or networked 15:51.160 --> 15:55.880 particularly detectors participating to white rabbit project so you start from one of these 15:55.880 --> 16:04.280 examples and what you what we did here is they changed the external DCXO with the internal 16:04.840 --> 16:12.680 oscillator as advertised by the DCXO and once you change the internal oscillator well of course 16:12.680 --> 16:18.360 you will need to find you in a little bit the phase of loop because your ptp control the coefficients 16:18.360 --> 16:24.440 will will be somewhat different so actually the even though the software framework 16:24.440 --> 16:29.800 looks very impressive when you end up looking at what you need to port white rabbit and a new board 16:29.880 --> 16:35.880 you really need to look at the hardware description where the surface are located 16:35.880 --> 16:42.360 and what is the oscillator that is clocking the ptp core and then tuning the soft PLL 16:42.360 --> 16:50.120 in the WRPC software. Now there is no there is no mystery I'm not going to claim 16:50.120 --> 16:57.480 set 10 picosecond as a 3-star uses at 3rd using this crappy hardware we're going to get something 16:57.480 --> 17:05.800 in another second range so degraded 100 fold so that the challenge is as I understand it is that 17:05.800 --> 17:11.960 your internal oscillator inside your FPGA has a lot of natural phase noise and what we 17:11.960 --> 17:19.080 realize recently has many more spurious mode spurs and these spurs are alias back into 17:19.080 --> 17:24.200 into baseband because this ddmtd is only made of flip-flops there is no loop as filtering anywhere 17:24.200 --> 17:28.680 and so it means that your alias in the 60s to make a hertz whatever you have inside the 60s to 17:28.680 --> 17:34.680 dot 5 megahertz into the big note which indicates about 4kHz and all this energy alias back 17:34.680 --> 17:39.880 when it accumulates a stage noise and phase noise we just said is time situation so that's the reason 17:39.880 --> 17:44.520 so so now what we're working on is how can we either get rid of this spurs which seem to be 17:44.520 --> 17:50.600 the driving contributor or how can we use different techniques of fine-tuing the oscillator 17:50.600 --> 17:56.520 inside the FPGA to avoid creating this previous mode so the hardware that we're looking at 17:56.520 --> 18:03.960 are these two hardware sold by Android Digital it's the 3 2015 plus which if I remember what 18:03.960 --> 18:09.560 it's 100 something euros no HDR no radio frequency front end but it gets you started and the 18:09.560 --> 18:16.600 end to HDR 700 euros which is basically a d210 it's an 189361 plus a big FPGA on the back 18:17.480 --> 18:25.640 so we spent a bit of time working on the acorn because that was my my key objective for teaching 18:25.640 --> 18:30.200 for teaching my students I would have a hard time telling the university of course I have a 18:30.200 --> 18:37.240 very hard time telling I need 15 boards and 10 kPs but even saying that I'm going to buy 15 boards 18:37.240 --> 18:43.000 at 700 piece which we're doing with the red pitaya takes a few years to accumulate the hardware 18:43.000 --> 18:47.960 while the acorn at 100 euros so in one year I can get over hardware to get all my 18:47.960 --> 18:53.080 lapsetion running now what we realized is if you're a little bit if you follow the 18:53.080 --> 18:57.640 little bit time frequency developments everyone's been saying for decades quartz is the only 18:57.640 --> 19:03.400 way to go and there is no never going to be any replacement for quartz oscillators and now for 19:03.400 --> 19:08.200 about 20 years there's a couple of companies from the US from California who've been advertising 19:08.360 --> 19:13.720 that you could use silicon resonators instead of quartz which of course in our field is heretic 19:13.720 --> 19:18.440 you're never allowed to save a silicon with bead quartz but the fact is that commercially 19:18.440 --> 19:23.480 the guys from ac time they're just flooding the market with with a reprogrammable oscillators 19:24.200 --> 19:29.880 and and this is what you actually get when you these low cost FPGA they don't care about 19:29.880 --> 19:35.000 high stability oscillators they just need to communicate over high bandwidth networks and whatever 19:35.080 --> 19:42.360 you give them is good enough and what we realized is that these silicon based oscillators 19:42.360 --> 19:48.120 well how do you correct if you have a crappy silicon resonator which drifs over frequency 19:48.120 --> 19:53.320 over temperature unlike quartz well you need to correct for it so what they do is they they put 19:53.320 --> 19:58.120 a very poor quality resonators next to the good one they observe a temperature and because they're 19:58.120 --> 20:03.080 digital electronics they correct for the oscillators frequency so when you're doing not doing phase 20:03.160 --> 20:07.880 analysis you don't see it because it's smooth and they change it very quickly but in the white 20:07.880 --> 20:12.200 rabbits you're measuring the phase and you're trying to correct the phase and what we did here 20:12.200 --> 20:17.960 is we just looked at the phase output of this silicon base oscillator and what you see is all these 20:17.960 --> 20:22.280 jumps actually this is not a jump this is just me changing the frequency by one tier 20:22.280 --> 20:28.200 hers to have to have a scale otherwise I didn't know how to convert this scale of the bits into 20:28.200 --> 20:34.280 Hertz so what you see here is if I zoom in to these regions you've got these discrete steps 20:34.280 --> 20:40.200 and these are the internal DDS being reprogrammed inside the silicon if you look at a histogram of 20:40.200 --> 20:45.320 these values it's very obvious that there are discrete steps so if silicon base oscillators are 20:45.320 --> 20:49.160 very good enough for Bitcoin mining but not for while driving it and not for serious time in 20:49.160 --> 20:56.520 frequency activities so then we went back to the m2sr which has decent quartz oscillator and the first 20:56.520 --> 21:06.600 thing you see on the left is so the FTA is generating over the SI 3351 which is one of the integrated 21:06.600 --> 21:15.000 chips it generates 40 megahertz that is needed by the 89361 and what we did here is initially we wanted 21:15.000 --> 21:21.320 to get rid of the PLL inside this clock driver and all we did was to make it transparent so actually 21:21.320 --> 21:28.680 this clock driver we generated a wiretrabbit clock inside the FTA initially the radio frequency 21:28.680 --> 21:36.360 fontan is driven by the clock driver the AC 5351 and once the wiretrabbit is locked we tell the 21:36.360 --> 21:42.200 clock driver become transparent and just feed through the 62.5 megahertz from the wiretrabbit so 21:42.200 --> 21:46.840 what you see in the phase in the phase without locking you've got this drift of the phase these are 21:46.840 --> 21:53.880 two m2sr looking at the same 100 megahertz reference signal as when you look at the deed note 21:53.880 --> 22:01.640 these two m2sr are different frequencies so they have a phase with and once we look on the wiretrabbit 22:01.640 --> 22:08.760 you see that you get a flat phase whatever left over is our time constant of other control loop so 22:08.760 --> 22:15.640 so actually this is done by treating the clock driver of the 89361 by feeding directly the 22:15.640 --> 22:22.360 wiretrabbit signal now feeding a tone is good as long as you're talking about phase or frequency 22:22.360 --> 22:26.520 but when you're talking about time tones is no good because of the periods of a total of the same 22:26.520 --> 22:32.360 as a tone so for the next experiment we generate a total random sequence on an FTA J so it's a 2.5 22:32.360 --> 22:37.240 mega cheaper second and I showed previously an elsewhere but even though you have a finite 22:37.240 --> 22:42.440 bandwidth which is like 5 megahertz 5 megahertz is the inverse of 200 nanoseconds with clever 22:42.440 --> 22:47.160 signal processing on your cross correlation you can improve the timing with a factor equal to 22:47.160 --> 22:51.800 the signal to another ratio and because here we have something like 30 dB signal to another ratio 22:51.800 --> 22:56.600 we can improve this result more than 100 volts so your two or another seconds become 22:56.600 --> 23:08.040 pico seconds timing resolution so so what we're doing here is we start triggering not only the clock 23:08.040 --> 23:14.120 so we don't only drive the clock feeding the as your front end with a wiretrabbit oscillator 23:14.120 --> 23:20.760 but now we say start streaming the data on the rising edge of the one pps and this means that 23:20.760 --> 23:28.680 all the over M2SDR starts streaming data over the PCI express bus at the same time and this means 23:28.680 --> 23:34.200 that you see that now all our cross correlation so the cross correlation mean we measure the time 23:34.200 --> 23:39.560 of flight of the total random sequence to the two M2SDR are always located the same place 23:40.360 --> 23:48.600 at the same place but plus or minus one sample period because we said over the PCI express bus 23:48.600 --> 23:53.560 starts streaming whenever the data are available but we never locked over time the various 23:53.560 --> 23:58.760 oscillators so those oscillators are free running in phase in time but they're locked in frequency 23:59.480 --> 24:07.800 so now we need to find the trick to synchronize the the time at which the samples are located 24:07.800 --> 24:13.400 and I just wanted to hint here when I said we share the one pps and both and twice your 24:13.400 --> 24:18.760 start at the same time this I think a distance starts mentioning this but this is a big issue 24:18.760 --> 24:25.640 because it means someone some common message has to go to all the all the wiretrabbit slaves 24:26.040 --> 24:30.760 so one way of doing this is the wiretrabbit trigger distribution I'm not exactly sure 24:30.760 --> 24:35.880 what is the current state of WRTD so this is one message that you send to all your wiretrabbit 24:35.880 --> 24:40.920 nodes to tell them we all decide that at midnight we all start sampling at the same time 24:41.880 --> 24:47.480 if you look at the USRP in your radio when you want to have distributed x310 24:47.480 --> 24:53.240 measurement like I said earlier you need to run them all from the same USRP block you're not allowed 24:53.240 --> 25:01.000 to have two computer separated because you need to send to all the x310 the message 25:01.000 --> 25:06.120 let's settle in the in five seconds we all start measuring when we say when we get the 25:06.120 --> 25:11.880 five one pps in five seconds so now that we've done now that we saw this issue well 25:12.600 --> 25:20.360 there's a bit of a trick but in the 8031 you've got a signal which is called a syncing 25:20.360 --> 25:27.880 and the synchronization input allows you to tell the d9361 to log the a2d converter PLL 25:27.880 --> 25:33.480 on the rising edge of one pps so you're sure now that all your samples are not only 25:33.480 --> 25:38.200 streamed at the same time but also are collected at the same time which is the rising edge of one pps 25:38.200 --> 25:43.960 and now you see you compare it before now before our cross-collation peaks were within one 25:43.960 --> 25:49.080 sampling period at the same place now they are all exactly at the same location because now the 25:49.080 --> 25:57.720 two ID9361 are collecting the data also on the rising edge of one pps and now we are facing the 25:57.720 --> 26:02.920 last issue and I'm afraid there is no solution to this that like what every b210 users and every 26:02.920 --> 26:09.640 ID93961 user knows is that the two pps local oscillator of a rate of frequency from 10 is free 26:09.640 --> 26:15.800 running so we have no way of telling so we've told the PLL of the a2d converter to log on the 26:15.800 --> 26:20.600 one pps but now you still have a zero ix we need the you need to tune the local oscillator 26:20.600 --> 26:27.480 to know what is the phase and it explicitly said in the aDI application know there is no way 26:27.480 --> 26:33.160 of locking the local oscillator of a rate of frequency from 10 this guy is free running so 26:33.160 --> 26:38.680 what we're looking at is injecting noise so that we can post-process and and lock on this time delay 26:38.680 --> 26:44.360 but I think at the end of the day the a2d9361 is just not the way to go and we we want to do 26:44.360 --> 26:50.440 the a rate ptai away working a date band and not try to work with such super complex 26:50.440 --> 26:56.840 a rate of frequency from 10 so that concludes what I wanted to tell you where you can run 26:58.120 --> 27:04.680 a white rabbit as a gateway and a software or you can use the wrapper that is provided by 27:04.680 --> 27:10.520 litex by an individual and it's working the same way people from computer science they prefer 27:10.520 --> 27:14.840 the litex way because it's Python I've heard people who said yeah but that's one more 27:14.840 --> 27:19.240 dependency that we're going to rely on so they preserve a white rabbit way but at the end of the day 27:19.240 --> 27:24.920 you see here that we have a truck phase of the M2SDR from from an individual it's completely 27:24.920 --> 27:31.400 programmed in litex so it's natural to to to wrap a white rabbit inside this in this framework 27:32.120 --> 27:37.400 so I just wanted to complement a three-stance presentation to show you that even if you're not 27:37.400 --> 27:41.400 working a turn or even if you don't have access to a six-stance five-digital and both 27:41.400 --> 27:46.280 accelerator there's a lot of things you can do with white rabbit I would like to convince you 27:46.280 --> 27:50.120 that actually you don't even need to have a white rabbit switch because the white rabbit 27:50.120 --> 27:54.120 these endpoints can talk to each other so if you don't want to look to a hydrogen major 27:54.120 --> 27:59.800 but you just want to these two guys to be synchronous then then the white rabbit's going to do the job 27:59.800 --> 28:04.200 if you want to play with with it at home you've got the white rabbit's accord repository 28:04.200 --> 28:11.560 that tells you how to do this you can use the light text here I put for you the command if you want 28:11.560 --> 28:19.800 to enable the white rabbit's capability of the light text and to as your light text software 28:20.360 --> 28:27.080 and the white rabbit remains an open source open hardware project thanks to the white rabbit 28:27.080 --> 28:31.960 collaboration that was initiated by Raviye so if you're interested in this story I put a few 28:31.960 --> 28:36.280 leaflets on the first two corners of the first table if you're interested in white rabbit 28:36.280 --> 28:41.080 collaboration please have a look and consider collaborating and joining if you if you're interested 28:41.080 --> 28:44.280 in this kind of activity and with this I thank you for that attention