WEBVTT 00:00.000 --> 00:18.240 Please welcome our next speaker Thomas Goodchens, who will talk about Mish Asik, which by 00:18.240 --> 00:23.600 the sheer amount of people must be something popular. 00:24.480 --> 00:31.200 And actually it is good. But one thing in mind, we are here in open source conference. 00:32.000 --> 00:40.320 And if Mish Asik is something not, it's an open technology, keep in mind, it's based on proprietary 00:40.320 --> 00:49.200 and patented technology. But it is cool. Thomas, stages yours. Thank you. 00:49.200 --> 00:58.800 So, okay, good evening. You could say evening. Just let me introduce myself to our three words. 00:58.800 --> 01:03.680 I'm Thomas Goodchens, I'm one of the call-the-banner-posts of the firmware of Mish Asik. 01:04.400 --> 01:10.560 And everything about Mish Asik is open source down to the actual radio chips we're using. 01:11.120 --> 01:17.440 This is indeed patented and proprietary technology. But this also goes for every other 01:17.440 --> 01:28.720 software solution that uses lower modulation. We can decode it with a STR. But this was basically 01:28.720 --> 01:35.440 reverse engineered. Okay, let's get started. Who in the audience knows Mish Asik? 01:37.280 --> 01:45.440 Okay, so I can skip the first 10 slides of my presentation. That's okay. This is basically what 01:46.320 --> 01:53.440 looks like. So for user, you take a Mish Test Ignote, the node hardware, pair your phone with it, 01:53.440 --> 01:59.520 download the software. Of course, off-grid means you're already downloaded the software. And then 01:59.520 --> 02:05.840 you pair it to the node and then you use it like this. Oh, now something broke down here. 02:06.000 --> 02:16.480 This is also the firmware in this case. It's showing telemote data and progress slides. 02:17.280 --> 02:26.000 Okay, next question I always almost always get is how fast is it? And the answer is it depends. 02:26.160 --> 02:36.080 Because as you see here, we have several presets in the firmware that have different link budgets and 02:36.080 --> 02:42.480 throughput. The data rate that is on this diagram here is not the net data rate. This is 02:43.360 --> 02:50.320 including the protocol overhead. So you won't get this kind of throughput if you set it to this settings. 02:51.200 --> 03:01.200 The last entry very long slow is erased from the slide because we deprecated it in the firmware. 03:02.240 --> 03:09.600 It was basically unusable for normal people. You need a special node hardware. But this was used 03:09.600 --> 03:17.360 for range testing or range record testing, I'd say. And I left it in there because obviously, 03:17.360 --> 03:23.440 if you take the radio parameters, you can still use it and recreate it. But it won't work with any 03:25.440 --> 03:33.120 stock node hardware you can buy. The first setting short range turbo is a small one there. 03:33.120 --> 03:38.880 You see the bandwidth is 500 kilohertz. In Europe, you don't have the 500 kilohertz at all this 03:38.880 --> 03:45.920 puzzle. So the short turbo can be set and then the firmware reset it to the next speed setting. 03:45.920 --> 03:55.360 Because it's not usable in Europe. What is link budget and data rate? You see here, most of the 03:55.360 --> 04:04.320 presets, they have very similar link budget. And then the throughput increases the link budget 04:04.320 --> 04:10.960 decreases. Everyone know what link budget is. It's actually how far you can get with the 04:10.960 --> 04:18.480 signal before it starts to deteriorate and you can't decode it anymore. The third question we are 04:18.480 --> 04:23.840 getting on a booth is what can you do with it? You can do everything off-grid. You can go camping. 04:23.840 --> 04:29.040 You can go to Burning Man as you see here. The slides were prepared by colleague from the US. 04:29.040 --> 04:36.400 So it's with your S centrate. But you can also use it for disaster communication. If the normal 04:37.840 --> 04:43.920 mobile phone grid is not available anymore, you can use it for communication with your pairs. 04:45.120 --> 04:51.600 Okay, now let's see what we do. Obviously you need a lower radio. You can buy this. They start at 04:51.600 --> 04:57.280 about 10 bucks and then you get edit. Where you add a text and shipping and then you're about 20 bucks. 04:57.280 --> 05:03.520 But still very affordable. And you usually pair it with your phone and use it with the 05:03.520 --> 05:08.880 other software. But you also have standalone notes in development and somehow available already. 05:09.920 --> 05:19.520 And also you can pair it with your computer, of course. Now, a machine network means the 05:20.240 --> 05:26.400 message is traveled to the network. And somehow we need to tell the message to stop traveling. 05:26.480 --> 05:32.880 And this is what we do. We are a hot count. The standard hot count is 3. And as it is written 05:32.880 --> 05:40.080 in the top, really 3 is fine. Most people ignore this really 3 is fine and sell it to 7. 05:42.320 --> 05:48.720 That's a bit overkill. Because at the moment you see five radios here. And this is actually 05:48.720 --> 05:55.840 what 3 means. Every hot decreases the number by one. And when it reaches 0, it won't be 05:55.920 --> 06:02.640 retransmitted anymore. Some people in certain technologies need four or maybe five. But 06:03.520 --> 06:12.880 6 or 7 is almost never really necessary. Because it doesn't give you any advantage anymore. 06:12.880 --> 06:19.680 Because you create a rebroadcast storm in your network. You won't be able to benefit from the 06:19.680 --> 06:25.520 higher count. So please don't set it like this. If you put a higher number than 7 into the 06:25.520 --> 06:32.960 optic application, it will be worth two, three. Okay, then you can expect data from the network. 06:32.960 --> 06:40.400 You can bridge it via MQTT to, for instance, home control solutions or 06:41.840 --> 06:47.200 extractor raw data. You see this is really raw data. Because you can't value read it. 06:47.200 --> 06:54.160 The string in the MQTT explorer. And this is because we are using protobuff encoding and not 06:54.160 --> 07:00.400 JSON or something, you can really digest. So you really need to decode the message first and then 07:00.400 --> 07:10.320 you can process it. Now I'm going to go a bit into details of the null configuration. We have 07:10.320 --> 07:16.000 roads. These roads were really introduced with a version two firmware that didn't exist before. 07:16.000 --> 07:23.520 And the two original roads we had were basically client and router. All the others they were 07:23.520 --> 07:32.000 added later for special use cases. So the road is really to tell your node what it should be. 07:32.640 --> 07:39.200 So the client is obviously very seclined. Client mute as you see is a client that doesn't 07:39.200 --> 07:45.760 be broadcast or client hidden is a client that doesn't even announce it's there. The tracker 07:47.920 --> 07:58.400 is basically a client that is a bit optimized for a position display or transmission 07:58.720 --> 08:09.280 because it gives an emphasis on the text message but on the position data. So it's just a different 08:09.280 --> 08:16.480 preset for the firmware. And I'm going to skip a few now. The TAC tracker is one special one because 08:16.480 --> 08:24.240 it talks for protocol. We have an application called ATAC and the TAC tracker roll sends 08:24.240 --> 08:33.120 compatible frames to an ATAC server and also very this. The real important information here is 08:33.120 --> 08:39.040 the last two lines, the router and repeater roll. A repeater is an invisible router. So that's it, 08:39.040 --> 08:43.920 but the router is really a bit problematic because it was abused in the past and is still abused. 08:43.920 --> 08:51.200 What the router does is doesn't change the behavior of the node except in a few spots where 08:51.280 --> 08:58.640 power management is concerned and also in the way the mesh works. Oh, the range test I want to show. 09:02.000 --> 09:08.640 The router will re-broadcast first because if one of the nodes receives a package, 09:09.280 --> 09:18.960 it will re-broadcast it. If the hop timer is not expired. So the time frame where it is repeating 09:19.040 --> 09:25.440 depends on how strong the signal was that was received. A weaker signal will re-transmit faster 09:25.440 --> 09:32.400 than a strong signal. So the nodes on the edge of your reception area where we broadcast faster. 09:33.120 --> 09:42.560 So this is for coverage of course. Now the router is designating a node that is an exposed area. 09:42.560 --> 09:48.560 So this one is preferred when this delay timer is running. So router will always re-broadcast first 09:48.800 --> 09:55.760 before client. And please, a router is not something you put on your rooftop. Your rooftop is 09:55.760 --> 10:02.160 not an exposed position. An exposed position would be a radio tower, a mountain top, a tall building 10:02.160 --> 10:12.240 and by tall amenities, 20 stories. So the router is really something that is an exposed position. 10:13.120 --> 10:20.000 Because if you put a router on your rooftop or in your living room, it will ingest messages 10:20.000 --> 10:25.920 and not pass them on because by re-broadcasting first from a not optimal radio position, 10:25.920 --> 10:32.480 it will eat and hop and so you would decrease your coverage. And in the past we had a special 10:32.480 --> 10:40.560 role that was called router client. It was a router in timing and was a client in connectivity. 10:41.040 --> 10:46.160 Many people were using that and many people were harming their networks by using it. 10:46.160 --> 10:50.160 So we deprecate it to roll and you set it nowadays. It's still in the firmware. 10:51.440 --> 11:00.160 It will refer to client and at the moment we recommend in larger networks to set clients 11:00.160 --> 11:06.560 that you have in your living room to actually client mute. Because so it won't re-broadcast. 11:06.640 --> 11:13.280 You receive your stuff and you set a router or there will be a router late. So no, not a router. 11:13.280 --> 11:20.320 I'm sorry. Not giving you fake news. A client on your rooftop or a router late. 11:20.320 --> 11:24.880 A router late is a power management router but we broadcast a client. 11:27.280 --> 11:30.720 So please don't put routers in your vicinity. 11:31.040 --> 11:38.480 Okay, next question we're getting on the boot. How far does it go? This is actually the standing range 11:38.480 --> 11:48.160 record. 331 kilometers. From a mountaintop in northern Italy to a mountaintop in Slovenia. 11:48.880 --> 11:56.480 And as you can see in the bottom the Fresno frame already touched the surface. So it was barely 11:57.440 --> 12:04.560 that this connection could have happened and also this was in very low, very slow and low setting. 12:04.560 --> 12:12.720 The one that was marked red in my previous slide. So for range records or inch testing you can really use that. 12:13.600 --> 12:18.640 But not for much else because transmitting one of these frames takes several seconds. 12:19.600 --> 12:27.280 And of course you need luck to have not no interference within these several seconds. 12:27.280 --> 12:31.280 So this took a long time till this record was seen. 12:32.560 --> 12:37.600 Okay, what we also have at mesh testing is a coverage tool. So if you're planning your local network, 12:37.600 --> 12:44.800 you can use site meshtastic.org and see what potential 12:45.760 --> 12:52.240 re-broadcast position or other position really means for your coverage wise. This is actually 12:54.080 --> 13:02.160 model with topology. So it's fairly accurate what it doesn't have is a built up space or 13:02.160 --> 13:08.640 or woods and something like that. I know there are better models. The one we are using is available 13:08.640 --> 13:22.000 worldwide. So it's a planning tool. Okay, where are we using lower? In the 868 SOD bond. 13:23.120 --> 13:27.600 Some say I S m and but technically it's an SOD bond. You're allowed to go up to 13:27.600 --> 13:40.880 27 dBm which is roughly I think 500 milliwatts. In the 433 S m band you are up to 10 dB and also 13:40.880 --> 13:49.360 on the 2.4 GSM. A gigahertz ISM band. Mesh testing can use all three of these 13:50.000 --> 13:58.000 radio ranges. Obviously the preferred one is 868 because of the higher transmit power and also the 13:58.000 --> 14:09.760 433 ranges very congested. Most radios can do up to 22 dBm. There are radios that can do 27 dBm 14:09.760 --> 14:18.240 but they usually include a power amplifier. And also ideally it would also include a reception 14:19.360 --> 14:26.320 amplifier. So it's not really much use shouting out your stuff and not hearing anything. 14:27.680 --> 14:36.240 Okay, last one especially about the low power part of lower the S-1262 is a 4 milliampere 14:36.240 --> 14:42.560 actively receiving. So we are in Mesh testing. We are in continuous receive mode and it uses 14:42.560 --> 14:51.680 next to none of the power of the device. Okay here again which frequency to use. I started to 14:53.520 --> 15:00.400 explain it. 433 is really congested with the standard settings. We have 4 frequency slots there. 15:00.400 --> 15:11.280 We can use on 868. You see it around here. There's a lot of different presets in this area and all 15:11.280 --> 15:18.800 of them are almost all of them. I was treated to 1% duty cycle if you don't do frequency hopping. 15:19.360 --> 15:25.920 With Mesh testing you can't do frequency hopping because for that you would need to have very 15:26.000 --> 15:32.000 good synchronized receivers and transmitters and in a peer-to-peer network this is just 15:32.000 --> 15:40.240 not feasible. Believe us we tried. Okay so we are restricted to slot that has 10% duty cycle. 15:40.240 --> 15:46.640 So at the moment we have in this area only one usable frequency on the default setting. 15:46.960 --> 15:55.200 That's not really that because you will find each other more easily. In the US they have 15:55.200 --> 16:02.400 I think 104 slots available which is much but you can't find each other that easily. 16:05.120 --> 16:10.240 Okay and also the transmit power 500 milliwatts. So that's what we're going to use. 16:11.200 --> 16:17.680 Now you see the there are still other frequencies. This is designated here for frequencies 16:17.680 --> 16:28.480 with 2 watts or 500 milliwatts. You see the 10% for access points. So you have to use fixed 16:31.600 --> 16:36.720 locations and kind of wrong with them and also they are only 200 kilohertz or default setting 16:36.720 --> 16:42.720 uses 250 kilohertz. So in the future it would be possible to use these for additional frequencies 16:42.720 --> 16:47.840 with different presets and with the detection rather than not a stationary or moving. 16:49.120 --> 16:58.240 So we're still evaluating this for the time being we only have the slot at 865.5.525. 16:58.240 --> 17:04.400 So this is the only usable frequency in Europe. Okay then a word on security. 17:05.360 --> 17:12.400 Mashedastic is encrypted. Mashedastic is encrypted with an AES 128 default key. 17:13.600 --> 17:18.160 This default key is baked in the firmware so you could debate if it is encrypted because the key is 17:18.160 --> 17:23.440 public. But this is only for first discovery. If you want to build your private network of course 17:23.440 --> 17:32.480 you can change the key and the Mashedastic supports up to AES 256 bits. So this is pretty secure. 17:33.360 --> 17:40.160 This means the channels which are logical channels are encrypted by this key and you can program 17:40.160 --> 17:48.240 up to 8 keys into the device so we can let's say program 8 user groups inside with different 17:48.240 --> 17:55.360 encryption keys. If you send direct message you are switching to a different encryption scheme 17:55.360 --> 18:00.080 with public and private keys. So the notes need to do a key change first. 18:01.040 --> 18:09.200 This is not really secure because it doesn't do authentication or ident checking because a note 18:09.200 --> 18:14.240 would accept the first key it has. It hears from another note in the note info package as a valid one. 18:14.880 --> 18:21.360 Just if the second note info package has different key then the key in the app turns red and you see 18:21.360 --> 18:27.200 there is something wrong there. That for instance happens if you reset the note to factory default 18:27.200 --> 18:34.080 and the new key is generated. Then all your peers need to delete your entry in the database 18:34.080 --> 18:42.640 and then let you rediscover your device. Still pretty secure for the future we are planning an 18:42.640 --> 18:48.800 extension using a hardware encryption chip because it's better against the reading out the 18:48.800 --> 18:54.640 keys from the flash of a recovered device. On the other hand it's going to be a bit more 18:54.800 --> 19:00.560 expensive because it's an hardware encryption chip but it's optional. So the basic encryption 19:00.560 --> 19:08.320 scheme on a scheme on change so you're still going to be able to message people that 19:08.320 --> 19:14.880 don't have this hardware chip and vice versa. Okay what different hardware can you use where 19:14.880 --> 19:22.080 commodity hardware? As I said the cheapest one at the moment is the one below in the middle. This one 19:23.040 --> 19:32.160 here this costs recommended retail price $9.95 including shipping and European value at a 19:32.160 --> 19:38.640 tax so it's going to be a bit more expensive but still this is quite good for an SX-1262 chip 19:38.640 --> 19:45.760 but it's a second generation value and an ESP32 processor. The other ones are a bit more 19:46.720 --> 19:53.200 expensive at the moment the most expensive ones are these two here the Vismesh and the 19:53.200 --> 20:01.360 Lily Go Taco. They both contain a Nordic semiconductor chip so are very power-efficient and one has 20:01.360 --> 20:09.600 a OLED display and the other one in E paper. The one you see at the top left is one here as well 20:09.600 --> 20:17.440 and a colleague that did the introduction showed me here as one too. This is actually a very 20:17.440 --> 20:25.360 recent device was developed by a CIT Studio. It's a card tracker and it has about two days of 20:25.360 --> 20:33.200 battery runtime if you use it on a not too busy channel and your territory was a radio and it 20:33.200 --> 20:38.640 costs about a when it is here including the taxes and the shipping costs about 50 bucks. So this 20:38.800 --> 20:47.040 pretty decent it's IP67 and so it does prove and limited waterproof. It contains the GPS 20:47.040 --> 20:56.880 tracker module, radio and temperature probe and I think accelerometer. Okay next thing we have a 20:56.880 --> 21:04.000 standalone hardware most of this is still in development because we are doing a new user interface 21:04.080 --> 21:11.120 for the nodes. The user interface is not really user interfaces and application so it uses the 21:11.120 --> 21:19.920 node API pretty much like the Android or Apple app would also do which means the node can only 21:19.920 --> 21:27.680 use one of these API interfaces so if you have the graphics where I running on your node or connected 21:27.680 --> 21:34.160 to your node you can't use Bluetooth API anymore or the serial API or the Wi-Fi API. So only one 21:34.160 --> 21:42.080 connection at the time so the standalone node is really standalone. Okay and we have 21:42.960 --> 21:53.520 SBC hardware which contains Raspberry Pi and other stuff up left is the risk 5 processor architecture. 21:53.600 --> 21:59.840 We have to start up Raspberry Pi and we have at the bottom we see the open WW1. 22:00.880 --> 22:07.520 Mesh testic is also running as a Linux demon you can compile it as a demon and access either 22:07.520 --> 22:15.280 SPR connected or USB connected radios. Part of this is still in the future you see at the top 22:16.160 --> 22:22.880 USB hub with four radios connected. This actually works in a lab. The four radios have for 22:22.960 --> 22:28.080 different serial numbers so you can attach a mesh testic demon to each of them and route between them. 22:31.520 --> 22:36.240 So mesh testic is open source I said it in the beginning. You can find us on GitHub, 22:37.840 --> 22:43.440 send pull requests try to understand the firmware and ask us on this code if you don't understand 22:43.440 --> 22:48.320 the firmware. Everyone is there and you'll get an answer in time. 22:49.280 --> 22:59.120 Okay a bit about deployment and inner workings. We are using platform. As a development environment 23:00.240 --> 23:08.640 we're using the Arduino stack as an abstraction layer because we're supporting different radios. 23:09.520 --> 23:19.760 Radio MCUs and we also developed our own portability stack to make an Arduino application one on Linux as a demon. 23:21.760 --> 23:29.520 The protocol itself uses the Google protocol buffers and also the data storage on the node itself. 23:29.520 --> 23:37.040 So the storage of the configuration and storage of the node database is also protocol serialized. 23:37.200 --> 23:43.600 So if you want to talk to a node for instance through the API that was used by the by the 23:45.840 --> 23:52.720 by the app before so you want you want to interface instead. You would ideally use a civil bus 23:53.440 --> 24:03.760 connection or a civil connection and this protocol buff encapsulation and just send a message through the node. 24:04.080 --> 24:12.320 Okay I forgot one thing. If you want to send your own messages through the node please don't 24:12.320 --> 24:19.360 try to modify the firmware. Most of the radios have a very tight flash space and the firmware 24:19.360 --> 24:25.200 takes up almost all of it. There is a module API in the firmware and theoretically you could use 24:25.840 --> 24:31.760 right a new module for the firmware but it's really easier to use the API to connect to the running 24:31.760 --> 24:39.200 firmware either via serial or if it's an ESP via TCP port and use the protocol buffer interface 24:39.200 --> 24:45.840 to tell the node to send your message. And if you want to encapsulate your own protocol you can ask us 24:45.840 --> 24:51.840 for a port number and then you can put your own protocol data in the payload and you want to 24:51.840 --> 24:58.480 stir the rest of the network. So if you want to turn something through there or if you remember the data 24:58.480 --> 25:03.040 array you can achieve or just remember there are other people also on there that you want 25:03.040 --> 25:13.520 throttle and then you can talk to us about protocol number. Okay I said we have a module configuration 25:14.320 --> 25:20.400 these are the modules that are baked into the firmware just a very quick overview. I upload the slides 25:20.400 --> 25:27.280 after the presentation I was told to do it before but our booth was so small that I didn't 25:28.080 --> 25:33.440 manage in time I'm sorry for that but as soon as possible you'll get the slides. 25:34.800 --> 25:42.080 Okay let's skip over that a bit because one one important thing is telemetry because what can we 25:42.080 --> 25:48.640 send text messages, location data and sensor data. These are the sensors that are supported by the firmware 25:48.640 --> 25:53.680 natively you can just hook them up to the iSquetry interface they will be auto discovered 25:54.080 --> 26:02.320 and configured and as soon as you switch on the matching telemetry module in your configuration 26:02.320 --> 26:07.200 the data is transmitted out on the network and you can ingest it put it on a graphana dashboard 26:07.200 --> 26:18.240 or whatever you want to do with it. Like this these are different dashboards and if you look closely 26:18.320 --> 26:25.360 there are only three dashboards because the fourth one is actually mesh sensor. mesh sensor is a topology 26:25.360 --> 26:32.000 maper you can connect one node to the mesh sensor application it's also free and open source and 26:32.000 --> 26:40.160 this will map out your network like this this is the one of the partial node maps there's no official 26:40.160 --> 26:47.040 node map but some some people are running maps and if you're mapping it out the mesh sensor 26:47.120 --> 26:53.520 application one warning it uses trace routes and trace routes are a bit like 26:55.200 --> 27:02.080 also heavy on your network. In newer versions are toned down a bit so it is usable but we 27:02.080 --> 27:05.840 remember to not leave it running all of the time but use it for mapping the network 27:06.960 --> 27:13.760 optimizing the network and then please switch it off again okay Laura 27:13.840 --> 27:22.320 maybe you're wondering what our logo comes from they you see it this is the lower modulation 27:22.320 --> 27:32.480 on a time on a time frame so Laura is just jumping modulation the point where the trip 27:32.480 --> 27:41.920 here starts and ends this defines what information we transmit not if it's up going up or down 27:42.000 --> 27:48.160 not the the sloping but the point where it starts and where it ends and every one of these 27:48.160 --> 27:58.000 sweeps here can codify 16 values so it's nibble the thing that starts with 16 sunk frames or the 27:58.000 --> 28:04.800 preamble the 16 zeros for mesh testing the normal Laura one uses eight symbols we use 16 28:05.440 --> 28:11.280 to give the MCU time to wake up if it's sleeping then there is a sync word use a custom sync word 28:12.240 --> 28:17.120 if a sync word doesn't match we don't decode it and then the data parts starts with error 28:20.640 --> 28:33.200 and I hope this is working this is what it looks like on an SDR no it's not working 28:33.600 --> 28:39.200 yeah I know it's working and we can't even hear each 28:43.200 --> 28:47.600 these are the upsurge and downsurge and the upsurge spectrum that Lauren 28:47.600 --> 29:08.320 not really okay thank you so you see the actual modulation this was very long slow but 29:08.320 --> 29:14.720 you can hear it and it's really slow depending on preset it takes several seconds to send out of 29:15.040 --> 29:26.240 package okay we've been invited on a ticket from the IRU so I'm going to talk briefly about 29:26.240 --> 29:34.320 hem mode because as you saw in front at least one frequency range in the US two frequency ranges 29:34.320 --> 29:41.280 are also hem radial ranges so you can put the firmware into a special hem mode you can enter the 29:41.280 --> 29:47.920 call sign and say I'm licensed the pro is you're allowed to transmit with up to 10 watts 29:48.960 --> 29:54.080 and you can use higher gain antennas you're not bound to the limits of the ISM bed and 29:54.960 --> 30:02.880 the drawbacks as soon as you do that we'll switch off any encryption I know this is a hotspot for 30:02.880 --> 30:09.680 debate but to cater for every national interpretation of the no encryption rule we decided we're 30:09.680 --> 30:17.200 going to switch off encryption also direct messages because they are encrypted and the node will 30:17.200 --> 30:23.360 not forward packages that are encrypted anymore so you're not accidentally routing traffic for 30:23.360 --> 30:32.480 people that are not licensed this is the drawback of course you're not bound to the limits of the 30:32.480 --> 30:39.520 node anymore you can use the entire 430 megahertz band actually in the no configuration you put 30:39.520 --> 30:47.280 you can put in any of the frequencies you want to use also outside the presets it will just 30:47.280 --> 30:58.480 use the preset but you can shift the frequency wherever you want and you're called sign will be transmitted 30:58.480 --> 31:06.880 as required every 10 minutes with the node info package at the right of the slide you see how to enable 31:06.880 --> 31:15.200 that an example is the Android software you say I'm licensed this is my call sign and then you switch 31:15.200 --> 31:32.640 into hand mode somehow it's not going to the next slide oh there it is okay 31:33.040 --> 31:50.080 these are a few pictures of node installations especially of repeaters or routers people are using 31:50.080 --> 31:55.120 radio towers either hammer radio towers or commercial radio towers of course only with with permission 31:56.320 --> 32:00.960 that that's one thing every time you set up a note out and why please ask the property on 32:01.120 --> 32:06.320 the mission even with public land just don't put nodes anywhere you've had an incident about 32:06.320 --> 32:11.760 the one or two years back I don't remember in solid lexity or in the area of solid lexity 32:11.760 --> 32:19.600 where notes were discovered on some public land big note installations with solar panels 32:19.600 --> 32:26.480 luckily they turned out to be helium nodes and helium hotspots and not majestic but I don't want 32:26.480 --> 32:39.840 to explain to the authorities what this is and if it can blow up okay I've kept my time any questions 32:40.160 --> 32:48.000 I can expect a lot sure 32:54.880 --> 32:59.200 sorry I don't know that I know there's been reverse engineering of the protocol you can 33:01.360 --> 33:07.440 I'm sorry yeah the question was if I know better the patterns run out I don't know that 33:10.000 --> 33:17.200 all I know is there is a G&U radio module that can decode Laura and also decode 33:17.200 --> 33:23.200 majestic packets so you can use that you can also transmit them but it's not as good as the 33:23.200 --> 33:30.640 radios itself by cemetery because they of course the HF matching is a bit different than to 33:30.720 --> 33:38.240 NSDR as the R is always inferior to the real radio harbour chip yes 33:43.040 --> 33:48.960 yes the difference between majestic and other Laura or Laura Wang installations like helium 33:49.760 --> 33:56.560 most other networks use Laura Van which is a rapper above the Laura network or a layer above the 33:56.560 --> 34:03.040 Laura network Laura Van defines frequency slots and has a hub in spoke architecture so you have 34:03.040 --> 34:08.240 concentrators or excess points and you have your sensors that are transmitting data to the 34:08.240 --> 34:13.920 excess points so we don't use Laura Van and helium is an implementation of Laura when the things 34:13.920 --> 34:20.080 network is another one we use the Laura physical transport layer and put our own peer to peer network 34:20.080 --> 34:25.600 on top of it okay still please 34:51.040 --> 34:55.040 I didn't catch the device in your question I'm sorry 35:05.040 --> 35:10.240 I'm really not sure I remember this one maybe we can talk after the talk 35:11.360 --> 35:13.360 bilateral about this yes 35:13.600 --> 35:19.760 does the network make an distinction with the station area more about the question is if there's 35:19.760 --> 35:24.880 any distinction between station area and mobile devices no the routing algorithm of the network 35:24.880 --> 35:30.240 if you can call it that because it's flat routing with a bit of intelligence behind it it assumes 35:30.240 --> 35:37.360 mobile nodes so we are not trying to build some up some routing tables or something like that 35:37.360 --> 35:44.960 because apart from the fact that we assume mobile nodes we don't have the bandwidth to exchange 35:44.960 --> 35:53.600 these routing tables we tried we have a very good simulator to simulate the traffic but it's 35:53.600 --> 35:59.680 it's really not feasible we've had one approach over the last few weeks we really implemented 36:00.560 --> 36:10.240 it with a bloom filter to distribute neighborhood tables but in the end it would be no advantage 36:10.240 --> 36:18.400 or disadvantage would be the same performance so we assume mobile nodes yes 36:20.400 --> 36:26.080 then do as an example yeah if you actually solve the problem of for collision detection 36:26.640 --> 36:31.840 the reason I ask you is that as far as I know these are the most of these more objects have 36:31.840 --> 36:38.000 the problem that they cannot really detect the signal is free well 36:38.800 --> 36:44.720 yes the question was about collision detection the older same tech chips are not very good at 36:44.720 --> 36:49.680 detecting collisions because they can only decide if there's another error or signal on the frequency 36:49.680 --> 36:54.400 the newer chips are better in that case and we don't have any software provisions we just 36:54.400 --> 37:04.960 will I on the collision detection by the chip yes oh I'm sorry I meant the person behind you 37:06.320 --> 37:14.080 okay I was curious where is the best place to ask questions about setting up hardware 37:14.080 --> 37:19.440 like a group chat or a forum or something like that like if you have a really good advice for example 37:20.400 --> 37:25.920 yes the question is about a contact point or we have best to ask questions most of the developers 37:25.920 --> 37:31.680 are on the discord channel or on discord server for mistastic so on homepage I have different 37:31.680 --> 37:38.720 links for social media groups or officially one official ones and I think you can use all 37:38.720 --> 37:43.280 that discord is the real time channel where you can meet the developers in very also coordinate 37:44.240 --> 37:59.200 yeah the question is about scalability yes it scales the default setting does not scale very well 37:59.200 --> 38:05.360 it's meant for range so if you flesh device powered up first time you're going to discover 38:05.360 --> 38:12.800 few nodes that are a bit farther off so as soon as a community develops beyond 30 nodes I think 38:12.800 --> 38:21.360 40 nodes you're going to switch to a quicker setup to faster setup so yes it scales to give you a 38:21.360 --> 38:27.520 number how it scales we put a special firmware on devcon that was locked to the faster setting we 38:27.520 --> 38:37.440 have available and we had 800 nodes on the network without any problem so it scales yes 38:45.840 --> 38:51.280 yeah the question is about measurement when you can detect how channel gets degraded we have 38:51.280 --> 38:56.720 some metrics about this we have the channel utilization and also if some of these thresholds are 38:56.720 --> 39:03.760 exceeded the node will dynamically scale down its broadcasts or the intervals of the management data yes 39:13.040 --> 39:18.880 order of devices yeah devices that square kilometer sorry no idea 39:27.600 --> 39:32.400 the feature where it will basically automatically determine the number of properties you set 39:32.400 --> 39:37.120 in order and the speed of which you need to translate order to code with dynamic order yes 39:37.920 --> 39:45.520 the question was about dynamic adaptation of roles and stuff yes we are thinking about this some 39:45.520 --> 39:50.800 of this is already in the firmware other things are already sketched out and this is going to be 39:50.800 --> 39:56.240 in the next development I'm going to take this this side of the room a bit I've connected them please 39:57.280 --> 40:09.520 and this is a lot of nice here today it's probably going to be less more about recommendation 40:09.520 --> 40:17.760 of this setup we have right here I'm surprised it's working that well on long slow you can see 40:17.760 --> 40:23.440 a lot of the optimizations we did over the last few weeks that it's running at all with default settings 40:23.440 --> 40:30.640 for something like this here first them with a bit more nodes I would recommend medium fast setting 40:32.400 --> 40:39.680 we deliberately wanted to test the default setting today okay there was another question 40:40.000 --> 40:45.040 should some be considered is the at no E to E C C security of the choice 40:47.280 --> 40:51.360 um the question about the encryption tips we are considering 40:52.560 --> 40:59.120 no it is not because we're using the Ede 25519 curve and there's not a lot of chips on the market 40:59.120 --> 41:03.120 that support this curve at the moment we are evaluating one in the next picture 41:03.760 --> 41:07.760 yes 41:17.760 --> 41:23.360 the question is about different transmission settings if you want to talk to each other you have to use the same 41:23.360 --> 41:30.160 settings yes the thing about the especially the spreading factor is the spreading factors laid out in a way 41:30.240 --> 41:34.720 that you can have more than one single on the same frequency that one interference with each other 41:34.720 --> 41:39.600 so you can have up to 66 or 7 signals on the same frequency that won't see each other 41:44.240 --> 41:46.320 any more questions in front here 41:46.320 --> 41:50.640 yeah I'll just ask for the what the overhead of having encryption on the 41:56.080 --> 42:01.120 the question is about the overhead of the encryption the encryption itself does not increase the packet 42:01.120 --> 42:09.200 but for the direct messages we added a signature to prevent certain replay attacks so this is increasing 42:09.280 --> 42:16.560 the payload by I think 8 or 16 bytes so this is this is the trade-off for increased security 42:16.560 --> 42:22.160 the thing is you can remote admin these nodes and this is also running over direct message 42:22.960 --> 42:26.960 the direct message message exchange was would not would not be that critical but the remote 42:26.960 --> 42:33.200 administration is because you can take over notice that so we added this additional layer yes 42:40.080 --> 42:48.400 question about the duty cycle yes this is per device transmitting yes and now this is 42:48.400 --> 42:55.760 doing a flat it's a mesh and it's doing cloud broadcast so for one single message can spawn 42:55.760 --> 43:02.240 a lot of other messages to reduce somehow the the utilization of the band because it's a share medium 43:02.240 --> 43:09.280 yes if you if you if you the questions about the bandwidth management with the duty 43:09.280 --> 43:18.400 cycle in in at the moment it gets too much I think the 25 and 35 percent are thresholds 43:18.400 --> 43:26.240 we prolong the interval something is sent out or suppressed packets for instance telemetry 43:26.240 --> 43:37.600 packets temperature unless the roll is sensor because then it won't do that but I think if the mesh 43:37.600 --> 43:43.920 is congested it will suppress packets up to three times and after three times it will transmit it anyway 43:43.920 --> 43:51.920 so temperature doesn't change that rapidly you can still use the device thank you yes 43:52.240 --> 43:58.560 a question of signature actually can I have one friendly mesh and one eventually separated mesh 43:58.560 --> 44:05.600 that is trying to be attached to the permission question about separation yes I said we have 44:05.600 --> 44:10.720 eight slots for encryption keys so the encryption keys basically your mesh so you can have the 44:10.720 --> 44:17.280 user groups that have different encryption keys many people are putting their private mesh or their 44:18.240 --> 44:24.720 first slot and then default in the second slot so they will still receive default messages 44:24.720 --> 44:33.280 but can communicate on their own private encryption keys don't know more questions I think it's time for 44:33.360 --> 44:41.360 you 44:44.160 --> 44:50.320 thank you very much