WEBVTT 00:00.000 --> 00:09.200 We have a couple of presentations about web-based software 00:09.200 --> 00:15.000 and radio. In my case, my interest in web-based VR was to access 00:15.000 --> 00:20.800 signal that were not accessible from my locations using direct 00:20.800 --> 00:26.200 receptions. And I'm interested in very low frequency time transfer 00:26.200 --> 00:30.200 and especially the signal broadcast from UK from interns. 00:30.200 --> 00:36.200 So that's too far from my locations and that's hence my use of the QSDR 00:36.200 --> 00:40.200 web-based network. So first of all, let me remind you why 00:40.200 --> 00:44.200 historically there has been very low frequency communication 00:44.200 --> 00:48.200 and why there is renewed interest in this technology. 00:48.200 --> 00:52.200 I'm going to talk quickly about briefly about the performance of 00:52.200 --> 00:57.200 the various time transfer signal you have access in Western Europe. 00:57.200 --> 01:02.200 And I'm going to focus on one particular signal that has been important 01:02.200 --> 01:06.200 from the US and that's been broadcast by the UK, which is 01:06.200 --> 01:10.200 enhanced low-run, ill-run. So I'm going to get in the details to show you 01:10.200 --> 01:15.200 how I use the QSDR signal to get a detailed understanding of ill-run 01:15.200 --> 01:20.200 CRC for the raw correction payload structure and I'm going to show you 01:20.200 --> 01:24.200 some of results. So to the best of my knowledge, this is the first open source 01:24.200 --> 01:30.200 ill-run decoder available. So just as a quick reminder at a space age 01:30.200 --> 01:34.200 where everyone's forgotten that there was a point where there was no satellite 01:34.200 --> 01:38.200 in space, why are we actually broadcasting radio frequency signal 01:38.200 --> 01:43.200 over satellites? Well, it's very simple. It's about a direct line of 01:43.200 --> 01:49.200 size range. If you're on the surface of the earth because earth is a sphere, 01:49.200 --> 01:55.200 well, you have a finite line of size and the further away your transmitter 01:55.200 --> 01:59.200 the longer this communication range. If I do a quick calculation, 01:59.200 --> 02:03.200 which is just trigonometry of a guy on the surface of the earth 02:03.200 --> 02:07.200 and the satellite flying at an orbit are just by simple trigonometry, 02:07.200 --> 02:11.200 you can show that the length of this arc will be something like 02:11.200 --> 02:17.200 8,500 kilometers if you have a GNSS signal at 20,000 kilometers away 02:17.200 --> 02:22.480 and you can have a geostation satellite which you basically cover half of a surface of 02:22.480 --> 02:31.200 the earth, so 20,000 kilometers on both sides. So that's very convenient, but satellites are far away 02:31.200 --> 02:36.240 prone to spoofing and jamming and rather challenging to launch. So 02:36.240 --> 02:42.240 historically, you had a way of broadcasting beyond direct line of size using the 02:42.240 --> 02:48.240 ionostric bouncing on the ionostric layer, which is low frequency, which 02:48.240 --> 02:52.240 happens to be limited by the cutoff frequency of a plasma in the ionostric here. 02:52.240 --> 03:00.240 So low frequency are 30 to 30 earth signals and they benefit from this ionostric effect. 03:00.240 --> 03:07.280 As an example, my watch is synchronized every night when the broadcast of the 03:07.280 --> 03:14.240 LF signal is best using the DCF 77 German broadcast station. Now in the lab, 03:14.240 --> 03:20.240 I have a few of these webber stations, which is also synchronized on DCF 77, 03:20.240 --> 03:24.240 gives you millisecond accuracy that sometimes fails to decode the date because 03:24.240 --> 03:28.240 there's so much noise in our lab at such the LF frequency. So 03:28.240 --> 03:34.240 you get high resolution, but don't charge the date. So if you look around, so this is for 03:34.240 --> 03:39.840 example, one of the manual of my watch, and actually this watch, we'll have a decoder, 03:39.840 --> 03:46.640 it will detect where it is located, it will use UVV in the U.S., it will use JJY 03:47.360 --> 03:58.080 or the Chinese in Southeast Asia and in Europe, it's using either MSF in the U.K., DCF 77 in 03:59.040 --> 04:04.400 Central Europe from Germany, no one's using the French ALS because it's subject to 04:05.120 --> 04:10.560 licensing and that's an issue. So, capture or decide it to use MSF 04:11.360 --> 04:17.440 DCF 77, YYVB, JJY, the Chinese broadcast station as well. 04:18.320 --> 04:23.600 So this gives me an overview of what are the signal we have access in Western Europe. 04:23.600 --> 04:31.040 So most of us will know DCF 77, MSF 60 kilohertz, ALS 162, which used to be for 04:31.040 --> 04:35.680 a French speaking audience, used to be fronceteer and they stop broadcasting the AM, 04:35.680 --> 04:40.480 but there are so many strategic French users of the timing signal that they keep on broadcasting 04:40.480 --> 04:45.920 162 kilohertz, which is phase modulated. I'm going to show you. So the day here are 04:45.920 --> 04:51.920 dates of launch and dates of update of the technology. Now, some of the people who are 04:52.640 --> 04:59.200 sensitive to time transfer are the energy and the smart grid. So in Germany, they created EFR, 05:00.160 --> 05:06.720 which is a signal dedicated for a signal for a smart grid processing. And if you're interested, 05:06.720 --> 05:14.240 there is a beautiful presentation at CCC last year about spoofing the EFR signal. And they actually 05:14.240 --> 05:20.640 realized that it was used in much more powerful production plan that originally expected. 05:21.600 --> 05:26.720 At the moment, you might know that there is a bit of jamming around the Baltic Sea, 05:26.720 --> 05:33.680 between Ukraine, Russia and the Dan-American Norway. And so in the Baltic Sea, there's a creation 05:33.680 --> 05:38.640 of the R mode, not exactly why this people are creating yet a new protocol, because they're basically 05:38.640 --> 05:43.840 recreated exactly what the Americans created during the Second World War to drive their 05:43.840 --> 05:49.520 bomber to Germany, which was called Loran Long Range. Now, Loran was initially a two-megahertz 05:49.520 --> 05:56.640 signal, which was upgraded, so rather a minimalistic range. And it was upgraded to 100 kilohertz 05:56.640 --> 06:06.240 in 1958. And since then, we had this Baltic Sea long run for positioning, and if we need positioning, 06:06.240 --> 06:11.680 we need high-resolution time transfer. Loran has slowly decayed, because everyone got familiar with 06:11.680 --> 06:18.000 GNSS, and now with the Ukraine War, people are getting familiar again with lots of GNSS, 06:18.000 --> 06:26.480 and maybe there's a good idea to keep a backup solution, actually. So I do not access the Loran 06:26.480 --> 06:31.920 signal. One reason being that I don't have a big FN10, I remember 100 kilohertz is 3 kilometer 06:32.720 --> 06:39.440 wavelength, and there is a fundamental rule, which actually was published in 1947, 06:39.520 --> 06:43.840 that says that if you have an antenna, which is much more than the wavelength, it must necessarily 06:43.840 --> 06:48.880 be resonant and high-q-factor, that's that's the relationship. So if you want to recover this 06:48.880 --> 06:57.120 CF77 MSF, L162, and Loran 100 kilohertz, either you have a huge antenna, or you need multiple 06:57.120 --> 07:01.840 antennas, but you're going to have one small antenna receiving all these guys. Now, rather than focusing 07:01.840 --> 07:08.240 on receiving these guys myself, I looked at what I can fetch online. Now, you might all be familiar 07:08.240 --> 07:15.520 with the WebAs ER from the University of Twenton. It works, but there are some limitations. 07:15.520 --> 07:21.680 First of all, if you look at the manual, so you cannot find a way of automating 07:21.680 --> 07:26.640 recording from WebAs ER from Twenton. And if you look at the manual that they tell you that 07:26.640 --> 07:33.360 including distribution part are entirely for reverse engineering is not allowed, and that's not exactly 07:33.360 --> 07:37.520 my conception of what open source means. So that's what we're going to forget about WebAs ER, 07:37.520 --> 07:43.200 and also WebAs ER is not timestamped. So I was more interested in timestamping because I wanted 07:43.200 --> 07:48.080 to have some time transfer capability, and that's exactly what QES ER is giving you. So this is 07:48.080 --> 07:54.480 the web interface of QES ER. Not only does it give you timestamp samples, but it also gives you 07:54.480 --> 08:01.040 the ability through an open QE client automated recording capability using patent scripts. 08:02.000 --> 08:08.880 So this is the list of broadcasts, sorry, the receiver. So the French ALS162, DCF77, 08:08.880 --> 08:14.480 in Germany, entered with Iloran Abwehr, and these are all the stations I've been looking at 08:14.480 --> 08:19.040 when recording. So what do we look like? This is a French system. Remember, the French 08:19.040 --> 08:24.400 system was next to the AM broadcast of Constantinople. So it's very narrow bandwidth, a few 08:24.400 --> 08:29.200 Hertz. So you're going from plus one region to minus one region in 20 milliseconds. So basically, 08:29.280 --> 08:33.280 you have a few Hertz bandwidth. And you remember from the radar equations that the time 08:33.280 --> 08:38.160 transfer capability is inverse of the bandwidth. So this is the time transfer I recorded this over 08:38.160 --> 08:43.120 a week of the various stations I showed you earlier, super simple decoding process, look at the 08:43.120 --> 08:48.160 zero crossing of the phase, and you get something in the millisecond range. The offset is the time 08:48.160 --> 08:52.960 of flight because there's no location of compensation. So what you're interested in is the line 08:52.960 --> 08:59.600 thickness, basically, fraction of a millisecond. Now if you go for DCF77, since 1988, 09:00.400 --> 09:07.360 Hetzel added on top of the AM modulation, a spread spectrum phase modulation, and this is 09:07.360 --> 09:14.560 750 Hertz wide. So you already see that DCF77 is much now or much better time transfer capability. 09:15.280 --> 09:21.200 And finally, you look at Loran, so the long range, initially developed 1942, it's part of 09:21.760 --> 09:27.440 MIT radiation lab publication that was recording all the development of US radio frequency 09:27.440 --> 09:31.520 communications during Stephen World War. And this is the kind of output that you get. 09:32.080 --> 09:36.000 Now you might say, hey, if it's the same thickness as the previous lines, what's the benefit 09:36.000 --> 09:40.640 of using Loran? Well, I change the scale. If you put this on the same scale as earlier, 09:40.640 --> 09:45.920 this is what you get from Loran. So remember, Loran is dedicated to location and locations 09:46.080 --> 09:53.120 to saturation, it's time of flight. So what the Americans got from their usage of system for 09:53.120 --> 10:02.480 positioning is not just a few Hertz, as DCFs, as an L362 or a few hundred Hertz, like DCF77, 10:02.480 --> 10:07.840 they got 20 kilohertz. Now, 20 kilohertz, that 100 kilohertz is a significant fraction of a spectrum. 10:07.840 --> 10:13.040 But this is what they got and the benefit of using a 20 kilohertz wide signal is your time transfer 10:13.040 --> 10:19.600 capability is much, much better. Now, Loran, we've seen earlier, Loran, we've seen earlier 10:19.600 --> 10:26.560 that we had these phase modulations for L362, Loran is based on these pulses. And I'm going to 10:26.560 --> 10:32.400 spend a bit of time now showing you the details of how these pulses are analyzed and how we look 10:32.400 --> 10:40.000 at the Loran protocol using the QESR recordings. Just before we get in the details, this was published 10:40.080 --> 10:45.920 February 17, 2022. I don't know if you have in mind the date when Russia invaded Ukraine, 10:46.720 --> 10:54.560 exactly one week after this. And you might or might not trust GPSW, but so, 10:54.560 --> 11:00.000 Glodas is a Russian GNSS and actually, the Russians have been using the equivalent of Loran, 11:00.000 --> 11:06.960 I wouldn't have pronounced the name because I don't know how to pronounce it, CHYKA. And 11:07.120 --> 11:14.320 well, we see so many pictures of CRPA GNSS antennas, but I'm not sure this prediction 11:14.320 --> 11:19.040 of ditching Glodas and going from Loran is correct, but it's a matter of fact that without 11:19.040 --> 11:26.720 Crimea, your Loran network from Russia will be hard to use over Ukraine. Maybe just a coincidence. 11:27.760 --> 11:34.080 So what is Loran? Loran is a set of broadcasting stations, a master and secondaries, and these people 11:34.080 --> 11:39.120 are broadcasting at the same time, so you need to have some differentiation, it's CDA-A, time 11:39.120 --> 11:45.760 time division multiple access. So you have various pulses, in X-axis is the time, you've got a master, 11:45.760 --> 11:50.800 you've got a few secondaries, and you see these pulses that we've been recording from the QESR. 11:51.440 --> 11:56.800 Now these pulses have a polarity, not only do I have a magnitude, but if you can also look at the 11:56.800 --> 12:03.440 sign, and the polarity will tell you by the sequence of polarity, whether it's a master or second 12:03.440 --> 12:07.600 there is broadcasting, and this is exactly what you're seeing, so in blue is the magnitude, 12:07.600 --> 12:13.040 and in red is the phase of the baseband signal, because the QESR does not give you access to 12:13.040 --> 12:18.320 100, 200 kilohertz, you've got the baseband signal. Now the difference between Loran, the historic 12:18.320 --> 12:24.240 Loran from the US and the Loran and hence Loran, is that since 2000s, there has been the addition 12:25.120 --> 12:30.960 of a digital modulation. Now surprisingly enough, this was developed at Delft University by the Dutch 12:31.040 --> 12:38.720 people in Europe, and it's called Eurofix. Now Eurofix adds plus or minus 1 microsecond offset 12:38.720 --> 12:44.960 over these pulses, and if you look at plus or 1 microsecond at 10 microsecond period 100 kilohertz, 12:44.960 --> 12:50.560 it's plus or minus 36 degree phase shift. So not only you have a plus, 90 degree or minus 90 degree, 12:50.560 --> 12:56.160 the tell you is it's a master of secondary, but you see that you've both pulses plus 36 degree 12:56.160 --> 13:02.320 or minus 36 degree, and this gives you the big value that they added. The sum of these bits of 13:02.320 --> 13:09.120 sets are new, so that non-Loran receivers or Loran receiver can still get an accurate timing. So 13:09.120 --> 13:14.800 the sum of these positive and negative pulses will cancel out, so that the average 13:14.800 --> 13:23.200 seal operates for proper Loran, Loran broadcast receiver. Now this Loran protocol is 13:23.280 --> 13:31.920 partly documented in an ITU documentation. It's been now promoted by an American company called 13:31.920 --> 13:39.200 Eurofix enough, and it seems to be sold or promoted by a Dutch company whose got many 13:40.080 --> 13:44.800 document manuals online, and these manuals are much more detailed than they should be, but that's 13:44.800 --> 13:50.960 good for us because it gives us a lot of information. So when you look at the phase that I showed 13:51.040 --> 13:57.200 you earlier, the QESDR is time-stamped, but obviously it's not a GPS discipline oscillator, 13:57.200 --> 14:02.320 because when you look at the phase, you see it's slowly drifting for all the master and secondary 14:02.320 --> 14:07.680 recording. So obviously this is a receiver drifting also because the master and secondary of Loran 14:07.680 --> 14:13.200 are driven by seismic clock and seismic clocks are not drifting by definition. And so you first 14:13.200 --> 14:18.880 you must first cancel out the local oscillator drift of your QESDR recording, and then when you 14:18.880 --> 14:23.200 look at this plus or minus 36 degree at all the earlier, so you remove the plus or minus 90, 14:23.200 --> 14:29.520 which is of course facing information, and you see on the histogram that we have minus 36 degree, 14:29.520 --> 14:36.480 plus 36 degrees, or chances that we will be able to decode the phases and the bits are pretty good. 14:37.760 --> 14:45.200 So then you get into the ITU documentation that describes, so this is not invented. This is from the ITU 14:46.160 --> 14:52.320 published in 1996, if I remember well. And what they tell you is that actually they use a 14:52.320 --> 14:59.280 tristate because your phases can be minus 1, 0 or plus 1. And actually yesterday I discovered there 14:59.280 --> 15:05.920 was a both meeting of people working with free treats. So I was not even aware that people were 15:05.920 --> 15:12.960 doing this kind of statistics, but yet people are more familiar with bits. So you convert the 15:12.960 --> 15:18.400 treats to bits through this table. Again, you will see that the sum of all the phases is 0, 15:18.400 --> 15:26.240 and what you actually end up having is 120, so out of your six treats, you get 127 possible bits. 15:26.800 --> 15:33.840 So these are seven bits sequences. So first of all, you need to translate your free phase states 15:33.840 --> 15:39.760 into bits. And once you get your bits, then you need to analyze the payload, the content. 15:39.920 --> 15:44.800 If you're familiar with continuous data stream with just in earlier advice presentation, 15:44.800 --> 15:49.360 usually you put a sync word because the sync word gives you the starting of your, of your 15:49.360 --> 15:56.640 frame. In Iran, there is no such thing as a sync word, so you need to find a way of identifying 15:56.640 --> 16:02.960 where is the beginning of a sentence. One thing we do know is that the payload is 70 bits, 16:03.040 --> 16:12.400 including 56 data, 14 bits CRC, and 140 bits for the forward error correction reads Solomon. 16:12.400 --> 16:18.480 So we know one thing, we know that the total message length is 210 bits long. 16:19.280 --> 16:27.280 And if you draw the phases as 210 values by the slow time over here, obviously you do see some 16:27.280 --> 16:32.880 pattern, these are the useful data, these are the forward error correction which looks random. 16:32.880 --> 16:39.040 So visually, you do identify where is the beginning of a sentence. But how do you automate this 16:39.040 --> 16:47.360 process? So there's a few data online. I used to work on RDS, one of the very first projects to 16:47.360 --> 16:53.600 get me into a SDR was the rate of data system that you have on the FM broadcast. And if you read the 16:53.600 --> 17:01.840 RDS documentation, they put a CRC at every sentence that they sent. And they tell you explicitly 17:01.840 --> 17:08.160 in RDS that you should be using. So you just run for each big position what would be the CRC 17:08.160 --> 17:13.040 for a given payload. And if CRC beats actually match your calculation, then you find the 17:13.040 --> 17:20.320 beginning of a frame. So this is one way. There is another approach which is using the forward 17:20.320 --> 17:25.040 error correction, which is pretty much the same, except that I did not know at this time how the 17:25.040 --> 17:29.520 forward error correction was working, whereas CRC is much easier to implement than read Solomon. 17:29.520 --> 17:36.800 So what I did is implement the CRC. But if you're familiar with CRC between the documentation 17:36.800 --> 17:40.640 and the implementation, there's so many things you can change. You can flip the input bit, 17:40.640 --> 17:45.120 you can flip the polynomial coefficient, you can flip the resulting CRC. You can save at the 17:45.120 --> 17:52.000 place instead of assigning minus 36 degree and plus 36 degree to minus one and plus one stage. 17:52.000 --> 17:58.240 You can flip the conversion from phase-state to big-state. So there is so many degrees of freedom 17:58.240 --> 18:03.680 that it does take a bit of trial and error. It actually took us two months to realize that there 18:03.680 --> 18:09.120 were so many degrees of freedom because, of course, for the first two months, it was failing. 18:09.200 --> 18:16.400 And then at some day, it was a Eurocar morning. After another night of trying this, 18:16.400 --> 18:21.600 going to the lab in the morning, let's see again if it failed. And one morning you come and you 18:21.600 --> 18:27.520 see the green lines and that's just one of the few beautiful morning when you come when you realize. 18:27.520 --> 18:34.320 So this is what happens. The green lines, you've got, on the left, is the big index. So that's 18:34.320 --> 18:40.720 a position in the file. Then you've got the data. Then you've got the 14-bit CRC that we calculated. 18:40.720 --> 18:45.760 All of these lines, I only displayed the one for which the CRC matches the actual recording. 18:45.760 --> 18:53.120 And then you've got the four-direction that's better later. Now you see here that we identified 18:54.080 --> 19:03.440 sentences, position 14 and 15 as starting. Then 225, 226. Then 435, 442, 443. So actually, 19:03.440 --> 19:08.640 this method, I had not realized initially, but it's kind of weak because you can demonstrate 19:08.640 --> 19:14.160 that in the CRC, if you make a cyclic rotation of the payload, you make the same cyclic 19:14.160 --> 19:22.240 rotation of the CRC checksum. And this means that if you have the right payload at this location, 19:22.240 --> 19:27.120 and if you just flip the beginning and the end, well you end up having the same CRC over here. 19:27.120 --> 19:35.120 And so you might have some fast detection. Yet, because we know that it's only 2010 bits 19:35.120 --> 19:40.640 spacing between sentences, if you only keep the one that are separated by 2010 bits, which I did 19:40.640 --> 19:46.480 in the green lines here, you get the right sentences. And this is a point where we can start 19:46.480 --> 19:51.760 having fun because we know where the sentences start. We know what the CRC is. So now, 19:51.760 --> 19:56.240 well, now we start analyzing. So I told you there is this Dutch company, 19:56.240 --> 20:01.200 Rio Tronica, selling Iloran hardware, and their manual are super detailed, 20:01.200 --> 20:06.000 actually it's written that the guy who invented your fix, they can show off. And here I'm just 20:06.000 --> 20:13.600 showing you these are the bits that we decoded, and everything has to be bit flipped. So they always 20:13.600 --> 20:18.480 start with a least significant bit to the right. So whenever you see a sentence, you must flip the 20:18.480 --> 20:24.640 bits, yet another awkward aspect. But when you do this and you look at the manuals from Real Tronica, 20:24.640 --> 20:30.960 you end up finding that it's a UTC broadcast message, tag number one. You have to remember to flip 20:31.040 --> 20:36.240 a bit. So you take these bits and you flip that upside down. And you look, this is the seconds 20:36.240 --> 20:40.640 within the hour, precise time with 10 and a second, and you've got the leap second between 20:40.640 --> 20:47.280 Lauran C and UTC. And if you look at the documentation, indeed, Lauran is 27 of 2 UTC. 20:48.000 --> 20:51.680 And then if you continue, you're sorry here, you've got the next message, 20:51.680 --> 20:58.720 subtype. Now you can have another type of UTC message, which is what is the date. And you find that 20:58.720 --> 21:04.960 you can actually decode the hour of a year. And you take one of these online, one of these online 21:04.960 --> 21:10.000 calculators that gives you what is the hour of a year. And you actually, indeed, find that this 21:10.000 --> 21:17.520 thing was recorded October 14, which is indeed the name of the file that I saved, which includes 21:17.520 --> 21:23.680 the time at which it was recorded. And finally, you see that the year is 2025. So this is all correct. 21:23.840 --> 21:29.280 So now we've learned how to decode Lauran. We have our first item where we can not only get 21:29.280 --> 21:33.920 the precise time from the analog signal, but we get the decode payload, which is UTC time. 21:35.680 --> 21:41.600 One limitation of the historic Lauran is that you're measuring surface wave time of flight. 21:41.600 --> 21:46.240 Now the problem with surface waves is they're propagating between the waveguide, which is made 21:46.240 --> 21:51.440 on the one hand by the atmosphere. And on the other hand, by whatever you have in the surface of 21:52.320 --> 21:58.000 Earth, whether it's soft water, ideal for wave, but when it's propagated over ground, 21:58.000 --> 22:03.600 whether it's raining, whether you're dry ground, your velocity of a surface wave differs. 22:03.600 --> 22:09.600 Now this, I was first introduced to this for lightning detection. You might have heard of a 22:09.600 --> 22:14.720 Greek project to us about lightning detection, where they introduce this correction factor of 22:14.720 --> 22:20.400 the speed of electromagnetic waves, depending on whether they propagate over sea or ground. And this 22:20.480 --> 22:27.040 in Iran is this ASF differential time in correction. Unfortunately, this message seems to be 22:27.680 --> 22:32.720 proprietary and I could not find any documentation. So if there's anyone who knows about ASF, 22:32.720 --> 22:38.160 I would be eager. Well, to know a bit more, what we do see here is that we know from the 22:38.160 --> 22:43.840 documentation that 13 is the ASF message. And we see that if you remember to flip the bits, 22:43.840 --> 22:48.400 it's all zeros and a tiny value. So I'm pretty sure it's something like delay, and if 22:48.400 --> 22:54.320 look at the documentation, they're mostly all written in two nanoseconds, multiple. So this 22:54.320 --> 23:00.080 looks very much to me like a station identifier and a time delay, multiple of two nanoseconds, 23:00.080 --> 23:07.360 but there's just a hint. And then you've got another message which is the health of the broadcast 23:07.360 --> 23:12.240 mutation. So when you're looking at Antoine, Antoine is actually in Western Europe. There's 23:12.240 --> 23:17.200 only one country that keeps on broadcasting Iran, because remember, Iran is American, so there's 23:17.200 --> 23:22.800 only one country in Western Europe that's a Persian horse of the US. And so UK still broadcasting 23:22.800 --> 23:29.040 Iran over the other Western Europe decided to ditch their lower annotations. So actually the poor 23:29.040 --> 23:34.080 Antoine has to broadcast both the master and the secondary signal because there is no over secondary 23:34.080 --> 23:40.560 broadcast station in Western Europe. And so when you look at the messages, you find this health 23:40.560 --> 23:48.880 state, and this is a 10-bit station ID. There's a free-bit station health. These messages were not 23:48.880 --> 23:55.680 publicly available. The only thing I figured out by myself is I knew that Antoine was on the wrong 23:55.680 --> 24:01.040 side of a green-witch meridian. It wasn't the west. And so being on the west, it was a negative 24:02.880 --> 24:08.400 longitude. And when you see this quantity here, you have a hint that when you've got all these 24:08.400 --> 24:13.440 leading ones, that's a good hint that this is a negative quantity in two complement. And if you 24:13.440 --> 24:20.880 just convert these binary numbers as a digit, a 32 digit, you actually end up finding something 24:20.880 --> 24:26.560 that looks like this, which multiplied by 10 to a minus 7 gives you a longitude and latitude 24:26.560 --> 24:31.600 you ask this to open street maps and you get exactly on the Antoine broadcast station. So this 24:31.600 --> 24:36.320 is correct. And actually there was a discussion, if you're familiar with the time that's 24:36.320 --> 24:41.040 mailing list, that's a list of people who are interested in time and frequency, the offer of 24:41.040 --> 24:45.760 WebAsYR published a couple of copy-paste that he made because he claims to have written an 24:45.760 --> 24:50.640 ill-around recorder, but he doesn't he doesn't publish anything. And the few lines he published 24:50.640 --> 24:59.040 on the mailing list matched the identifier of this station. So this is all matching very well. 24:59.840 --> 25:07.280 Yeah, I just wanted to add that the offer of a Eurofix revision 2015, which is one of 25:07.280 --> 25:12.640 his professors of dancing university, was kind enough to send me the update of a Eurofix revision 25:12.640 --> 25:17.760 you will not find it on the internet. It's not publicly available, but he sent me a copy. So I can 25:17.760 --> 25:22.560 tell you that these are correct and now you have your own information despite not being in the Eurofix 25:22.640 --> 25:29.680 revision. So okay, we've got the payload, we've got the CRC, we would like to have a read Solomon. 25:30.800 --> 25:38.640 And a read Solomon is one of his, I only use read Solomon in the case of CCSDS and CCSDS, 25:38.640 --> 25:44.640 despite all of the information that Daniel is sharing on his blog about the various declination 25:44.640 --> 25:49.840 of CCSDS when even within NASA they cannot agree what is the definition of CCSDS. 25:50.240 --> 25:57.440 I had never had to read the read Solomon by myself. So the first thing I was not familiar with 25:57.440 --> 26:02.800 is that when people tell you that they are doing read Solomon's 3010, well it doesn't exist 26:02.800 --> 26:09.120 3010. You cannot make a read Solomon's 30 because 30 is not a power of 2 minus 1. So actually 26:09.120 --> 26:16.400 it must be the closest power of 2, which should be 32. However, you saw earlier that we're working 26:16.400 --> 26:26.000 with 7 bits and 7 bit packets, they call it GF7 and I had again to learn how sorry GF128, 26:26.000 --> 26:32.560 2 to the 7. And I heard I learned the naming convention this means that you get data which are 26:32.560 --> 26:39.840 127, possibly with a lot of leading zeros followed by, so when you say you've got 3010, 26:39.840 --> 26:46.400 it means you've got 10 bit payload, 30 bit word syncword. And this means that actually out of 26:46.400 --> 26:56.240 1307 data you've got 97 leading zeros, then the 10 useful data leading to 127 reads Solomon output. 26:56.240 --> 27:03.920 So this is actually what you end up processing. And then again Daniel has been super useful during 27:03.920 --> 27:08.640 the Christmas vacation answering very quickly to my request because I couldn't understand anything 27:08.720 --> 27:14.720 to what I was looking at and he knows. And so Daniel figured out that when you actually, 27:14.720 --> 27:20.000 this is a short sentence that I had not even noticed, the relation between GF128 elements in binary 27:20.000 --> 27:25.360 data should be to consider the value of a power of alpha as a 7 bit binary. And I didn't know 27:25.360 --> 27:30.720 what that meant, but Daniel identified this means you're taking alpha to the power of B and not 27:30.720 --> 27:36.560 the B's as the powers of a polynomial coefficients here. And so I will not get into detail. I'll 27:36.560 --> 27:41.840 just show you the piece of code that Daniel sent me and thanks to which this all works. 27:41.840 --> 27:48.880 And so the trick is that you need to convert from the input binary state to the power, 27:48.880 --> 27:53.200 then you do all the decoding. So usually you don't want to encode, you just want to decode, 27:53.200 --> 27:58.560 but then you decode and you have to go back into your original state. So this is totally from each 27:58.560 --> 28:03.760 and that's my understanding what is the difference between these powers of alpha and alpha to the power. 28:04.320 --> 28:12.000 So at the end of the day, what does this mean? Well, if on purpose, I change one byte in the message. 28:12.000 --> 28:18.240 So I corrupt one message on purpose. You see that the fact is doing its job. It found that I had 28:18.240 --> 28:25.280 corrupted a data. So I equals 5. It detected the error on solution 5. And it said you put 42, 28:25.280 --> 28:30.080 but originally it was 1c. So the further correction is working now. And if you want to use it 28:30.160 --> 28:34.720 for your synchronization, it's working as well. So now concluding this presentation, 28:35.600 --> 28:40.640 okay, we did an turn, but does it work somewhere else? So first of all, we know that the Koreans 28:40.640 --> 28:46.720 are using illoran. If you look at the countries using illoran, basically Western Europe decided 28:46.720 --> 28:52.080 to ditch it because it's not used. You have got South Korea because North Korea is jamming their 28:52.080 --> 28:57.680 geniuses. You've got South Korea, because they have Iran next door. You've got China. So all the 28:57.680 --> 29:05.200 countries during illoran are the one subject to Genesis loss. So Korea, Korea, we only have one 29:05.200 --> 29:12.160 signal that we can get from QSDR. And unfortunately, it does not seem to be holding any information. 29:12.160 --> 29:16.320 But that doesn't conclude much because there's at least four stations in Korea, 29:16.320 --> 29:20.640 three of which I have never been able to listen at. So that's the limitation of the QSDR receivers. 29:21.280 --> 29:27.600 Then we've got, I told you the Russians, which are supposed to use illoran. And there is one QSDR 29:27.600 --> 29:33.200 in Finland, which is getting a very nice signal which I attribute Russia, because I don't 29:33.200 --> 29:39.440 see who else would be broadcasting illoran compatibility with Syria. And again, the red is the master, 29:39.440 --> 29:46.080 the green is one of the second there is. And I don't think I see a neurofix message on the Russian 29:46.080 --> 29:52.480 illoran. So at the moment this is still working progress. And then we've got Saudi Arabia. 29:52.480 --> 29:59.440 And Saudi Arabia, there is one QSDR receiver in Qatar working very well. And actually it's only 29:59.440 --> 30:07.600 a few kilometers even from this, I think it's called Salwa. Yeah, this broadcast station Saudi Arabia. 30:07.600 --> 30:13.760 I'm not going to do the whole story again, but if you record the data from this QSDR, 30:14.320 --> 30:20.000 the structure is a little different because somehow usually you're supposed to have eight 30:20.080 --> 30:25.760 bits on the second there is nine bits on the master. And somehow the Saudis, they have nine bits 30:25.760 --> 30:31.680 everywhere. So for decoding illoran, I just get rid of the nine bits. And if you get rid of the nine 30:31.680 --> 30:37.520 bits, you get something, again, I'm not going to get people hold the demonstration. But you get a 30:37.520 --> 30:42.000 latitude, you get a longitude. This time I had to ask Google Maps, because Open Street Maps 30:42.000 --> 30:46.960 doesn't have anything in Saudi Arabia. And you end up finding exactly the location of a 30:47.760 --> 30:52.080 map. And if you decode the message, you see that this is called the Whiskey Station, 30:52.080 --> 30:59.280 which I can't sign up for Saudi Arabia. So that's the decoding process of the Saudis signal, 30:59.280 --> 31:07.360 which is meeting the Europe's definition. So this concludes my exploration of illoran illoran 31:07.360 --> 31:13.440 is a technology that has been very long that I wanted to work on illoran. And last summary, 31:13.440 --> 31:20.400 if I remember well in July, the French president went to the UK. And there was a press, 31:20.400 --> 31:27.280 really saying, France is going to work with illoran. No one knows who decided this, no one who 31:27.280 --> 31:33.120 affected the side of that illoran will be broadcast in France. And so because I'm not working on 31:33.120 --> 31:38.320 in the primary methodologies institute, I have nothing to say. But because I'm working on HDR, 31:38.320 --> 31:42.400 I've been informally asked, what do you think of it? And I said, okay, you're going to import 31:42.400 --> 31:45.200 an American technology, you don't know how it works, you don't know how to decode it, 31:45.200 --> 31:50.800 it doesn't know how to use it by yourself. That's very clever. So I don't have anything to say about 31:50.800 --> 31:54.880 it, but at least I can tell you now that we have an open source illoran decoder that affects 31:54.880 --> 32:00.640 my contributions of illoran. I'm interested in time and presidency transfer. These are 32:00.640 --> 32:04.880 all deviations. If you're familiar, if you're not familiar, just take this as a standard deviation, 32:04.880 --> 32:10.000 the higher it is, the worse it is. This is a French L1062, this is DCF77, 32:10.880 --> 32:14.800 and this is a loran from Qatar. You obviously see that the broader the bandwidth, 32:14.800 --> 32:20.320 that they're the timing capability. I tried to show you that we could do this all of this 32:20.320 --> 32:27.760 without relying on actual real signals. This is all relying on web services. We have become familiar 32:27.760 --> 32:34.960 with illoran, the digital payload, the CRC, the four-layer correction. We've been able to use 32:34.960 --> 32:41.680 mostly publicly document, publicly available documents to decipher the payload, working progress. 32:41.680 --> 32:45.600 It would be really nice to have more signal from the Koreans, because at the moment I don't 32:45.600 --> 32:50.080 have one signal which doesn't carry anything. The Chinese, there's a lot of signal from China 32:50.640 --> 32:56.080 that need to be decoded. I recently discovered one key way is the receiver in Tushu in South 32:56.080 --> 33:01.040 and Japan, which is getting a very good signal. The Russians, I need to figure out why they're 33:01.040 --> 33:08.320 not broadcasting the Eurofic signal. There is one message that is published on Korea. You've got 33:08.320 --> 33:15.600 a lot of online documents from the Koreans about GNSS-proofing and protection. The Koreans are broadcasting 33:15.600 --> 33:20.560 one message, which is called Message Number 10, which I've never seen, and I would really be eager 33:20.560 --> 33:29.200 to detect this information. With this website, with the KiwiSDR software, it's a bear because 33:29.200 --> 33:32.800 public monitor be code, and with this, I thank you for attention.