Hi, welcome everyone and a small technical problem, I almost lost my voice when standing
at the ham radio booth.
So you know my voice is not very good today.
Anyway, I'm going to talk about the OpenRTX project which is an open source firmware for
ham radio devices.
We will see it's not only an open source firmware, it's also a little more.
First of all, who am I?
Also known as Redman on the various communication channels, Matrix and Discord and so on.
I come from Milan, Italy.
I'm a ham radio operator since 2017 as India Uniform 2 kilo Whisky Oscar.
I do not do so much ham radio activity but like on air, I do it on hardware and on code.
I'm a firmware developer by profession and for I work in motorsport industry.
I'm co-founder and developer of OpenRTX and also member of the M17 team since 2021.
So OpenRTX, it's as I say, an open source firmware for ham radio devices which is by
design modular which means that you can, it's designed to allow you to easily add or remove
components.
It's designed to be easily portable to new devices.
You want to have it on whatever radio or whatever device you prefer.
You can almost take it and implement a couple of files and have it up and running on your
new device.
And finally, it's easily extendable to new protocols which means that we try to standardize
the interface between the firmware core and the protocols so that you can implement your
own protocol in the firmware without too much pain.
Finally, it's currently supporting only FM and M17 even though it has been developed
primarily on DMR devices.
I will tell you why it does not support DMR now.
And finally, not written here, licensed under GPLV3.
So a bit of timeline.
The project started in March 2020 and it started because of COVID.
It started because me and Nicola, the uniform 2 kilo indian November were at home basically
with nothing to do.
We decided to try porting the OpenGD77 project to the Taitira MD380 which at the time was
known also and it's still known also because of the work done by Trevis Goodspeed on MD380
tools.
He did a lot of reverse engineering, modding and work on the original firmware.
Then in September 2020 after a bit of work already we already brought up the radio driver,
the display and a bunch of stuff.
We realized that the OpenGD77 firmware was too much connected with the structure of the
radio.
So we decided to, okay, let's take everything, restart from scratch, design things from top
to bottom instead of adapting the firmware to the hardware.
So yeah, we abandoned the original idea of the porting and we can say it's the official
beginning of OpenRTX because we created a separated repo with the OpenRTX name before
it was known as, it started as OpenDMR.
Only 2021, so like four months later we had the first release, V0.1 with working FM, transmission
reception MD380.
Also one month later we joined the M17 team and we started doing some experimentation about
transmitting M17 with the MD380.
A bit of time after we brought up the support for GD77, MDM18, M1, MD380 plus a lot of work
in the middle and finally in May 2022 we released the V0.3.3 version which has full support
for M17 voice transmission.
But now basically since that version you can take radio and flash the firmware and you
can use it for M17.
Then November 2022 we had a huge contribution from a home radio operator from Australia
which implemented the voice prompts for vision impaired operators for extended accessibility
and in the end October 2023 we wrote a BSP for the Lilligo TTWR Plus which is a small device
you can buy easily and play with with ESP32 and radio module and various technical improvements
in the middle, restructurations, every 10,000, M17, MD later on.
A lot of stuff and yeah more to come.
So the supported devices are those.
We saw them in also in the timeline.
We have the two Taitira, Retivis radios, MD380 single band, the other one is dual band,
single band is UHF or VHF and the other is VHF and UHF.
They both do FM and M17.
GD77 and DM1801 they do only FM, they are DMR radios, they cannot do M17 for technical
reasons.
I will give you a bit more details about M17 implementation later and I will tell you why
those radios cannot support M17.
We have the M17, MD17 and then finally the Lilligo radio which now does only FM in the
future is going to be, is going to also support M17.
The hardware is good, it's just a matter of writing drivers which is not an easy task
always.
So the internal structure is of the firmware is this one.
There is at the bottom there is an interface with the operating system which can be either
real time or not.
It's preferred to have a real time operating system on the radios because you have to do
protocols and protocols have timings and so you know you cannot just have like normal
scheduling.
Then we have our hardware interface API which is a set of other files which define the functions
used for keyboard and display and so on.
In the middle which is the code which is common between all the devices.
I called it the core part.
It has a small graphics library written by us.
We thought about using LVGL but it was a little bit too heavy because one of the objectives
is to keep the code size as small as possible.
So LVGL was a little too big at least for some devices.
There is GPS for the radios who have the GPS.
There are voice prompts.
All the system to have save, restore of user settings and default settings and settings
management.
There is the code plug system which allows you to have a list of channels and contacts
and stuff like that and saved in the radio.
Also the audio management subsystem which is a mechanism we set up to make easy the
management of audio connections.
You can, we have those concept of audio path and audio stream so that you can easily open
a path from source to destination and the audio management system is responsible for
actually talking to the hardware and making the various connections and managing the possible
conflicts between those paths.
Because if you open a path towards a device which is already busy, either your path has
an higher priority and you go over or you get rejected but you need code to manage this.
Then there is the UI which is the part for keyboard UI basically.
And then the operating modes now is FMM 17 but yeah, more to come and we have some ideas
of what we are going to implement in the future.
So yeah, regarding the interface with the operating system, all the code uses the standard
POSIX API which means that any POSIX compliant operating system is good.
For example, we already run the firmware also you can compile and run it natively on Linux
which is very good for debugging when for example you are developing UI or other parts
instead of compile, flash, test, debug, modify and go on.
You can run it on Linux so yeah, any POSIX compliant operating system is good.
All the remaining pieces use the standard C library so you need operating system which
supports them and yeah, if possible use real-time operating system on embedded devices.
The other interface is as I said, we have API function for display, keyboard, audio connections,
management of the radio section and for the non-volatile memory plus like general purpose
platform API which is used for device initialization and to manage all the other things which do
not fall in the other categories like the LEDs, calibration data, hardware information
data, so on and so forth.
Yeah, and also the code is made such that you can share an implementation between devices
as long as there are similarities between the hardware of the various targets for example
in the MD series radios.
The display is always the same, is always connected there.
We wrote the display driver once and we compile it for every target.
As regards the user interface, currently we have standard let's say GUI which is the
GUI you can find on the all the handled devices plus a dedicated GUI for the module 17 just
because the module 17 does not need all the elements of the standard radios and also it
requires some dedicated entries in the menus for example for calibration of levels and
so on.
So given that module 17 is not completely radio we decided to make a dedicated GUI only for
it but this also means that if you want you can also write your own GUI from scratch or
you can also run everything in address mode without the GUI.
Yeah, we have also future plans of making the GUI scriptable or expandable with modules
such that you can for example implement your own module like satellite tracking module.
You can just, we expose, we give a standard interface to interconnect with the rest of the GUI
and then you can just write your code using that interface plus the graphics functions
and that's it. You can add whatever you want.
For the operating modes we are using C++ and yeah, I didn't say that all the code is written in C
plus some pieces in C++. We use the C++ for the operating modes, simple C++ luckily just
because it was a bit more handy to use C++ to do that part.
We define a generic operating mode class which has a bunch of functions to enable, disable,
to have periodic update if you have to check, squelch, make computations, whatever and the
function return in the squelch status which then gets queried by the GUI and so on.
So, yeah, to define your own operating mode you just have to subclass the operating mode class
and then implement the interface functions and integrate it into the list of operating modes
and you are done.
And yes, there is still some work to do on the operating modes because for example now there is
not a clear way to for example set some configuration data of a specific operating mode.
For example, M17, yeah, now this code is a little hacked in order to allow the user to set easily the
source call sign, destination call sign and stuff like that.
So, as regards M17 in particular, as I said before, we started the work on MD380, then we extended to the
MDUV380.
By the way, we started on the MD380 because luckily we had the schematic of the radio.
So, we were able to see if there were actually possibility from the hardware to implement this.
Everything is managing inside the microcontroller and also, and this is why the other radios cannot do M17,
is that the hardware must have the following connections.
Everything is done inside the microcontroller.
The microcontroller has to sample the microphone for audio encoding.
It has to sample the demodulated audio from the radio stage because we do all the 4FSK modulation in software
in code.
So, we have to sample the raw data with 24 kilohertz and the connection must have the enough bandwidth in order to
not distort the signal.
And like, so to say, outbound we have to be able to send raw data, raw demodulated speech to the speaker
in form of analog signal and also send the basement off to the radio frequency stage for modulation.
And yeah, we need those connections.
The GD77 locks the, for sure, the ref stage to the MCU.
MCU to speaker, I'd probably, it's okay and the MCU to ref stage also.
So, it cannot send and receive basement.
The microcontroller cannot send and receive basement to the ref stage and you cannot go on air this way.
And current problems we have, yeah, you have to mod the hardware of the radio if you want to have M17 on it.
Quite a limitation because, yeah, you know, you have to have a bit of practice with soldering of SMD.
There are guides on the website, but yeah, you still have to do that or have someone which is a couple of doing that.
Given that we are doing everything in the MCU, the MCU has to be powerful enough, which means now M38 has 168 MHz CPU, Cortex M4, which is powerful enough.
The point is that for M17 you have to send a frame every 20 milliseconds.
So, you have to do everything in 20 milliseconds, audio encoding, baseband and so on.
If your MCU is not quick enough, you cannot do that.
And finally, yeah, quite a problem.
Codec 2 is using floating point math, which means that if your MCU does not have hardware acceleration for it or it does not have enough clock frequency, you are busted.
Because you are not able to stay within the timings of the protocol.
As regards the codeplug, when we started, initially we thought about parsing and keeping the original codeplug format of the radio manufacturer.
But we decided not to do so because otherwise we would have to manage a shitload of codeplug formats with various versions.
A mess, basically.
So, we decided to, okay, let's write and specify our own format.
So, we tried to make something which is open free, of course, which supports common ham radio needs.
Direct communications, repeaters, hotspots, whatever.
And also portable across devices.
These both for end users, you have your codeplug file and you can move it around openRTX devices because the structure is the same.
So, they speak the same language.
And also for developers, you can take the reference implementation and use it in your own project if you want.
It's currently working progress.
There is a request for comment open on GitHub.
Please take a look at it, comment, help us.
We need a bit of feedback from ham radio operators on how this has to be structured.
Technical details.
It is a binary format, which means that you can either write it row mode to the non volatile memory or inside files.
And it's also compact because, yeah, it's binary.
Up to 65K channels.
So, a lot of space.
And this currently supporting FM, DMR for like historical reasons because we worked on DMR radios.
And yeah, I'm 17, but more to come.
It's something you can extend.
It's already designed to have more than those operating modes.
And also it may become a separate entity from the firmware.
Just because we want to make it something which can be used by hopefully also radio manufacturers.
I hope at some point in the history to have it become like reference standard for exchange of codeplug data because now each codeplug is specific to the radio.
There are softwares which allow to convert code plugs, but yeah, it's not as easy as taking one file and flashing it into different devices.
So summing up what's next on the other side codeplug.
We have it's the next in the row.
Schedule for we are working on this.
In these days.
This is a bit more internal to the firmware and event exchange system so that you can register to events or send events which can make the development a bit more easy.
Also, APRS support because why not.
And more to come probably we have to integrate because it has been done before GPS tracking.
I want to have something for meteorological zones radio zones the modulator for those.
And then we will see.
No DMR in the end because we still have the problem that.
Audio codec is patented.
And yeah, how do you include the patented binary blob in your work without.
Risking of being sued for patented infringement.
I don't know.
It's open problem. We have to find a way to solve it.
And yeah, this is the main reason why there is no DMR on it.
The point is the maries open states public specification.
It's a.
Etsy standard but yeah, the problem is the codec for the short.
And hardware side which wins hardware support.
Open HD.
Bow fang DM 1701 which is another radio which can do.
I'm 17.
This quite a dream.
Yeah, is a series of radios.
Difficult because of the microcontroller they have.
All the microcontroller for automotive from 2008.
Big Indian no debugger.
No the compiler.
It's a mess.
But you know why not.
And also yeah more to come.
So that's it.
Happy hacking.
Okay.
Yeah.
Yeah.
Yeah.
The ones not doing 17 you said.
Yeah.
What okay.
About the ratio.
Yeah.
Yeah.
So question is what about the devices which do not have the they are which now do not have the hardware connection.
What if they had the hardware connections.
Well, they would do M 17 is once you have the hardware connections.
Then it becomes just a matter of writing the drivers and you have M 17 support.
So it's on on this.
Thanks again.
Yeah.