Okay, welcome everyone, so yeah, M17 and OpenRTX, one year later, basically it's follow-up
of the talks we gave, I gave one on OpenRTX last year and Morgan gave one on M17 last
year, so yeah, this is what happened one year later.
With introduction, I'm a radio operator from Italy, Milan, I leave being a firmware developer
by profession, I manage to turn this a passion into a profession, but I still keep the
passion and yeah, and I am co-founder and developer of the OpenRTX project, which began
in 2020 during COVID, because yeah, we were basically at home doing nothing and we wanted
to do stuff, so we started working on this project and yeah since 2021, I'm also one
of the, I would say, core members of the M17 team, which we will see in a brief moment
what does, so brief recap of what M17 is, I want to go into the details of this project
because we had a talk last year, which covers all the details, basically M17 is first
of all the community of OpenRTX developers and radio enthusiasts, which gathered during
years around the main idea of a Polish-Harm radio operator, Vocic, Sierra Pava 5, with
Kiewiski Pava, which at some point decided to develop and devise and openRTX protocol
for Harm Radio, a completely open source protocol, open source specification, voice code
and so on, so yeah, first of all M17 is this community revolving around this idea of open
Harm Radio stuff and main goals are promoting this protocol and working on specification,
working on all the details of this protocol, but also developing open source firmware and software
to deal with, yeah, and Harm Radio stuff, but also developing open source hardware and I will
show you an example of this hardware and in parallel we have OpenRTX, which is more about
developing a firmware for Harm Radio devices, also supporting M17, but in principle not
only supporting M17 is, I would say is a parallel counterpart of M17, M17 is a protocol,
this is a firmware which implements M17, but the ideas are shared, objectives not completely
coinciding, this firmware has been devised from scratch in order to be modular, which means
that you can easily add protocols or features to this firmware, easily portable to new devices
because in our experience with the previous project, we saw that that project was so tightly
coupled with the hardware that it made basically impossible to port it to new devices, the beginning
of this project was an attempt of porting OpenGD77 to a specific radio and then we realized,
okay, this firmware is too tightly coupled with the hardware that we need to basically
redesign everything from scratch and this is how we got here and yes, it is easily
extendable to new protocols, going to hardware, this is what happened during the last year,
finally, this is the one point zero revision of basically a modern device which allows you to convert
any radio you have to an M17 radio, hardware completely open source, you have the files,
you can manufacture it, just send a galber files to any PCB manufacturer,
so completely open hardware and yes, it runs OpenRTX, so it's open from hardware to software
and yeah, it has been released at 29th of June, 2024 during Humradio for this often,
we decided to take this occasion of releasing this finally, this hardware after like at least
couple of years of iterations during, we decided to take the occasion of Humradio for this often,
also has a symbolic way to say, okay, now it's finally we have something we can show, we can
distribute, with respect to the previous versions you can find around, we have some at our
booth downstairs, the board has been completely redesigned because yeah, first of all we wanted
to fit it into an aluminum case because before this we had only bare PCB boards which are a
mess to deal with, you would be sending out with short circuits, you don't know how to put,
where to put them so on support, so we redesigned completely board to fit it into an aluminum case,
and it has a new user interface board because the previous one had physical buttons
and this one has touch buttons, yeah, it has been organized to be a little more user friendly,
yeah, we have a fix on the audio amplifier because we have a design issue with it,
basically it didn't work very well, it could volume was very low, and we had this connector here
which looks like an Ethernet connector but it's not an Ethernet connector,
basically it's an interface named open headset interconnect standard, it's a specification
devised by an American ham radio operator with the aim of providing a standard interface
connector for all the ham radio devices allowing you to plug whatever microphone and speaker
devised you have to any ham radio device, so it's not very popular but we decided to include
this connector, yeah, has a way to promote this standard which hopefully will make the life
a little better because now each radio has its own standard and its own format of the connector
for the mixed speaker and you end up having like 40,000 mixed speakers each one for each radio
and you get crazy, so yeah, we decided to include this connector which is not present in the previous
revision boards and yeah, we changed the license of the hardware which now is licensed
under certain open hardware license and also yeah, we have the open source, the open source
hardware certification we have, yeah, the mark for, now it's really certified as open
under and for those interested will it be available in the market probably yes,
there is Lily Go, the famous Chinese manufacturer and distributor of
hardware which seems to be interested in manufacturing this device but I cannot say anything specific
because it's something going on in the background and I don't have really fresh news about this
going on still about hardware we have finally the very first commercial device having an open source
film on it it is a cooperation from connect systems and open at the axe it took I would say
one year to get here we started we all started with an email from the CEO of connect systems
which is on the American United States based California distributor of the radio devices
which is interested in supporting the M17 protocol and all started one one year ago with an email
from Jerry saying I'm interested in M17 I want to do something would you help me so
finally one year later we have the first radio it's first version of firmware has been released
and July 2024 alongside we hardware we took an already existing hardware and we applied some
hardware modifications to make it M17 compatible and yeah now is available on the market
is UHF only unfortunately is not a dual-band device it's a single-band UHF only
there is no VHF version that I'm aware of so quite a validation but we can live with it it goes
way over the ham radio band plan because originally the hardware is for CVUs so for example security
people and stuff so it has a very wide bandwidth but yeah at least it covers also the ham radio so
it's okay and what's inside an STM32F for microcontroller which is the same you you can find the
in the in the module 17 and in the other radios supported by OpenRTX so that was easy
these dumb HR C6000 which is a basically a DSP designed to do the DMR protocol
I would say almost completely obscure you then you don't have a lot of documentation about this
chips or to develop the firmware I had to reverse engineer the original firmware to extract the
informations I needed to make this chip run but yeah I mean it's not ideal but we have it working so
no worries and the radio frequency stage is discrete which means it has a VFO PLL and so on
supported it is not based on radio on a chip like others device like other devices it still has
support for DMR for those interested in doing DMR however it comes through the original
manufacturer firmware which is closed source so technically a dual firmware device you use OpenRTX
if you want to go FM and MS-17 and possibly in the future other protocols because now hardware is
there it's just a matter of firmware and if you want DMR or FM but in another way you have to load the
oven firmware and yeah and also it has a so-called CS-717 plus version which has been released around
in like November 2024 which which has a very BCCPU it has DM32 H7 which basically doubles the
capabilities of the other microcontroller. This plus version is available on the market but
yeah it's the OpenRTX side still has some problems and I'm working on those but I see some potential
because I mean it has a very powerful microcontroller I think you can almost run Linux on this microcontroller
so really you have a lot of perspectives and yeah this speaking of hardware more or less is
what happened in this past year is this module 17 and this other other things are going on but
yeah not not not production radio I would say speaking of software what we have
we have a 17 packet mode which I think is something not really known because so far I'm 17
protocol concentrated mainly on voice but it also has a packet mode and nobody knows about the
packet mode and but yeah speaking of it it transmits data in chunks of 25 bytes and it allows
to send over the air up to 825 bytes basically it divides this big payload into chunks of 25 bytes
each and it sends them over here but yeah you can start doing interesting things with this
and maximum data rate is 4.5 kilobit per second not that fast but still you have it it goes over
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
for example we can control and command the beaters yeah you are chef link you can just send
commands and data and you have telemetry for example over standard radio frequency carriers so
you don't you don't really need internet access up to the repeaters side we can use it for
messaging services in these days voice check fell in law with SMS over at 17 is done is doing
like a lot of work around sending SMS over at 17 so yeah you can use it to send SMS but
also hopefully something more interesting and useful than just text it texting with your friends
over at 17 and finally wireless access on networks but these are just free examples so
for the meme we would say that so far nobody expects the M17 packet mode and now we have it so yeah
going to coming to an interesting use of M17 packet mode we have M17 net net net
which has a demon developed by Morgan which allows you to create TV for links over
17 packet so you can message for example to you something over 17 why because these comes from
a real use case scenario that is transmission of data in like industrial environment with
with those nodes right here there's mission nodes very far away one to each other so
either you run kilometers of cable or you go another way and but yeah why not using TV4
I mean you have an infrastructure over these and yeah written by Morgan it's based on the
Linux 2 top driver and not on does not rely on a random driver in the Linux kernel written by
a hand radio operator 40 years ago not maintain it anymore which breaks down because I just change
the Linux version so it's really 2 top device you open you have a network device and you send it
over the network device and you're done downsides so far it works on the on PC with a
next year because this was the development environment but soon TM will come with a TX link
which will give you the possibility of using your real real magic device to transmit data
over TV4 and something like that and yeah if you want to play with it you have code available
on GitHub and you can take it and use it more the well more stuff to come and yeah
thank you my my part of presentation just finished I just want to give you a brief update and now
I leave the stage to mark which will talk you about what happened yesterday basically
oh the call this in automotive sports box in stock
good stop good stop yes right software for race cars that's why I make this
okay I think you can hear this welcome my name is Mark I'm also a hand radio operator
HP-SP I'm a long time open source developer and I'm also since short time the open source project
coordinator for year-to-region one so I'm also the author of software to control
transceivers TRX control and as I met Sylvano on several occasions I thought well I should be
able to also control with TRX control open RTX radios and it has a protocol called RTX link
which is the cat interface to open RTX radios and it is fairly well documented it doesn't do as
much as a year is a radio does but then I mean this is a working progress and project on the
development but nevertheless I took this documentation and implemented it and I should theoretically
be able to read out the frequency set the frequency set the operating mode and but for some reason
I just was not able to set the frequency and I double check with the documentation and my implementation
and yes it was done correctly so what the hell was going on and then unfortunately I made the
mistake to start looking at the source code of RTX link and open RTX and the well there was
this comment to be implemented and then I knew why I was in the last hours not able to set the
frequency on the radio so but what do you do when you're a developer and you find such a comment
it was like a command not a comment so I fired up the editor and I started implementing this stuff
and then I found other commands that were not implemented and so I asked some time I got it working
and this kind of dragged me into this project and I hacked this RTX link protocol
after Sylvanas showed me how I can build the firmware and load it onto the radio so that's how it
came that I became part of this journey and because there were so many open questions and we met
the meat here at first them anyways I asked Sylvanas what do you think about the idea of doing an
open RTX hackathon on Friday before first them so that we meet somewhere and he said oh yeah good
idea so I looked for a space and actually the Brussels Hockey Space offered us generously to
to be there guests and so yesterday we met at the Hockey Space in Brussels which is a very nice
community I must say and they have great rooms and great possibilities to hardware hacking and
they have even have CNC machines and whatnot and then they're met some developers from Italy Switzerland
Germany Belgium France to spend a day on
this is a strange user interface so first thing sort out the topics what do we want to discuss
what do we address next because we had quite a few issues that were open and so
we first made a list that's the table of contents of my talk basically we first did a
little brainstorming session we had this RTX link branch with diverged quite a bit from the
master branch partly this is my fault because I continued to work on the protocol and at one
time we should merge this into the main line of the firmware in the master branch so this was an
issue that we had to discuss because it has diverged for more than one year so the master branch was
something completely different so this was probably already m18 and RTX link was still
yes you get the idea then we discussed a new cut interface computer edit
conceiving along with RTX link I will come to that in a minute the status of some particular
radios was an issue you probably heard of this UV380 radios which have a 5 watt
transmitter there is a waterproof addition here he shows you one there's a waterproof addition
the UV390 and then there is a third addition the UV390 in 10 watt now that's nice but
this slightly different we'll come to that later and another topic was how to use m17 for data transfer
and not only voice coding we heard about the project where it is done in a very particular way
but it would not work with any open RTX radio so we wanted to discuss how can we use any
art open RTX radio to for data transfer then very wild idea maybe not so wild if you know me
better is making open RTX scriptable with a scripting language and one very very important topic
in my opinion until now in open RTX you can set the frequency and a mode if you want to use
another frequency you can change the frequency but what you cannot do is you cannot store a frequency
and then make channels or whatever so in DMR speak that would be code blocks with the zones
and the top groups and whatnot or in other commercial radios we have a memory system with channels
channel groups and so on so we need something similar for open RTX so this is also the point
that took the most time of the day actually but let's start with RTX link RTX link is nice
because it makes sure that the data is not corrupted it uses CRC codes it uses a
slip framing for serial lines and this is a bit it's not complicated to implement but if you
look at cat interfaces of other radios they're just very simple asky based protocol so you can send
a string and it does whatever you need but let's first the thing about merging it or what we do
we for the moment we will not merge it so sorry if you're using the master branch but Mark will
rebase it so that the branches are not diverging so much they're just diverged by the RTX link
parts so we we're going to rebase it and now I come back to this RTX link issue so we have
CRC we have the slip framing and what we cannot do when you have the the USB serial device
in your let's say Linux computer and you want to talk to the RTX Open RTX Radio you have to
have a client who does all this slip framing and who does the CRC calculations you can not do
like echo frequency blah blah blah and redirect this to the serial port what you can do with the
radio or a can wood radio so it really is a protocol that needs software on both ends and so we
had the idea to add a new cat interface and as a complement I have a lot of typos I see as a
complement to RTX link so RTX link ensures data and credit integrity it's a bit complex
for simple cat operations so the new cat interface will be simply text oriented like done in
yes or can wood radios but it will have a command to switch to RTX link mode so when you have
to flash the firmware for example then you want to be sure that the data you send comes into the
radio as is so we switch to RTX link and then we have a transfer channel which allows us to
transfer data in a secured way I will also discuss that when it is possible when the radio for
example is connected to the computer using USB that we use multiple endpoints so that there could be
endpoint for the cat interface and the separate endpoint that talks directly RTX link protocol
okay that was the ideas for computer to radio operations now the situation of these these radios here
I don't know what these engineers defeat they smoked but they just changed to GPIO pins
that's the only difference power amplifier and backlight GPIO they are reversed yeah so on the
UV 390 10 watt if you want to transmit you have to turn on the backlight and if you want to see
something on the display you have to press the PTT button which completely makes no sense in a way
but then there is no way to detect the model you have in software we decide we first so we could
display a message at boot up 3 press the PTT button and those who do not see the message do not press
the PTT button so when after one second PTT is not pressed we know we are on this 390 okay
we decided on a more pragmatic way we're going to provide two for very images one for the 390
plus or 10 watt version and one for the 5 watt version assuming does that the person owning the device
knows what device he or she has um the MD96 title is also the MR mobile radio and it's very
unspectacular what we have to say here we need to collect more more information these radios they
have a ton of hardware revisions and they're probably different and none of them works so
we're now looking at the radios we have a chance to see what revisions there are we collect data
and other than that there's no news on this front
M17 for data transfer is somehow logical because M17 already is a digital transmission mode
and the idea we developed then what morning report does require special hardware
correct me if I'm wrong yes for now it requires special hardware so the idea is to bring
this net B and RTX link together so look at net D why it doesn't use RTX link probably
because RTX link is just not suited for the use case so we will have to extend the RTX link protocol
for data transfer and then all this stuff with the term and top device and IPv4 and of course in the
future IPv6 is done in the net D part which uses then RTX link to talk to the radio and the radio
does all the stuff that needs to be done on the M17 site so in the future we hope that M17 net D
team and the demon can talk the RTX link protocol and use any M17 capable radio to transfer data
we have to keep in mind that this will be slow this is not 10 gig Ethernet link
this is probably 2500 bit per second something like more in size it's a bit more okay
will be 3000 bit per second okay now he said it doesn't make sense to implement the RTX link protocol
in each client that wants to use it so we have plans to provide an open source library under
the MIT license for POSIX systems that implements the client side of RTX link so that they can be used
by any software that wants to make use of an open RKX system
the next thing is to add a scripting engine to open RKX and so that when you turn on the radio
it starts a script in format time that was autoexec.bat now we do something a bit more sophisticated
and the idea is to expose open RKX internal functionality to Lua so that you can control the
radio completely from your script but then also that we can call into Lua code from open RKX core
and we want to create an event system independent from scripting by the way in open RKX
that triggers events whenever something happens like you change the volume you change the frequency
you tap a button so that the Lua script has a possibility to get at this events
this will of course be optional in the in the open RKX firmware because we are not yet sure
if you can if you can really put the engine although it's very very small Lua if you can put it
in every radio so there will probably be radios that have to support and there will be radio
that don't. Now the memory system for open RKX does of course when you take it the
radio and you modify it in open firmware the first thing you think of is code blocks
and but code blocks they they have been invented for a purpose and this purpose is not hammer
radio and it requires software on a PC to prepare this code block to load it on to the radio
and then the radio basically can only use this program frequencies, talk groups and sounds
and you cannot program it on the radio and as hammer radio operators we want to be able to do
such stuff on the radio itself so the discussion we discussed I think about for two or three hours on this
issue should we go code block style should we use data structures in the software and some binary
format on on to to store this how it is binary format look like or does it need to be code
blocks or should it better be like a memory system with memory banks or memory groups call it
whatever you want or to be used static files and then we had this idea why not give a
SQLite a try and store this data in relational database sounds crazy at first as we saw the
also maybe it's crazy but then it can run on an Arduino Uno SQLite and each radio has more
power than that so we think it could be done and we will give it a try we will load lots of data
in it and see how fast can we retrieve the data we have of course little issues with how what happens
if you turn off the radio to not corrupt the database and I forgot to mention to store the
this data we will use little fs in which is in the meoxics kernel that we use so we'll have a file
system on the radio and when we have a file system we can use SQLite to store data and if this
works you can download our architect's link the SQLite file of all your channels that you have
defined you can edit them with an SQLite house a SQLite editor whatever so we think that
this would give us a tremendous flexibility and I think that was the last slide yes indeed
so are there any questions at the moment
yes
the question was what is the plan for adding a DMR support on
open our kicks and I think I hand this over to the boss okay I would say probably first of all
let's expire the button then we will see I mean no out of joke
these devices come with a with a companionship which does all the protocol and the MR
by itself is an Etsy standard so it's public and yeah there is no problem in implementing the MR
problem is the audio codec which is patented and you cannot extract the binary of this
codec from the original firmware and put it into your firmware it's still patented infringement due
to redistribution so this is why we don't have the MR so far but this said
we also have the problem of reverse engineering this dumb chip which does not have documentation
so to come to an answer I added to be honest is I don't know I hope to have the MR in
as soon as possible in the next years but yeah currently because of those problems
honestly not yet a priority because yeah it's a difficult way to get there
okay question is if I want to get started with OpenRTX and as an end user which radio should I get
and yeah would say if you go on the website or on the readme page of the repository you have a list
of the devices supported on the website there is also a list which I would say it may need some
updates about the development status of all the supported devices I in general if you want to go on
the chip way you can take an MD UV 380 or radius like that which I would say that are quite available
on the free market second hand markets can buy them for reduce price or I don't know if you want
the complete fully functional hardware out of the box then you have to take this yes 7000
it depends if you if you're not afraid of modifying your radio and you're interested in
17 you can go also with the title once if you for some reason you don't want to open up your
radio and change some parts then you have to buy the other one or find someone which wants to
modify the radio for you
following up on the special you presented that there is a 17
upper one yeah and you said well I know that because I take out the rooms it's this realistic
you're thinking that okay yeah the question is is it is it realistic that
module 17 version 1.0 will pop on the market no
okay yeah okay okay okay okay yeah for the remote people question is what basically what's
the entry level of building my own module 17 and yeah well it contains SMD components
I would say it can be soldered by hand because the okay smallest size is 0603 which okay
are small but not that small but also if you have an marketplace which has the
reflow oven or yeah you can you can you can assemble those at home no problem
I would say that I also have to say that the very first versions have been assembled at home so
yeah you can do it you can do it no problem yeah
we have the DMI issue that I and the
yep we would be possible to switch the credit down to something like credit to on like
standard right years or is that like too much of a like semi-autic relationship with the
trends between DMA okay and question is is it possible to switch the codec with DMR
and the answer is yes you can do that however you will land up with your own version of DMI I mean
it's completely doable I think that someone attempted doing so but all the remaining infrastructure
does not support it so your your your voice will not go through and as far as I know
to do the MRE you will need at least a repeater I don't know if point to point honestly
if point to point the MRE is possible probably yes is it okay it is but yeah I mean
technically doable but yeah it's your own is rolling your own version of the DMR standard
yeah I mean probably for the sake of science which should try to do that but yeah
okay so if you have more questions we're here all day and there is the amateur radio
info booths and there are lots of M17 stuff there in the AW building around floor thank you
you