WEBVTT 00:00.000 --> 00:16.700 Okay, welcome everyone, so yeah, M17 and OpenRTX, one year later, basically it's follow-up 00:16.700 --> 00:26.220 of the talks we gave, I gave one on OpenRTX last year and Morgan gave one on M17 last 00:26.220 --> 00:31.940 year, so yeah, this is what happened one year later. 00:31.940 --> 00:44.460 With introduction, I'm a radio operator from Italy, Milan, I leave being a firmware developer 00:44.460 --> 00:52.620 by profession, I manage to turn this a passion into a profession, but I still keep the 00:52.620 --> 01:01.260 passion and yeah, and I am co-founder and developer of the OpenRTX project, which began 01:01.260 --> 01:12.180 in 2020 during COVID, because yeah, we were basically at home doing nothing and we wanted 01:12.180 --> 01:22.220 to do stuff, so we started working on this project and yeah since 2021, I'm also one 01:22.220 --> 01:32.300 of the, I would say, core members of the M17 team, which we will see in a brief moment 01:32.300 --> 01:42.060 what does, so brief recap of what M17 is, I want to go into the details of this project 01:42.060 --> 01:49.860 because we had a talk last year, which covers all the details, basically M17 is first 01:49.860 --> 01:58.740 of all the community of OpenRTX developers and radio enthusiasts, which gathered during 01:58.740 --> 02:07.180 years around the main idea of a Polish-Harm radio operator, Vocic, Sierra Pava 5, with 02:07.180 --> 02:16.660 Kiewiski Pava, which at some point decided to develop and devise and openRTX protocol 02:16.740 --> 02:24.580 for Harm Radio, a completely open source protocol, open source specification, voice code 02:24.580 --> 02:33.900 and so on, so yeah, first of all M17 is this community revolving around this idea of open 02:33.900 --> 02:44.980 Harm Radio stuff and main goals are promoting this protocol and working on specification, 02:45.060 --> 02:52.020 working on all the details of this protocol, but also developing open source firmware and software 02:52.020 --> 03:00.740 to deal with, yeah, and Harm Radio stuff, but also developing open source hardware and I will 03:00.740 --> 03:10.980 show you an example of this hardware and in parallel we have OpenRTX, which is more about 03:11.060 --> 03:19.380 developing a firmware for Harm Radio devices, also supporting M17, but in principle not 03:19.380 --> 03:27.780 only supporting M17 is, I would say is a parallel counterpart of M17, M17 is a protocol, 03:27.780 --> 03:36.820 this is a firmware which implements M17, but the ideas are shared, objectives not completely 03:36.820 --> 03:46.980 coinciding, this firmware has been devised from scratch in order to be modular, which means 03:46.980 --> 03:54.900 that you can easily add protocols or features to this firmware, easily portable to new devices 03:54.900 --> 04:02.420 because in our experience with the previous project, we saw that that project was so tightly 04:02.420 --> 04:10.500 coupled with the hardware that it made basically impossible to port it to new devices, the beginning 04:10.500 --> 04:17.140 of this project was an attempt of porting OpenGD77 to a specific radio and then we realized, 04:17.140 --> 04:22.980 okay, this firmware is too tightly coupled with the hardware that we need to basically 04:23.140 --> 04:30.900 redesign everything from scratch and this is how we got here and yes, it is easily 04:30.900 --> 04:43.060 extendable to new protocols, going to hardware, this is what happened during the last year, 04:44.020 --> 04:55.860 finally, this is the one point zero revision of basically a modern device which allows you to convert 04:55.860 --> 05:05.140 any radio you have to an M17 radio, hardware completely open source, you have the files, 05:05.780 --> 05:11.620 you can manufacture it, just send a galber files to any PCB manufacturer, 05:12.500 --> 05:20.980 so completely open hardware and yes, it runs OpenRTX, so it's open from hardware to software 05:21.620 --> 05:28.500 and yeah, it has been released at 29th of June, 2024 during Humradio for this often, 05:29.380 --> 05:36.580 we decided to take this occasion of releasing this finally, this hardware after like at least 05:36.580 --> 05:43.060 couple of years of iterations during, we decided to take the occasion of Humradio for this often, 05:43.620 --> 05:50.980 also has a symbolic way to say, okay, now it's finally we have something we can show, we can 05:51.540 --> 06:00.580 distribute, with respect to the previous versions you can find around, we have some at our 06:00.580 --> 06:08.580 booth downstairs, the board has been completely redesigned because yeah, first of all we wanted 06:08.580 --> 06:17.860 to fit it into an aluminum case because before this we had only bare PCB boards which are a 06:17.940 --> 06:24.100 mess to deal with, you would be sending out with short circuits, you don't know how to put, 06:24.100 --> 06:31.300 where to put them so on support, so we redesigned completely board to fit it into an aluminum case, 06:32.420 --> 06:38.580 and it has a new user interface board because the previous one had physical buttons 06:39.700 --> 06:46.100 and this one has touch buttons, yeah, it has been organized to be a little more user friendly, 06:48.180 --> 06:54.900 yeah, we have a fix on the audio amplifier because we have a design issue with it, 06:55.860 --> 07:08.740 basically it didn't work very well, it could volume was very low, and we had this connector here 07:08.740 --> 07:12.740 which looks like an Ethernet connector but it's not an Ethernet connector, 07:13.220 --> 07:22.420 basically it's an interface named open headset interconnect standard, it's a specification 07:22.420 --> 07:33.620 devised by an American ham radio operator with the aim of providing a standard interface 07:33.620 --> 07:41.700 connector for all the ham radio devices allowing you to plug whatever microphone and speaker 07:41.700 --> 07:52.260 devised you have to any ham radio device, so it's not very popular but we decided to include 07:52.260 --> 08:02.740 this connector, yeah, has a way to promote this standard which hopefully will make the life 08:02.740 --> 08:08.260 a little better because now each radio has its own standard and its own format of the connector 08:08.260 --> 08:14.180 for the mixed speaker and you end up having like 40,000 mixed speakers each one for each radio 08:14.180 --> 08:20.500 and you get crazy, so yeah, we decided to include this connector which is not present in the previous 08:20.500 --> 08:27.940 revision boards and yeah, we changed the license of the hardware which now is licensed 08:27.940 --> 08:34.820 under certain open hardware license and also yeah, we have the open source, the open source 08:34.820 --> 08:43.220 hardware certification we have, yeah, the mark for, now it's really certified as open 08:43.220 --> 08:51.540 under and for those interested will it be available in the market probably yes, 08:52.340 --> 08:57.700 there is Lily Go, the famous Chinese manufacturer and distributor of 08:58.180 --> 09:09.860 hardware which seems to be interested in manufacturing this device but I cannot say anything specific 09:09.860 --> 09:18.100 because it's something going on in the background and I don't have really fresh news about this 09:18.740 --> 09:29.460 going on still about hardware we have finally the very first commercial device having an open source 09:29.460 --> 09:37.620 film on it it is a cooperation from connect systems and open at the axe it took I would say 09:37.620 --> 09:46.580 one year to get here we started we all started with an email from the CEO of connect systems 09:46.660 --> 09:55.060 which is on the American United States based California distributor of the radio devices 09:55.860 --> 10:07.140 which is interested in supporting the M17 protocol and all started one one year ago with an email 10:07.220 --> 10:15.780 from Jerry saying I'm interested in M17 I want to do something would you help me so 10:17.380 --> 10:26.420 finally one year later we have the first radio it's first version of firmware has been released 10:26.420 --> 10:34.420 and July 2024 alongside we hardware we took an already existing hardware and we applied some 10:34.420 --> 10:41.060 hardware modifications to make it M17 compatible and yeah now is available on the market 10:42.900 --> 10:48.420 is UHF only unfortunately is not a dual-band device it's a single-band UHF only 10:49.620 --> 10:59.860 there is no VHF version that I'm aware of so quite a validation but we can live with it it goes 10:59.860 --> 11:09.940 way over the ham radio band plan because originally the hardware is for CVUs so for example security 11:09.940 --> 11:18.340 people and stuff so it has a very wide bandwidth but yeah at least it covers also the ham radio so 11:18.340 --> 11:29.060 it's okay and what's inside an STM32F for microcontroller which is the same you you can find the 11:30.020 --> 11:36.500 in the in the module 17 and in the other radios supported by OpenRTX so that was easy 11:37.860 --> 11:48.740 these dumb HR C6000 which is a basically a DSP designed to do the DMR protocol 11:50.580 --> 11:58.660 I would say almost completely obscure you then you don't have a lot of documentation about this 11:58.980 --> 12:07.060 chips or to develop the firmware I had to reverse engineer the original firmware to extract the 12:07.060 --> 12:16.980 informations I needed to make this chip run but yeah I mean it's not ideal but we have it working so 12:16.980 --> 12:24.900 no worries and the radio frequency stage is discrete which means it has a VFO PLL and so on 12:24.900 --> 12:33.300 supported it is not based on radio on a chip like others device like other devices it still has 12:33.300 --> 12:42.500 support for DMR for those interested in doing DMR however it comes through the original 12:43.140 --> 12:51.220 manufacturer firmware which is closed source so technically a dual firmware device you use OpenRTX 12:51.220 --> 12:57.940 if you want to go FM and MS-17 and possibly in the future other protocols because now hardware is 12:57.940 --> 13:06.260 there it's just a matter of firmware and if you want DMR or FM but in another way you have to load the 13:06.340 --> 13:18.340 oven firmware and yeah and also it has a so-called CS-717 plus version which has been released around 13:18.340 --> 13:31.460 in like November 2024 which which has a very BCCPU it has DM32 H7 which basically doubles the 13:31.540 --> 13:39.380 capabilities of the other microcontroller. This plus version is available on the market but 13:40.420 --> 13:49.540 yeah it's the OpenRTX side still has some problems and I'm working on those but I see some potential 13:49.540 --> 14:00.980 because I mean it has a very powerful microcontroller I think you can almost run Linux on this microcontroller 14:01.060 --> 14:10.900 so really you have a lot of perspectives and yeah this speaking of hardware more or less is 14:11.460 --> 14:18.580 what happened in this past year is this module 17 and this other other things are going on but 14:19.300 --> 14:29.220 yeah not not not production radio I would say speaking of software what we have 14:29.780 --> 14:40.260 we have a 17 packet mode which I think is something not really known because so far I'm 17 14:40.260 --> 14:47.940 protocol concentrated mainly on voice but it also has a packet mode and nobody knows about the 14:47.940 --> 14:59.380 packet mode and but yeah speaking of it it transmits data in chunks of 25 bytes and it allows 14:59.380 --> 15:11.300 to send over the air up to 825 bytes basically it divides this big payload into chunks of 25 bytes 15:11.300 --> 15:19.460 each and it sends them over here but yeah you can start doing interesting things with this 15:20.660 --> 15:31.220 and maximum data rate is 4.5 kilobit per second not that fast but still you have it it goes over 15:31.220 --> 15:40.660 VHF and UHF you can go very far with this and yeah so how can we use this packet mode for a lot of things 15:41.300 --> 15:49.940 for example we can control and command the beaters yeah you are chef link you can just send 15:49.940 --> 15:58.180 commands and data and you have telemetry for example over standard radio frequency carriers so 15:58.180 --> 16:06.420 you don't you don't really need internet access up to the repeaters side we can use it for 16:06.420 --> 16:16.420 messaging services in these days voice check fell in law with SMS over at 17 is done is doing 16:16.420 --> 16:26.100 like a lot of work around sending SMS over at 17 so yeah you can use it to send SMS but 16:27.060 --> 16:34.340 also hopefully something more interesting and useful than just text it texting with your friends 16:34.420 --> 16:42.020 over at 17 and finally wireless access on networks but these are just free examples so 16:43.060 --> 16:50.580 for the meme we would say that so far nobody expects the M17 packet mode and now we have it so yeah 16:52.500 --> 16:59.700 going to coming to an interesting use of M17 packet mode we have M17 net net net 17:00.180 --> 17:08.820 which has a demon developed by Morgan which allows you to create TV for links over 17:08.820 --> 17:19.140 17 packet so you can message for example to you something over 17 why because these comes from 17:20.100 --> 17:30.260 a real use case scenario that is transmission of data in like industrial environment with 17:31.380 --> 17:38.500 with those nodes right here there's mission nodes very far away one to each other so 17:38.500 --> 17:45.300 either you run kilometers of cable or you go another way and but yeah why not using TV4 17:46.260 --> 17:53.540 I mean you have an infrastructure over these and yeah written by Morgan it's based on the 17:53.540 --> 18:00.900 Linux 2 top driver and not on does not rely on a random driver in the Linux kernel written by 18:00.900 --> 18:07.380 a hand radio operator 40 years ago not maintain it anymore which breaks down because I just change 18:07.380 --> 18:14.260 the Linux version so it's really 2 top device you open you have a network device and you send it 18:14.340 --> 18:22.660 over the network device and you're done downsides so far it works on the on PC with a 18:22.660 --> 18:31.780 next year because this was the development environment but soon TM will come with a TX link 18:32.500 --> 18:40.420 which will give you the possibility of using your real real magic device to transmit data 18:41.380 --> 18:50.500 over TV4 and something like that and yeah if you want to play with it you have code available 18:50.500 --> 18:59.860 on GitHub and you can take it and use it more the well more stuff to come and yeah 19:00.660 --> 19:07.940 thank you my my part of presentation just finished I just want to give you a brief update and now 19:07.940 --> 19:14.020 I leave the stage to mark which will talk you about what happened yesterday basically 19:14.020 --> 19:33.140 oh the call this in automotive sports box in stock 19:33.140 --> 19:46.260 good stop good stop yes right software for race cars that's why I make this 19:50.260 --> 19:57.060 okay I think you can hear this welcome my name is Mark I'm also a hand radio operator 19:57.060 --> 20:09.620 HP-SP I'm a long time open source developer and I'm also since short time the open source project 20:09.620 --> 20:19.300 coordinator for year-to-region one so I'm also the author of software to control 20:19.540 --> 20:27.860 transceivers TRX control and as I met Sylvano on several occasions I thought well I should be 20:27.860 --> 20:38.820 able to also control with TRX control open RTX radios and it has a protocol called RTX link 20:39.620 --> 20:47.940 which is the cat interface to open RTX radios and it is fairly well documented it doesn't do as 20:47.940 --> 20:55.460 much as a year is a radio does but then I mean this is a working progress and project on the 20:55.460 --> 21:02.100 development but nevertheless I took this documentation and implemented it and I should theoretically 21:02.100 --> 21:09.300 be able to read out the frequency set the frequency set the operating mode and but for some reason 21:09.860 --> 21:16.820 I just was not able to set the frequency and I double check with the documentation and my implementation 21:16.820 --> 21:24.660 and yes it was done correctly so what the hell was going on and then unfortunately I made the 21:24.660 --> 21:32.100 mistake to start looking at the source code of RTX link and open RTX and the well there was 21:32.100 --> 21:42.500 this comment to be implemented and then I knew why I was in the last hours not able to set the 21:42.580 --> 21:50.180 frequency on the radio so but what do you do when you're a developer and you find such a comment 21:50.740 --> 22:00.180 it was like a command not a comment so I fired up the editor and I started implementing this stuff 22:01.300 --> 22:10.020 and then I found other commands that were not implemented and so I asked some time I got it working 22:10.500 --> 22:18.500 and this kind of dragged me into this project and I hacked this RTX link protocol 22:20.340 --> 22:27.220 after Sylvanas showed me how I can build the firmware and load it onto the radio so that's how it 22:27.220 --> 22:36.260 came that I became part of this journey and because there were so many open questions and we met 22:36.420 --> 22:42.340 the meat here at first them anyways I asked Sylvanas what do you think about the idea of doing an 22:42.340 --> 22:48.740 open RTX hackathon on Friday before first them so that we meet somewhere and he said oh yeah good 22:48.740 --> 22:58.500 idea so I looked for a space and actually the Brussels Hockey Space offered us generously to 22:58.580 --> 23:08.740 to be there guests and so yesterday we met at the Hockey Space in Brussels which is a very nice 23:08.740 --> 23:16.980 community I must say and they have great rooms and great possibilities to hardware hacking and 23:16.980 --> 23:25.220 they have even have CNC machines and whatnot and then they're met some developers from Italy Switzerland 23:25.300 --> 23:30.260 Germany Belgium France to spend a day on 23:40.740 --> 23:49.460 this is a strange user interface so first thing sort out the topics what do we want to discuss 23:49.540 --> 23:58.260 what do we address next because we had quite a few issues that were open and so 23:58.260 --> 24:06.980 we first made a list that's the table of contents of my talk basically we first did a 24:06.980 --> 24:15.140 little brainstorming session we had this RTX link branch with diverged quite a bit from the 24:15.140 --> 24:23.220 master branch partly this is my fault because I continued to work on the protocol and at one 24:23.220 --> 24:28.580 time we should merge this into the main line of the firmware in the master branch so this was an 24:28.580 --> 24:36.500 issue that we had to discuss because it has diverged for more than one year so the master branch was 24:36.500 --> 24:43.860 something completely different so this was probably already m18 and RTX link was still 24:44.820 --> 24:53.140 yes you get the idea then we discussed a new cut interface computer edit 24:53.140 --> 25:00.420 conceiving along with RTX link I will come to that in a minute the status of some particular 25:00.420 --> 25:09.620 radios was an issue you probably heard of this UV380 radios which have a 5 watt 25:09.620 --> 25:17.620 transmitter there is a waterproof addition here he shows you one there's a waterproof addition 25:17.620 --> 25:28.020 the UV390 and then there is a third addition the UV390 in 10 watt now that's nice but 25:30.740 --> 25:41.220 this slightly different we'll come to that later and another topic was how to use m17 for data transfer 25:41.220 --> 25:48.660 and not only voice coding we heard about the project where it is done in a very particular way 25:48.660 --> 25:55.380 but it would not work with any open RTX radio so we wanted to discuss how can we use any 25:55.620 --> 26:06.740 art open RTX radio to for data transfer then very wild idea maybe not so wild if you know me 26:06.740 --> 26:16.580 better is making open RTX scriptable with a scripting language and one very very important topic 26:16.580 --> 26:24.420 in my opinion until now in open RTX you can set the frequency and a mode if you want to use 26:24.420 --> 26:30.580 another frequency you can change the frequency but what you cannot do is you cannot store a frequency 26:31.220 --> 26:40.020 and then make channels or whatever so in DMR speak that would be code blocks with the zones 26:40.020 --> 26:47.220 and the top groups and whatnot or in other commercial radios we have a memory system with channels 26:47.220 --> 26:57.060 channel groups and so on so we need something similar for open RTX so this is also the point 26:57.060 --> 27:07.460 that took the most time of the day actually but let's start with RTX link RTX link is nice 27:07.460 --> 27:16.980 because it makes sure that the data is not corrupted it uses CRC codes it uses a 27:16.980 --> 27:28.500 slip framing for serial lines and this is a bit it's not complicated to implement but if you 27:28.500 --> 27:35.620 look at cat interfaces of other radios they're just very simple asky based protocol so you can send 27:35.700 --> 27:47.140 a string and it does whatever you need but let's first the thing about merging it or what we do 27:47.140 --> 27:54.980 we for the moment we will not merge it so sorry if you're using the master branch but Mark will 27:54.980 --> 28:03.220 rebase it so that the branches are not diverging so much they're just diverged by the RTX link 28:03.220 --> 28:13.460 parts so we we're going to rebase it and now I come back to this RTX link issue so we have 28:14.500 --> 28:23.860 CRC we have the slip framing and what we cannot do when you have the the USB serial device 28:23.860 --> 28:31.140 in your let's say Linux computer and you want to talk to the RTX Open RTX Radio you have to 28:31.300 --> 28:39.700 have a client who does all this slip framing and who does the CRC calculations you can not do 28:39.700 --> 28:47.380 like echo frequency blah blah blah and redirect this to the serial port what you can do with the 28:47.700 --> 28:58.180 radio or a can wood radio so it really is a protocol that needs software on both ends and so we 28:58.180 --> 29:09.620 had the idea to add a new cat interface and as a complement I have a lot of typos I see as a 29:09.620 --> 29:20.020 complement to RTX link so RTX link ensures data and credit integrity it's a bit complex 29:20.020 --> 29:28.100 for simple cat operations so the new cat interface will be simply text oriented like done in 29:28.100 --> 29:35.780 yes or can wood radios but it will have a command to switch to RTX link mode so when you have 29:35.780 --> 29:43.220 to flash the firmware for example then you want to be sure that the data you send comes into the 29:43.220 --> 29:51.460 radio as is so we switch to RTX link and then we have a transfer channel which allows us to 29:53.140 --> 30:01.860 transfer data in a secured way I will also discuss that when it is possible when the radio for 30:01.860 --> 30:08.580 example is connected to the computer using USB that we use multiple endpoints so that there could be 30:09.460 --> 30:18.340 endpoint for the cat interface and the separate endpoint that talks directly RTX link protocol 30:18.580 --> 30:34.420 okay that was the ideas for computer to radio operations now the situation of these these radios here 30:37.460 --> 30:46.820 I don't know what these engineers defeat they smoked but they just changed to GPIO pins 30:47.780 --> 30:57.060 that's the only difference power amplifier and backlight GPIO they are reversed yeah so on the 30:57.060 --> 31:04.660 UV 390 10 watt if you want to transmit you have to turn on the backlight and if you want to see 31:04.660 --> 31:14.420 something on the display you have to press the PTT button which completely makes no sense in a way 31:14.980 --> 31:26.100 but then there is no way to detect the model you have in software we decide we first so we could 31:26.100 --> 31:38.420 display a message at boot up 3 press the PTT button and those who do not see the message do not press 31:38.420 --> 31:47.300 the PTT button so when after one second PTT is not pressed we know we are on this 390 okay 31:48.740 --> 31:54.980 we decided on a more pragmatic way we're going to provide two for very images one for the 390 31:54.980 --> 32:05.540 plus or 10 watt version and one for the 5 watt version assuming does that the person owning the device 32:05.540 --> 32:21.380 knows what device he or she has um the MD96 title is also the MR mobile radio and it's very 32:21.380 --> 32:29.700 unspectacular what we have to say here we need to collect more more information these radios they 32:30.340 --> 32:37.460 have a ton of hardware revisions and they're probably different and none of them works so 32:38.340 --> 32:45.620 we're now looking at the radios we have a chance to see what revisions there are we collect data 32:45.620 --> 32:48.580 and other than that there's no news on this front 32:49.380 --> 33:07.700 M17 for data transfer is somehow logical because M17 already is a digital transmission mode 33:08.660 --> 33:17.220 and the idea we developed then what morning report does require special hardware 33:19.060 --> 33:27.140 correct me if I'm wrong yes for now it requires special hardware so the idea is to bring 33:27.780 --> 33:37.060 this net B and RTX link together so look at net D why it doesn't use RTX link probably 33:37.060 --> 33:44.980 because RTX link is just not suited for the use case so we will have to extend the RTX link protocol 33:44.980 --> 33:55.540 for data transfer and then all this stuff with the term and top device and IPv4 and of course in the 33:55.620 --> 34:06.420 future IPv6 is done in the net D part which uses then RTX link to talk to the radio and the radio 34:06.420 --> 34:17.860 does all the stuff that needs to be done on the M17 site so in the future we hope that M17 net D 34:18.580 --> 34:27.300 team and the demon can talk the RTX link protocol and use any M17 capable radio to transfer data 34:29.700 --> 34:36.660 we have to keep in mind that this will be slow this is not 10 gig Ethernet link 34:37.540 --> 34:47.940 this is probably 2500 bit per second something like more in size it's a bit more okay 34:48.900 --> 35:03.780 will be 3000 bit per second okay now he said it doesn't make sense to implement the RTX link protocol 35:03.780 --> 35:12.340 in each client that wants to use it so we have plans to provide an open source library under 35:12.340 --> 35:21.780 the MIT license for POSIX systems that implements the client side of RTX link so that they can be used 35:21.780 --> 35:27.620 by any software that wants to make use of an open RKX system 35:27.620 --> 35:45.620 the next thing is to add a scripting engine to open RKX and so that when you turn on the radio 35:45.620 --> 35:54.420 it starts a script in format time that was autoexec.bat now we do something a bit more sophisticated 35:55.380 --> 36:03.620 and the idea is to expose open RKX internal functionality to Lua so that you can control the 36:03.620 --> 36:12.340 radio completely from your script but then also that we can call into Lua code from open RKX core 36:13.380 --> 36:21.860 and we want to create an event system independent from scripting by the way in open RKX 36:21.860 --> 36:28.420 that triggers events whenever something happens like you change the volume you change the frequency 36:28.420 --> 36:35.860 you tap a button so that the Lua script has a possibility to get at this events 36:38.260 --> 36:47.220 this will of course be optional in the in the open RKX firmware because we are not yet sure 36:47.300 --> 36:54.420 if you can if you can really put the engine although it's very very small Lua if you can put it 36:54.420 --> 37:00.740 in every radio so there will probably be radios that have to support and there will be radio 37:00.820 --> 37:17.780 that don't. Now the memory system for open RKX does of course when you take it the 37:18.100 --> 37:23.940 radio and you modify it in open firmware the first thing you think of is code blocks 37:25.780 --> 37:33.620 and but code blocks they they have been invented for a purpose and this purpose is not hammer 37:33.620 --> 37:40.740 radio and it requires software on a PC to prepare this code block to load it on to the radio 37:40.740 --> 37:47.700 and then the radio basically can only use this program frequencies, talk groups and sounds 37:48.180 --> 37:53.940 and you cannot program it on the radio and as hammer radio operators we want to be able to do 37:53.940 --> 38:02.820 such stuff on the radio itself so the discussion we discussed I think about for two or three hours on this 38:02.820 --> 38:12.100 issue should we go code block style should we use data structures in the software and some binary 38:12.100 --> 38:23.140 format on on to to store this how it is binary format look like or does it need to be code 38:23.140 --> 38:30.100 blocks or should it better be like a memory system with memory banks or memory groups call it 38:30.100 --> 38:37.300 whatever you want or to be used static files and then we had this idea why not give a 38:37.300 --> 38:50.660 SQLite a try and store this data in relational database sounds crazy at first as we saw the 38:50.660 --> 39:00.180 also maybe it's crazy but then it can run on an Arduino Uno SQLite and each radio has more 39:00.180 --> 39:08.900 power than that so we think it could be done and we will give it a try we will load lots of data 39:08.900 --> 39:16.900 in it and see how fast can we retrieve the data we have of course little issues with how what happens 39:16.900 --> 39:24.900 if you turn off the radio to not corrupt the database and I forgot to mention to store the 39:24.900 --> 39:33.380 this data we will use little fs in which is in the meoxics kernel that we use so we'll have a file 39:33.380 --> 39:41.380 system on the radio and when we have a file system we can use SQLite to store data and if this 39:41.380 --> 39:48.580 works you can download our architect's link the SQLite file of all your channels that you have 39:48.580 --> 39:56.020 defined you can edit them with an SQLite house a SQLite editor whatever so we think that 39:56.020 --> 40:04.900 this would give us a tremendous flexibility and I think that was the last slide yes indeed 40:05.860 --> 40:09.860 so are there any questions at the moment 40:19.380 --> 40:21.380 yes 40:25.380 --> 40:30.740 the question was what is the plan for adding a DMR support on 40:31.220 --> 40:43.220 open our kicks and I think I hand this over to the boss okay I would say probably first of all 40:44.820 --> 40:51.540 let's expire the button then we will see I mean no out of joke 40:51.860 --> 41:03.060 these devices come with a with a companionship which does all the protocol and the MR 41:03.620 --> 41:12.420 by itself is an Etsy standard so it's public and yeah there is no problem in implementing the MR 41:13.140 --> 41:22.580 problem is the audio codec which is patented and you cannot extract the binary of this 41:24.180 --> 41:31.700 codec from the original firmware and put it into your firmware it's still patented infringement due 41:31.700 --> 41:40.020 to redistribution so this is why we don't have the MR so far but this said 41:40.660 --> 41:46.820 we also have the problem of reverse engineering this dumb chip which does not have documentation 41:48.500 --> 41:57.860 so to come to an answer I added to be honest is I don't know I hope to have the MR in 41:59.860 --> 42:05.700 as soon as possible in the next years but yeah currently because of those problems 42:06.180 --> 42:14.020 honestly not yet a priority because yeah it's a difficult way to get there 42:22.420 --> 42:30.580 okay question is if I want to get started with OpenRTX and as an end user which radio should I get 42:30.580 --> 42:40.020 and yeah would say if you go on the website or on the readme page of the repository you have a list 42:40.020 --> 42:48.020 of the devices supported on the website there is also a list which I would say it may need some 42:48.020 --> 42:58.820 updates about the development status of all the supported devices I in general if you want to go on 42:58.900 --> 43:10.100 the chip way you can take an MD UV 380 or radius like that which I would say that are quite available 43:10.100 --> 43:19.780 on the free market second hand markets can buy them for reduce price or I don't know if you want 43:19.860 --> 43:29.860 the complete fully functional hardware out of the box then you have to take this yes 7000 43:31.460 --> 43:37.220 it depends if you if you're not afraid of modifying your radio and you're interested in 43:37.220 --> 43:44.420 17 you can go also with the title once if you for some reason you don't want to open up your 43:44.500 --> 43:52.180 radio and change some parts then you have to buy the other one or find someone which wants to 43:52.180 --> 43:55.300 modify the radio for you 43:55.380 --> 43:59.540 following up on the special you presented that there is a 17 44:01.140 --> 44:09.060 upper one yeah and you said well I know that because I take out the rooms it's this realistic 44:09.060 --> 44:16.660 you're thinking that okay yeah the question is is it is it realistic that 44:18.420 --> 44:22.500 module 17 version 1.0 will pop on the market no 44:25.300 --> 44:40.660 okay yeah okay okay okay okay yeah for the remote people question is what basically what's 44:40.660 --> 44:49.300 the entry level of building my own module 17 and yeah well it contains SMD components 44:50.260 --> 44:59.780 I would say it can be soldered by hand because the okay smallest size is 0603 which okay 44:59.780 --> 45:05.460 are small but not that small but also if you have an marketplace which has the 45:06.180 --> 45:12.740 reflow oven or yeah you can you can you can assemble those at home no problem 45:13.060 --> 45:18.420 I would say that I also have to say that the very first versions have been assembled at home so 45:19.140 --> 45:24.260 yeah you can do it you can do it no problem yeah 45:24.580 --> 45:27.380 we have the DMI issue that I and the 45:27.940 --> 45:33.620 yep we would be possible to switch the credit down to something like credit to on like 45:33.620 --> 45:38.820 standard right years or is that like too much of a like semi-autic relationship with the 45:38.820 --> 45:48.580 trends between DMA okay and question is is it possible to switch the codec with DMR 45:49.460 --> 45:58.740 and the answer is yes you can do that however you will land up with your own version of DMI I mean 45:58.740 --> 46:09.700 it's completely doable I think that someone attempted doing so but all the remaining infrastructure 46:10.500 --> 46:17.860 does not support it so your your your voice will not go through and as far as I know 46:19.300 --> 46:25.140 to do the MRE you will need at least a repeater I don't know if point to point honestly 46:25.140 --> 46:32.500 if point to point the MRE is possible probably yes is it okay it is but yeah I mean 46:34.100 --> 46:41.940 technically doable but yeah it's your own is rolling your own version of the DMR standard 46:41.940 --> 46:51.140 yeah I mean probably for the sake of science which should try to do that but yeah 46:52.980 --> 46:58.420 okay so if you have more questions we're here all day and there is the amateur radio 46:58.420 --> 47:07.140 info booths and there are lots of M17 stuff there in the AW building around floor thank you 47:11.940 --> 47:13.940 you