WEBVTT 00:00.000 --> 00:11.160 Okay, hello everyone, so I'm Pierre Bissack, I'm from the, I'm a contributor to the 00:11.160 --> 00:17.200 Centipede project, and I'm the author of the millipede cluster, so I'm going to explain 00:17.200 --> 00:25.000 what is all about, I'm also an open street map contributor, so I'm going to explain why 00:25.000 --> 00:34.000 and how we can get centimetric precision geopositioning. 00:34.000 --> 00:39.320 Currently we are not supposed to talk about GPS anyway, not because of the event in the 00:39.320 --> 00:44.880 US, but because there are several constellations now, we have the US constellations, which 00:44.880 --> 00:50.520 you know already, we have the European constellation, which is called Galileo, the Chinese, 00:50.520 --> 00:57.680 which is called Baidu, and the Russian constellation, which is called Glonaz, and most GPS 00:57.680 --> 01:02.880 receiver actually are GNSS receiver, they are received currently, all the constellations, 01:02.880 --> 01:10.360 it depends on the antenna, so you have different frequency bands, which are shared or not 01:10.360 --> 01:15.760 shared between the constellations, I'm not a big specialist of that, so I'm not going to go 01:15.840 --> 01:21.280 at length on the matter, but the thing to remember is that with a single antenna, you can 01:21.280 --> 01:30.880 receive the briefing, it's much simpler than if you had different frequencies, but you 01:30.880 --> 01:38.280 have several ranges of frequencies, which have different characteristics, so you have different 01:38.280 --> 01:42.000 kinds of corrections to apply. 01:42.000 --> 01:47.440 There are several precision positioning technologies, so the one I'm talking about is RTK, 01:47.440 --> 01:54.240 which is RTK, which is on the bottom left, which is at the same time the fastest and the 01:54.240 --> 02:00.040 most precise, you can do a very precise positioning with PPP, which is called, which 02:00.040 --> 02:05.280 means a precise point positioning, but you have to accumulate data over a long period, 02:05.280 --> 02:12.760 so it's not practical to use on the vehicle. 02:12.760 --> 02:13.760 How does it work? 02:13.760 --> 02:21.880 I'm not a big specialist of the thing, but the main idea is that you get a reference station 02:21.880 --> 02:28.560 from who's, you know the exact coordinate, you have to calculate the exact coordinates, 02:28.560 --> 02:36.520 and then you can compare the computed positions through the normal algorithms, and 02:36.520 --> 02:45.040 from that you can deduce the correction to apply due to troposphoric and ionostric delays, 02:45.040 --> 02:54.320 which are due to especially to water in that atmosphere, etc. 02:54.320 --> 03:05.640 There are standards to communicate the data, the most, the two standards we are using are 03:05.640 --> 03:15.320 RTCM, which is a standard packet, a standard packet, format for exchange of GNSS data between 03:15.320 --> 03:25.880 a receiver and software, RTCM comes from radio technical commission from maritime services, 03:25.880 --> 03:32.600 so it's an open style, it's a bit like some national standard, it's open, but you have 03:32.600 --> 03:42.760 to pay to get it, and you can't share it, it's not open source, but we can get the documents 03:42.760 --> 03:52.360 anyway, and the other standards I didn't talk about is N-trip, which is the way to stream 03:52.360 --> 03:58.040 this data over the internet using something that looks like HTTP. 03:58.040 --> 04:02.600 Actually, there are two versions of N-trip, one and two. 04:02.600 --> 04:10.160 The first one was based on an old audio streaming protocol, and it was roughly based 04:10.160 --> 04:16.720 on the IDs of HTTP is 0.9, which was the first version of HTTP, but it's not really 04:16.720 --> 04:23.200 HTTP, it's really quite messy, and there was a revision with which is called N-trip 2, 04:23.200 --> 04:32.160 which is more compliant with HTTP 1.1, which is easier to use with regular webs of 04:33.120 --> 04:44.160 so there are a lot of clients, software clients which have been implemented with, I mean, 04:44.160 --> 04:52.160 we have quick and doubting implementation, or using the HTTP libraries from the 04:52.240 --> 05:03.120 voices from the mobile phones, but the protocol is not, it's designed to transmit 05:03.120 --> 05:10.160 RTCM packets, but it can actually transmit anything in the specifications, there are no, 05:10.160 --> 05:18.400 you can transmit any kind of binary data, so you can transmit proprietary protocol if you want, 05:18.480 --> 05:28.320 and in general, that's what you do. So ATK, how does it work? You need a reference base for which 05:28.320 --> 05:38.640 you need to determine the precise position within a few millimeters, and from then you can compute 05:38.640 --> 05:45.600 from a mobile, from a mobile vehicle, which we call the rover, you can compute 05:45.600 --> 05:51.040 either the absolute positioning, geographic, if you, your base is precise enough, and you can 05:51.040 --> 05:57.600 also compute the relative positioning, so you get incremental positioning from one position to the next. 06:00.160 --> 06:05.920 Ruravos must be close to their base, because we don't transmit, we don't really transmit 06:05.920 --> 06:14.960 corrections, actually we transmit satellite observations, but then the algorithm comes to the difference, 06:15.280 --> 06:23.120 between the actual position and corrected positions, so it works like a correction in the end, 06:23.120 --> 06:29.920 but for a correction to be usable, you need to be close to the base, which means about 30 06:29.920 --> 06:38.720 kilometers maximum, perhaps 100, if you get a slightly degraded precision, you lose a few millimeters 06:38.720 --> 06:47.600 for each 10 kilometers, you farther from the base. So you can do local deployment, in general, 06:47.600 --> 06:55.360 that's what you do, it's especially popular for farmers in France, because there are currently 06:56.240 --> 07:00.640 commercial networks, which are very expensive, you don't need to install your own base, you just 07:00.640 --> 07:06.560 take a subscription to a commercial service, and then you install on your tractor, 07:07.360 --> 07:11.440 then it's a serious thing to put on your autonomous tractor, and you pay a lot of money, 07:11.440 --> 07:21.840 it's in a thousand of euros per year, so it's very expensive, and it's better, it's much 07:21.840 --> 07:30.480 less expensive currently due to the hardware prices, having been very cheap now, it's very 07:31.440 --> 07:40.000 is very cheaper to install your own base and your own equipment, so this is how it works, 07:40.000 --> 07:46.560 the service, it's very complicated, so I'm going in more in detail, this is a regular 07:47.520 --> 07:54.000 high-track in general, you need at least four satellites, receive revsions for at least four 07:54.000 --> 08:00.000 satellites, and you compute, like you do in your phone, etc, you compute your position, 08:01.200 --> 08:08.000 if you had a base, the base can send you its own observation, and it's not its own position, 08:08.000 --> 08:14.160 so from that you can compute the correction to apply to get a synthetic position, 08:15.200 --> 08:22.800 so the idea is you have a local base, you can have a radio link from your base, from your local 08:22.880 --> 08:31.520 base to your local tractor or client or anything, the idea is that we send it instead on the internet, 08:32.160 --> 08:38.880 and we the rovers instead of adding a radio link, just use a standard mobile connection, 08:40.560 --> 08:47.440 so the idea is to have a cluster, the software that does this is called a cluster, and you can 08:47.840 --> 08:59.120 neutralize as many bases as you want, so that's what Santipet did, but the problem they had was that 09:00.240 --> 09:11.440 they had about 1,000 bases in 2023, and the software we use, which is written by the German 09:11.520 --> 09:18.640 federal agency for cartography, it was not written for this use case, it was written for a 09:18.640 --> 09:31.840 much smaller user base, so it was fully, it was beginning to have a reliability problems over 09:31.840 --> 09:41.520 1,000, 2,000 streams, so we we rewrote it in a totally different architecture, 09:42.320 --> 09:48.320 the rather you can do it by yourself, it's about there are dots on the Santipet site, 09:49.120 --> 09:58.880 it's about 250 to 300 euros, it's a bit of work, you can you can assemble it in about half a day, 09:59.440 --> 10:05.920 on the right, personally, I'm not a farmer, so I use it on trains to get the train speed, 10:05.920 --> 10:12.560 but it's an ideal way to look like a geek to their other passengers, because I attached the 10:12.560 --> 10:19.600 antenna to the window with the, I don't know, the general people are very polite, 10:19.600 --> 10:30.160 but that's very, very, very significant thing, so this is the current, the current status 10:30.160 --> 10:37.120 of Santipet in Europe, the green dots are the bases which have been correctly registered, 10:37.920 --> 10:44.400 as you can see the bases is French and we have a strong community here in Hungary, and it begins 10:44.480 --> 10:54.640 to spread in Northern Europe, I forgot to, we also have bases, I think the map is further 10:54.640 --> 11:00.080 in the presentation, we also have a few bases in Canada, I'm not sure, but Greenland, 11:02.480 --> 11:10.880 and it's mostly European, there is a lot of free software in Santipet, 11:11.840 --> 11:19.520 the main software which was, which enabled an installation of bases, this is Ertica base, 11:19.520 --> 11:24.400 by Stefan Pinot, where the millipet cluster, which I'm going to talk about, 11:25.600 --> 11:31.120 which I'm talking about, and so you see, that's told with this presentation from the 11:31.120 --> 11:39.200 Julia Ansla presentation, which is on GitHub, so Ertica base you need the software, 11:39.280 --> 11:44.880 you need the Raspberry Pi, you need the good antenna, and as you can see, you need to put it on 11:44.880 --> 11:52.960 the key of your sky, so this is where Stefan put it here, it was on his apartment building, 11:54.160 --> 12:02.080 so yes, they do well map, as you can see, there is nothing much in North America except Canada, 12:02.720 --> 12:11.120 but we're working on it, the redest of bases, we are currently at, sorry, the axes are 12:11.120 --> 12:19.440 very difficult to read, we are currently at over 12 hundred bases, but five hundred of which are 12:19.440 --> 12:29.680 out of France, very well, currently, this is the latest, it began in 2019, so this is the latest, 12:30.240 --> 12:40.720 the latest growth chart, 70% of the bases are underl by farmers, and we have a lot of private 12:40.720 --> 12:48.960 use, which is especially people working in service, and we have a several French Institute, 12:48.960 --> 12:55.120 which are, which are deployed bases, this is the client number of client, not number of 12:55.120 --> 13:02.960 base, number of clients, typically since it's mostly used by farmers, the peak that you see 13:02.960 --> 13:10.320 is the auto-insowing for wheat and barley, and there's another peak at the beginning of the spring, 13:11.200 --> 13:20.400 so the current, the current record is five hundred clients, so the clients, we have also statistics 13:20.480 --> 13:28.080 by the clients, the stuff we have types, you can use it on Android, apps to communicate with 13:28.080 --> 13:34.400 food Bluetooth, we have your receiver, so we can have, there is the equivalent of the user 13:34.400 --> 13:43.280 agent in the protocol to determine the software of the client, we have a base monitoring to 13:43.360 --> 13:50.800 so that you can switch out bases, which have a lower quality, sometimes you can have an antenna, 13:50.800 --> 14:00.720 which is pushed away by the wind, so it breaks precision, it's anticipated works with one 14:00.720 --> 14:07.920 of the French, a residential genesis per manor, which is the permanent national genesis network, 14:08.000 --> 14:16.720 which does archiving of position and streams, so this is a photograph of the modules, there are 14:16.720 --> 14:26.240 many chip makers, the most well known was U-blocks, which was from Switzerland, and now there 14:26.240 --> 14:35.200 are also Chinese chips, UM-980, which I haven't mentioned in the presentation, so what is 14:35.200 --> 14:44.640 it? It can be used in caves, sorry, it can be used, sometimes in houses, if you're not too far 14:44.640 --> 14:54.400 from the window, but you can be used for a band planning, if you want to, especially for 14:54.400 --> 15:01.200 a band feedback, if you want to have precise recording of, for payment sidewatch surfaces, 15:01.200 --> 15:09.200 etc, or telecom shelters, so it's very useful, this is a comparison between the internal 15:09.200 --> 15:17.200 camera of DPS of a GoPro camera on the left, and with the article on the right, so if you're doing 15:17.200 --> 15:24.080 a service for an open street map or other, it yields a much better point quality, you can use it 15:24.080 --> 15:30.560 on the high-speed trains, it depends on the window, that you have, it's more and more difficult, 15:30.560 --> 15:38.480 because there are thermal, formal treated windows, which prevent GPS signals from crossing the 15:38.480 --> 15:47.120 windows, but I sometimes add fixes at 300 kilometers per hour, so I was happy, you can use it for 15:47.120 --> 15:55.120 precise speed measurements, because GPS doesn't know the speed, it determines the speed by delta, 15:57.600 --> 16:07.120 position delta relative to time, so actually the lower, you speed is, and the most 16:07.200 --> 16:16.640 difficult is to measure it precisely due to the precision, so with article you can get much better 16:16.640 --> 16:24.800 much better speed precision, you don't have to statistically smooth the measurement over 10 seconds, 16:26.800 --> 16:35.600 the other thing, actually this is why I started millipede, it's that I want, I don't want to use it 16:35.600 --> 16:45.440 in a field, so I use it in a car or in a train, and of course as long as I get away from the 16:45.440 --> 16:53.360 base, I need it to reconfigure my client to use the next base, so I needed to determine what the next 16:53.360 --> 17:04.560 base was, which is to tell you extremely boring, so I want a patent script initially to do that 17:04.720 --> 17:12.000 for me instead, because the client sends its position to the server, so you can pick up the 17:12.000 --> 17:19.600 next, the closest path for me, for instance, so it's, it opens a lot of new use cases, 17:21.760 --> 17:31.280 there are commercial networks, which gives you virtual bases called BRS bases, it's more, 17:31.840 --> 17:38.880 much more complicated, because you need a lot of math, but in Centipede we don't need it much, 17:38.880 --> 17:46.320 because we have a much bigger base density, so VRS is mostly used, when you have a base is 17:46.320 --> 17:53.920 a space 200 kilometers, in Centipede we have a very good coverage of French or France, sorry, 17:53.920 --> 18:00.880 and Hungary, in France you are very, really more than 30 kilometers away from a base, 18:02.160 --> 18:10.960 you will have a Neo4, which is a special case for John Deere tractors, because they are all 18:10.960 --> 18:18.480 equipment in John Deere tractors, which has probably RS-232 link, we have limited the full put, 18:18.480 --> 18:27.840 so we need to reduce the stream throughput, so it's under that limit, and for that we convert 18:28.800 --> 18:36.320 the packets from with a lower precision, but which is still enough for our ATK, 18:39.200 --> 18:46.720 so the software is written to have a smaller memory footprint as possible, so the current 18:46.720 --> 18:58.720 cluster with 200,000, 500 bases is about 15 megabyte in memory, and it doesn't consume much 18:58.720 --> 19:09.200 CPU ever, it would run on our Raspberry Pi easily, I want to get into much detail, 19:09.200 --> 19:17.840 we support TLS of course, because John Deere tractors is a personal data potential, so 19:17.840 --> 19:25.840 we need to encrypt that if you can, currently not many clients are able to run TLS, 19:27.120 --> 19:31.200 the only one that I know of is Bluetooth, the NGNSS, which is an open source Android app, 19:32.320 --> 19:36.960 we also support IPv6 of course, just like for them, thank you for them for IPv6, 19:37.920 --> 19:45.200 it's written in C, it's written on previous day, which is my platform with choice, 19:45.200 --> 19:52.320 but it also runs on Linux, it's portable, and the idea to save memory was to get an even 19:52.320 --> 20:00.240 driven architecture using Libent, which is open source of course, so we have about 6600 bytes 20:00.240 --> 20:08.320 precision instead of a full thread stack that the BKJ, the form of cluster had, so it's 20:08.320 --> 20:19.600 much more efficient, the architecture, you can also run the cluster as a monofread application, 20:19.600 --> 20:27.200 but you will of course lose some latency, because you lose the possibility to 20:28.160 --> 20:37.760 do lose any parallelism in your CPU, so we also want a multi-fread architecture, which was 20:37.760 --> 20:45.280 well, about half of the development effort was debugging the multi-fread version, 20:46.640 --> 20:52.640 so it's more complicated, we have workers, which we have the main thread, which fuse 20:52.720 --> 20:59.920 the test, workers, which take the test and execute the test, and this is not even the full 20:59.920 --> 21:10.720 picture, because I have done some loading tests, and the main thread was a contention point, 21:10.720 --> 21:19.040 so actually we can have several thread on the main loop, the source code is on GitHub, 21:19.120 --> 21:30.480 the URL is here, sorry, and it's in production since last year, March 25, it was necessary to be 21:32.560 --> 21:40.720 for the cluster to be able to speed for the sewing season in spring in 2025, 21:41.280 --> 21:49.680 and so currently the new, we deployed the multi-thread version a few weeks ago, 21:51.360 --> 22:02.160 it consumes a lot a bit more CPU, but it will scale more easily to 4 CPUs, so it's better, 22:02.160 --> 22:15.840 and it reduces latency, but AI, since everyone talks about AI, I have mixed feelings about the AI, 22:15.840 --> 22:22.880 but it's very promising, for debug it's very bad, it's totally useless for debugging, 22:23.600 --> 22:33.520 for writing code it can help, for proposing algorithms, I asked it for a way to optimize the 22:33.520 --> 22:46.000 table, the source table, it gave good idea, for code editing, it's sometimes good, sometimes 22:46.000 --> 22:53.360 bad, a lot of valuations, but you can, it's a bit like an intern, you can't find the obvious mistake, 22:53.360 --> 23:04.480 but as soon as the code is a bit subtle, it doesn't yield much, many traits in thing, 23:04.480 --> 23:09.920 and you can be used for offering things like writing tests, so currently the 23:10.400 --> 23:17.600 customer is listed by PTH, which is the well-known, well-known structure to for 23:18.480 --> 23:24.960 networks, well-network of servers, and we are going to work on an Enica service for Wuzul, 23:24.960 --> 23:30.000 don't know, Enica's is a routing, internet routing trick, which allows you to 23:30.640 --> 23:39.680 have a unique, well-addressed, and for the clients to connect automatically to the nearest 23:39.680 --> 23:46.720 server, so it's in-wide use for the DNS, for example, for the root server, but it's a good 23:46.720 --> 23:55.360 use case also for our ATCMcaster, because it means that the base will connect to the nearest server, 23:55.440 --> 24:01.680 and the clients will connect to the nearest server also, so it reduces latency between the base 24:01.680 --> 24:09.520 and the clients, and it simplifies the rather configuration, because you just have one unique address, 24:11.440 --> 24:19.840 whatever your country, so I'm going to be very quick on this one, there are a lot of 24:19.840 --> 24:29.040 especially for HTTP compliance and RTCM compliance, we need a lot of tests to avoid the breaking 24:29.040 --> 24:37.280 things where when we factorize, refactorize code, the third one's test, I have tested the 24:37.280 --> 24:47.440 castor with up to $50,000 connections, at $80,000 it begins to really break, on a small processor, 24:47.440 --> 24:55.120 and the test load and the server were on the same machine, so I think we have a few years, 24:56.640 --> 25:04.160 we have a few of a tranquility regarding two performance, the most useful tool was by grind, 25:04.560 --> 25:17.280 for especially for finding multi-thread bugs, so thank you, if you have any questions, 25:18.880 --> 25:25.840 if you don't have questions, I have put myself a question, why, it's a running joke as post-dames, 25:25.840 --> 25:33.600 so why not rest, because I did not know rest at all, especially for network servers, 25:33.600 --> 25:40.640 so I just decided to go with C, which I know much better, but some day perhaps, I have asked 25:40.640 --> 25:51.200 the devs12, which is the mistrial developer AI model, so it's really a useful tool to 25:51.200 --> 25:57.120 rewrite code or to get code samples on the material, you don't want to, when you don't want to 25:57.120 --> 26:08.880 get into the documentation, when you have a bit lazy, you can have dedicated tutorials directly 26:08.880 --> 26:19.760 for your case, so I run this on my machine using AMD GPU, which is a custom upgraded GPU 26:19.840 --> 26:27.200 of about 300 euros, on a free-based machine running, emilaterally new, to run all 26:27.200 --> 26:38.000 a month to run the AMD GPU, so there was a talk about software in AI earlier, I encourage you to 26:38.080 --> 26:46.320 hear it, to listen to it, and to try yourself, okay, so now for the real questions, 26:51.760 --> 27:03.680 Baba, Niku, thank you, good talk, and like 40, you were saying that you do 27:04.400 --> 27:10.960 GODMS to find the best server for the robbers, but most of the robbers are behind the 27:10.960 --> 27:17.520 40 or 5 genie, I'm there, the bell-nathed, so for the important, the tractors, you said, 27:17.520 --> 27:26.000 they were on mobile or 4G leak, and 40 or 5 genies are the bell-nathed, so you don't really know where 27:26.080 --> 27:34.800 they are, because you will note the location where the nath ends, oh yes, so are you under the 27:34.800 --> 27:40.400 fact that they are all nathed behind the same operator, for example, actually we do not choose 27:40.400 --> 27:44.720 the IP address, I'm not sure I know some the question, the question was about how do we locate the 27:44.720 --> 27:55.840 robbers, actually the robbers sent their own position, okay, so 27:56.240 --> 28:03.600 the robber, they will send their GGA line, yes, but once the connection is established, 28:03.600 --> 28:12.400 but to find the best server to connect to for the DNS to answer the good IP, the closest, oh 28:13.600 --> 28:21.840 it's a magic of handicast, with handicast you have always had the same IP, and it's a routing, 28:21.920 --> 28:28.400 the internet routing that does this stuff, the routing, the routes you to the nearest instance 28:29.200 --> 28:36.160 of the caster, it's not deployed currently, currently we have only one caster, but it's like with 28:36.160 --> 28:43.840 DNS wood server, you have 13 server configured in your PC or in your local resolver, 28:43.840 --> 28:50.320 and actually there are behind each of these 13 IPs, there are 50 instances all over the world, 28:51.280 --> 29:01.680 so it's a magic of handicast, thank you, you showed us on the map that there is a quite good 29:01.680 --> 29:07.360 coverage in France in Hungary and in none of the surrounding countries, is there a reason for that? 29:08.560 --> 29:15.440 I don't for France, I can explain because it's started in France, for Hungary I think there is a 29:15.520 --> 29:24.400 strong community which decided to share, we have a few bases in Belgium, I can't really explain 29:24.400 --> 29:31.920 Julian, Julian knows probably more about this than I do, but we hope it will expand all over the 29:31.920 --> 29:38.320 world of course, so if you are from any country, don't hesitate to create a local community. 29:39.200 --> 29:49.280 But, currently Hungary is an accident basically, so Hungary is just an accident, perhaps 29:49.280 --> 30:02.640 I can't express, we don't have one growing long, but sorry Greenland, we say, I think it's 30:02.640 --> 30:19.200 fortunate, thanks, elaborating on that, how to start the community, what is needed to 30:20.160 --> 30:26.160 mount the base station, do I need to call up someone to precisely measure its location after 30:26.160 --> 30:35.280 installing the antenna? Sorry, you want to know what to install a base or there's a lot of 30:35.280 --> 30:46.240 documentation of the centipede site, centipede.fair, you can have a fully assembled base or you can 30:46.240 --> 30:55.360 do it yourself if you prefer and then you don't even have to share your data if you don't want to, 30:55.360 --> 31:04.240 you can just use your base locally and see with a close pharma or users if you want to participate. 31:06.240 --> 31:12.880 So, pharma is useful and there are about 70% of the network, sorry, I don't know what to do. 31:12.880 --> 31:17.680 You said agriculture is about 70% of the use, yes, yes, yes, yes, yes, yes, what do you 31:17.680 --> 31:27.360 probably have individuals and the institutions that use it are mostly geographical 31:27.360 --> 31:38.800 cartography users or people who contribute to open split map, for example, ever on the free time 31:38.800 --> 31:45.520 or professionally because you get much more precise positioning, especially in terms 31:46.480 --> 31:52.240 because we have a building, it's not always easy to get precise positioning. 31:52.240 --> 32:00.240 Okay, I have a question regarding how the way I need, you talk about memory consumption which 32:00.240 --> 32:12.400 is quite low, but regarding the CPU, it's written, you need several gigahertz, does it possible 32:12.400 --> 32:18.080 to have a CPU with a slow, slowware frequency? 32:18.080 --> 32:23.360 Yes, yes, it doesn't limit the threshold, the minimum requirements. 32:24.560 --> 32:30.560 Oh, the minimum, I don't know, the castor doesn't need to do a lot of computing. 32:32.320 --> 32:37.360 So, the main task is receiving and sending of the network and computing, 32:37.520 --> 32:46.240 RTCN checksums. So, on the client, the algorithm is run by the chip. 32:47.280 --> 32:52.480 So, it's included in the chip, if your chip supports RTK, you don't have to do anything on your phone, 32:52.480 --> 32:57.760 your can run, you can run it on the phone anyway, the algorithm can be run on the phone, 32:57.760 --> 33:00.720 but in general, it's better to let the chip do it. 33:00.720 --> 33:10.560 Yeah, just to complete the answer, but the usefulness, it is a very crucial for public works. 33:11.760 --> 33:18.080 In France, we have public utilities, distribution network, operator, for instance, for electricity, 33:18.080 --> 33:25.520 or whether supply that installed basis, just to survey where the excavators are digging, 33:26.400 --> 33:38.240 or to manage the confession between the executed works, also, so it's far beyond agriculture. 33:38.240 --> 33:46.880 Agriculture started it, but public works will widely spread for their own usage. 33:46.880 --> 33:54.720 And as Pierre said, it's really important because the commercial networks are really expensive. 33:54.720 --> 34:00.880 So, we will take really great benefits from a collaborative network like Santibet. 34:05.120 --> 34:07.120 Then we've got one time for one more quick question. 34:10.400 --> 34:13.840 Just to complement, we're using information logic for migration, 34:13.840 --> 34:18.080 migration, migration, and migration monitoring. Just to conclude a lot of your 34:18.080 --> 34:23.520 comments about running the algorithm on the chip, I used to enjoy having RTK Lib running on 34:24.400 --> 34:29.840 Android. There's no longer running off since Android 11 or something. 34:29.840 --> 34:35.440 I published an issue on the GitHub, but it's not Android, it's not RTK Lib, 34:35.440 --> 34:39.280 it's not no longer to be compatible. So, my question was what is the open source, too, 34:39.280 --> 34:44.560 that I could run on Android since I only know of free search as a free of charge, 34:44.560 --> 34:51.760 but I don't know of open source project, probably I can run on my Android to merge the rover. 34:51.840 --> 34:58.960 There was an app, I don't remember the name of, which used RTK Lib on Android, 34:58.960 --> 35:03.680 but I assume it's an older version of RTK Lib, I don't know. 35:03.680 --> 35:11.200 And for currently I use Bluetooth DJNSS, which doesn't do the algorithm itself, it uses the 35:11.200 --> 35:19.040 chip. So, it just transfers the data, the position to Android using the mockup location. 35:19.920 --> 35:26.960 And it connects, of course, to the castor, through the internet, it does IPv6, it does TLS, so it's pretty good. 35:28.960 --> 35:35.680 Could you set the bases up as castors, so each is its own server and you don't have a central server that's 35:35.680 --> 35:44.240 taken multiple traffic? Sorry, I missed part of the questions, could you say it again? 35:44.480 --> 35:51.840 So, when a client is a rover is told which base to you, so which server to use, 35:52.560 --> 35:59.440 could it be told the individual base, so each base is its own server running a very low rate 35:59.440 --> 36:10.320 castor? Yes, you can do that. Actually, the first version of the castor, I wrote to use the 36:10.400 --> 36:16.000 previous, I mean, the production server or centipet, which we didn't have the near location, 36:16.800 --> 36:21.360 and use it just as a proxy, you can use a millipet as a proxy. 36:21.360 --> 36:29.120 If you don't want to send your geolocation to anyone else, then yourself. So, you keep your 36:29.120 --> 36:35.760 geolocation to yourself and the external server only sees which bases you are subscribing to. 36:35.760 --> 36:42.560 I'm just a little bit of a question. I think we have time, thanks. Thanks for meeting.