Hi everyone. Maybe before we get started, how many of you do know about ham radio? This
is kind of the topic of the room I know, but still. Okay. And how many of you are ham
radio licensed? Nice. Okay, good. I still have included a small introduction.
Please put up your hands again. License operators, please. All right. So I still have a brief
presentation and introduction to the topic for you. Your experience with ham radio might
not be my experience, so I think this introduction is interesting. And then we will have a brief
overview of what ham radio and open source means. Not everybody understands open source
the same way, especially, I think, in ham radio community. You will see that open source
in ham radio did face and does face a few obstacles. We will pinpoint a few of those.
We will see the workarounds. And then finally, we will talk about M17, which is the project
that I want to talk about today. So first, who am I? So I'm a research engineer at the
University of Friage in Belgium. I do mainly embedded systems and RF. I'm a licensed ham
radio operator for two years now, called Sine of kind of number four, my Oscar Delta. I joined
M17 project one year ago, right after Fuzzdem. Wow. And yeah, I mostly do hardware design,
some of which you can see on the table in front of you. We will go back to that later
and work on firmware. Okay. Amateur radio, I think you, then almost everybody knows about
this logo for ham radio. This is a technical hobby. This is the goal is to experiment,
to play around, to have your hands dirty. It allows you to legally transmit uncertain
frequencies, which are allocated to amateur radio operations, and which you cannot do
if you don't have your license, of course. The hobby is extremely vast. So you have
operators which will do what we call DX, which is reaching the furthest away on the globe
using lowest power or specific modes, frequencies, whatever, which is called working demands.
You have people which are dedicated in antennas, transceivers, reception, transmission, whatever.
It's very, very, very vast. And I think most of you also know that the mainstream products
come from just a few brands, ICOM, Yezu, Kenwood, and then that's pretty much it. And you have the
Chinese brands, and usually your typical ham radio, Joe operator, or whatever, doesn't know about
those Chinese brands. So open source in amateur radio, well, this is a bit controversial, a bit
difficult to describe, but the ham spirits, which live in every one of us, have always been about
sharing design, ideas, discoveries, the problems we encountered, and how we did solve them.
You could call that open source knowledge, maybe, which is not to be confused with the fact that
most digital voice protocols that we use have published specifications, which means that if you
dig deep enough in whatever search engine you use, you will probably find specifications for
those protocols. That does not mean they are free and open source, which is very important. And
this is kind of the goal of this presentation. So, yeah. Some protocols are free available. Some
of you know about a few of those. So AX25, which is a material adaptation of the X25 protocol.
Which mainly works on VHF and UHF, so above 30 megahertz, which is not designed for voice,
of course. It's digital, but mainly data bits, let's say. And DSTAR, which is what most of us
could consider open source protocol for amateur radio. It is the first protocol really created
for amateur radio usage. So it is designed from the ground up with amateur radio in mind.
It is open specifications. So from the start, they decided to publish the specifications,
mostly in Japanese. So this can be an obstacle. Maybe if you speak Japanese, it's easier for you.
I don't know. YSF, Yezoo's proprietary mode. Specifications can be found online, but that's
pretty much it. You have to have a Yezoo radio to do YSF. FT4, FT8, just an example of a few modes
that are used. Very slow speed, very long range, very low power on HF. So very low frequencies.
And this kind of illustrates a point I'm going to go to. The new app, of course, DMR, Tetra,
P25, all those commercial protocols which have been adopted by amateur radio, which
are not designed for amateur radio. The main thing is, and especially when you talk about
FT4, FT5 and such protocols, there are many of them, those have only one closed source
implementation. It's not easy to play around with it. You can just, okay, I'm downloading this,
trying to modify this. Is it better? Is it worse? The way you play around is, okay, which power do
I need to reach this country in this weather or whatever, which is not what is suitable to each
and every one of us. So we will briefly take these stars as an example. So released by Japanese amateur
radio club, JARL in Japan in 2001. It uses AMBE codec vocoder from DVSI. So very briefly, vocoder,
you know that voice is very complex signal. You need a lot of bits to transmit the voice,
but amateur radio protocols are slow speed, slow bit rate. So you do need to encode the voice into
something which is manageable by those digital voice protocols. And the way it is done in the case
of DSTAR is using the AMBE codec from DVSI. Specifications are publicly available, but
there is no license tied to those specifications, which means you do not have to publish whenever you
deviate from those specifications. And so it kind of de facto became ICOM's proprietary mode.
It is called DSTAR, but it is not made to be interoperable with other DSTAR implementations,
which by the way, there are not really many other DSTARs implementations.
So yeah, main obstacles. First, manufacturers exploit the fact that specifications are not
really licensed, and so they can find the trick around to lock down their environments.
Main obstacle, second part is technical capabilities. Back in 2001, encoding voice in a microcontroller was
not really feasible. That's why you needed an ASIC, so a dedicated chip on the board made by DVSI
with their AMBE codec to be able to encode voice into bits manageable, but by the whatever digital
voice protocol you wanted to use. So I'm not spitting at DVSI and AMBE all the way. There is
a whole lot of technical reasons why this is that way, but I think it's good to understand
where we come from and to see where we can go from there. So also another thing to notice
DSTAR, YSF, DMR, P25, NXDN, whatever, almost all the digital voice protocols being amateur radio or
even commercial protocols use AMBE, AMBE to plus basically AMBE and variants of it from DVSI.
Basically one vocoder to rule them all. So how does one think are with closed source vocoder?
You don't. At least not really. But hey, the vocoder is an integral part of the protocol, so
how do you do? What do you do? Is it possible to have what we could consider fully fast protocol
if the vocoder is not open source and if so how do you do it? Well, 2001 was, sorry to break it to
you, but quite a few years ago. So solution came in 2010. Name is Kodak2.
Release in 2010 by David Roe. I want to underline that this was not an easy task. It was the topic
of a full PhD thesis. It self-relying on old works and algorithms and so on. So nobody woke up
in the morning and said, hey, let's do an open source vocoder. It's going to be easy.
That's not how it goes. It's fully open source, no patents, no industrial secrets. That's the point.
And since 2001, computing power on the microcontrollers increased by quite a lot. I mean,
8-bit peaks and 32-bits are microcontrollers are not the same thing.
So this last brick, which was kind of the missing brick to have open source, fully open source
protocols, allowed to the emergence of two main protocols. The first one is FreeDV, which is designed
by the same David Roe. He's not alone, but he is one of the contributors of FreeDV, licensed under
GPLV 2.1, using Kodak2 at lower bit rates because it's in HF, so low frequencies, narrow bandwidth.
You can't transmit a lot of bits. So you just slow it down. You degrade the voice a bit more,
but then you're able to do long range digital voice communications. And it's also used as the
reference Kodak2 implementation. So again, just like I said about FT4, FT5 a few slides ago,
you do something and then you provide your own implementation, except that this one is open source.
And then KM17, GPLV 2 uses Kodak2 at the highest bit rate available.
It fits in a standard FM bandwidth for VHF and up, so you can't really use that in HF. It's
a bit too wide. You are going to annoy a few people published in 2019.
So, M17 protocol has all the features you could expect from a digital protocol in amateur radio,
which is that you have the packet mode, so you can use it to control a remote site, for example,
using just sending commands. You have a stream mode, which is the mode which is used when you
use digital voice. It supports AES encryption, which depending on where you live, you might or
might not use it. I know I can't. It does have also the specifications for traffic over IP,
which I think is a good thing. If you look back, main digital voice protocols do not have that. So,
the community will kind of go, each one has its own way of doing it and different implementations,
and then somebody comes, hey, I have an idea. Let's try to inter-connect this, and it's just
one more break to a very tall and fragile wall. So, here we provide specifications for this,
which I think will ease up, does ease up implementation and inter-operation. If you
probably know about DMR, to use DMR, you need DMR ID, which is centralized. We don't. In this protocol,
you only need a call sign, which if you can use the protocol, you most probably already have a call
sign, so problem solved. And the specifications are open source and license under GPLv2, which means
that if some big manufacturer says, hey, I like this new protocol, let's try to benefit from it,
yeah, great. But if you modify it to make it incompatible with our specifications,
we will force you to publish your specifications completely, and we will find a way to make sure
that whatever we do next is going to be compatible with you. If you don't want to be compatible with
us, we will be compatible with you. Okay, so this was the M17 protocol, but we should go beyond that.
There is the whole M17 project thing. More than a protocol, getting rid of the proprietary
vocoder allows a load of things. First thing is you can have it running on your computer.
You don't have to pay for any license fee. You don't have to have any USB dongle that you have to
plug into your computer so that my software has to go through the proprietary chip that you used,
blah, blah, blah, blah. You can have software on your computer for Dstar, for example, but you need
this USB key on your computer to have the license to use the codec. You can have it on your phone.
Same thing, DroidStar, maybe some of you know about it, maybe not yet. This is a very small
app that allows you to use digital voice protocols and connect through reflectors, so servers.
M17 allows it to run straight out of the box. AMBE codec, there are online implementations,
illegal implementations that allows you to use AMBE, but you have to find it, download it,
and then it becomes very shady and it's a cat and mouse game between DVSI and amateur radio
operators. You can have it for your radio, a lot about that in just 10 minutes, apparently.
You can have it on reflectors. Dstar reflectors do need the same USB key that you would need on
your computer to translate the voice between AMBE and whatever else you would use. Maybe a small note
that if you have a Dstar reflector, which is from Dstar to Dstar, you do not need this key because
you do not need to decode the voice and re-encode it. You can just pass the encoded bits around,
but if you want to switch from something to something else, then you're stuck.
So yeah, it's a whole ecosystem which was able to grow from the ground up because of
the open sourceness of codec 2, including in this ecosystem module 17,
so which is this board which is open source hardware, open source software, open source protocol,
open source, almost everything you can wish for. Let me go in the frame of the camera maybe.
So you have the board here which is the newest revision 0.99 because you never do the 1.0 in one
go. And then the enclosure that goes around with it because having this on your computer is screaming
for I want short circuit as soon as possible, so let's try to avoid it and put it in an enclosure.
Difficult thing is yeah, when you have open source hardware making money out of it is difficult,
but this exercise is intentionally left to the reader. Yeah, fully open source, affordable.
50 euros about that. Try to find digital voice, modem, TNC, whatever for that price. I think you
will come back to us. Open HD, another baby which is on its way not as advanced as module 17 yet,
but it's aimed at being a fully open source portable radio. Basically if you can modulate it,
we can send it. For now it's only working on the 70 centimeters band, 430 megahertz,
and the 2.4 gigahertz. So for those of you who can see Qo100 in the sky, it does the upstream to Qo100.
25 milliwatts. Hey, it's a prototype. Step by step please. With its 3D printed enclosure also open
source and very quickly it relies on a deaf board developed by ST Microelectronics and the backside
we did ourselves with the power supply, the FPGA, and the transceiver. FPGA, so you can see maybe a
few asterisks on the screen. The FPGA tool chain is sadly not open source. You know maybe if you
play with that that having open source FPGA is difficult. It is one of our goals, but usually
they will provide IPs in their software and then say yeah, if you want to exploit it commercially,
please talk to us before that. So always a bit difficult to deal with that. We have plans for
the future though. We are starting the work to port it over OpenRTX, which you will know about in
six minutes and a half. We want an open source FPGA, so quick note that maybe the FPGA is not
open source, but it does not prevent you from building it yourself. Downloading the software
which is free as in beer and you can rebuild the bitstream and upload it to the radio. So
you can still tinker with it however you want, but it's not strictly speaking open source.
We want five watt output. We want USB-C charging. Oh my god, I come here, please.
So yeah, we have plans. We are not only pushing our protocol in it, but we just want to make
products better and open source for the community. I think there is a big hole in
the ham radio community with this and we are here to fill it. A very quick shout out to some very
interesting projects close to M17, the open source primary code OpenRTX. WPSD, which is the hot spot
software that you can use which supports M17 for, I don't know, a few years, a few months back,
they started support, contrary to PyStar which supports M17 for, I don't know, 10 days.
MMDVM, the hot spot hardware. So we rely on those to have hot spots which do M17 and there are
much, much, much, much more things that revolve around this. Okay, so thank you for your attention.
I hope you liked it. I hope it gave you some ideas and desire to join us, help us. We need
devs, please. I know everybody does need devs. Check out our infobooth, ham radio infobooth in
building AWU, but I think most of you already came and say hello, but if you did not, we are still
here today. Okay, thank you very much, guys.
Thank you.
We have some time for questions.
Yeah.
For FSK with root-raised cosine filtering.
So the the main chip that you would use is CC1200 from Texas Instruments.
Yep.
Using the packet radio port. Just like you would do for AX25, for example, your old TNC.
So this module basically takes the sound from the microphone, processes it, encodes it using the
Kodak 2 vocoder, does the protocol framing, baseband creation and processing and filtering.
You have baseband output here, feed it to your radio, and then the output is for FSK modulation
with 4M modules, for M17 protocol.
But if you want more, come to our infobooth. Yeah.
What FPGA type radio is in the chipboard?
For now it's the latest, I forgot the one. It's not an i40 which has an open source toolchain
available. We had some technical issues, we had some technical issues with the FPGA, so the one we
use, yeah, is LATIS, CERTUS, something, I guess, but because for the transceiver we use, we needed
LVDS pairs for the data transmission.
64 MHz for the LVDS pair speed.
Yep.
You have been addressing some of the shortcomings of all the other
modulation schemes and protocols, so letting aside that they are not all open source,
but they have other shortcomings like on UHF, there's reflection and there's fading and many
other things that you are experiencing outside the lab. Actually, are you also addressing these
things with M17? I mean, is there a better quality of voice? Is there a better cope with
fading and reflections and things like that?
Okay, yeah, there are shortcomings indeed with many digital voice protocols.
We are between a rock and a hard place. We use for-office-scale modulation scheme which
basically does not allow you to overcome the multi-path problems, reflections and so on,
so we are aware of this. We have to go step by step maybe. Specifications are open, you are free to
fork them and I don't know, implement it in OFDM to avoid some problems that you might have with
specific issues which is linked to the physical layer. And for the voice quality, some will say
that Kodek 2 sounds better than AMBE, some will say that it's worse. It depends, really,
but I think it's at least on par with the other protocols.
Yeah?
So that's a nice thing. For the Internet use cage of UHF, have you curves or measurements that say
what isn't that as an R? I can still do whatever analog voice versus M17 and how much further
can you get with like bursts?
Yeah, so this basically boils down to, yeah, do we have any graphs, lines,
explaining basically the difference between analog and digital? Well, this is a wider topic than just
M17, but I agree that maybe having those comparisons might be a good idea to push force into those modes.
But no, we don't have those curves at the moment, I believe.
Many people I think could have, but yeah.
Absolutely, question if I can. Yeah.
Have you thought about interfacing that or, and I know I'm on your description, so I'm asking you
to because one of the things I like as to experiment is that you can put other data on your channel,
but on the current hardware you cannot interface with it.
Okay, so can we send arbitrary data using module 17?
Not yet. Everything is there for you to be able to do it. So the final net is openRTX.
There is a USB-C port with data lines connected to the chip, so we use it for final updates.
We use it for STDIO output for debugging basically, and yeah, you should be able,
in the future it is planned, but Sylvano in a few minutes will talk about that, having
communication channel between the computer and the board, and then from there you can send
basically whatever you want. So yeah, it is feasible.
Yeah.
Have any large manufacturers shown interest in M17? Yes.
We talked about, we talked with Kenwood, which would be interested in implementing M17,
so I pinpoint back to the fact that specifications are licensed, GPLv2, so they cannot lock it down
for their own use. We also have connect systems which showed an interest in our radios and Bowfing.
With no more questions, and I see no hands rising. Big thank you again. Thank you very much.