Hello everyone, so I'm Everest, my course, I need a 5-0-0.
I will show and demonstrate what we have done with Open Research Institute, so I'm part
of the team. I'm not the specialist of this project, but I will try to explain this in more
details. So it's about space and terrestrial communication, especially more than them.
So what is Open Voice? Well, it's an open source digital voice protocol. It's designed
to be a bandwidth constraint, and it could be used on terrestrial or satellite communication.
This project is done by a lot of people around the world.
Why we develop this kind of new modern? Well, there is no really high quality voice communication.
Because we mainly want to use the FCC or the spectrum radio spectrum on until UHF, we need
to be less than 25 kilohertz. So in this particular modem and modulation, we are above that,
we can have more quality with that. What's important is that it's free implementable protocol,
so it's completely open source. We have already demonstrated in summer 2025, and on the last meeting,
we have succeeded in transmitting over the air, voice and data. So who is Open Research
Institute? Well, it's an installation based in US, with volunteers, which are about, well,
all around the world. There is a lot of project on this foundation. In two years ago, I used
personally, DVBS2 FPG-RP, which allowed to, for example, to broadcast on Q100, which is a
geostation satellite, and while I use the IP, Open Source IP FPGA-DVBS2. So it could be DVBS2,
it could be, well, there is projects like AirF Bitbanger, which is more electronic cards,
but it could, the Open Research Institute also use regular regulatory works, so with the FCC in US.
You can find all the details on the link, which is there. So what this? Well, it built around
16 kilobits, Open Source Voice Core, and with this Open Source Core, we have a super
your voice quality compared to other. So the voice quality is good, and it can be mixed also
with data, so packet, imagine you can chat and send audio at the same time. Generally, we have
some packet protocol, and we have some audio protocol, and with this, with this, open protocol,
we can mix both. So above the voice quality, I don't have the samples here, but you can
reach them with this links. We compare audio quality of several codecs. There is a whole
presentation here on YouTube, please don't go there, because it's a spoiler, as the
presentation is quite same as this day. So then what's the architecture of this protocol?
Well, we need first a 40 minutes second fixed frame lens, why, but it's a back practice for
opus codec, in order to have low latency and quality and less overhead. In order to
moderate it, we use the minimum shift gain modulation. So as we have 16 kilobits
codec, we have now 45.2 bitrate, which is MSK sorry. So we have a toned separation of 27.1 kilobits.
So we have a nertonyl bandwidth constant envelope, so the main spectrum is between 21 kilobits.
Using this MSK is useful to filters and amplifiers, we don't need to have
really a linear amplifier like we use in QPSK, for example. So it's easier.
Now deep, a little more in the codec itself. So first, we need to have like a transport stream
in DVV. Here we have some baseman data frame, okay. And the interlocutor is the interface between
the humane and the baseman packet. So the interlocutor is written in Python and is getting all the
input, which is the audio, the chat and even from that as. And can then send and be received by
the other interlocutor. So there is two main cases. The first is quite easy, which is
I go from one to one just by EIP, okay. So imagine you just have two computers or two devices.
And with this baseman packet, you translate and receive, okay. Now we can also do that
through RF. And then at this time, we use the modem. So there is what the interlocutor look like,
well, it's a web-based interface or a common line. So you can easily chat and generate
audio just with mic. So how we, well, there is several cases to connect with the modem.
Well, the first one is, well, the simplex1, which say that, okay, we send the data frame,
the baseman data frame, going to the modem, and then going to a radio frequency in
MISK and then demodulated and going to the all the interlocutor setting. So for that, we have
to configure the IP address of the modem to reach the transmitter on the receiver.
Another case is like a band type or a transponder, satellite transponder. So instead of having
the radio frequency directly going from one point to another, we use a satellite, which is
a transponder. And then so this is the same case, but we use the transponder or the satellite
to go to the receiver. And there is also some more complicated example, but which is quite interesting.
Here, we use another satellite, which embedded a processing inside. So the processing
is receiving the operating voice protocol here on MISK. So the app link is on MISK, but the
don't link, instead of sending it in MISK, so the same baseman, we multiplex it here in DVB
has 2. DVB has 2 is a normally, well, a general satellite protocol, which could be used mainly
on video, well, it's the standard commercial protocol to send you all the videos.
But you can also send some IP data. So the idea here is that satellite is getting all the
maybe another slide like that. So the satellite received the MISK, demodulated,
then re-injected in a multiplex. So you have, you can have multiple claimed multiplex to the receiver
side. So for example, you can have some conference, which means that several anti-locutors send
the MISK or the opening voice app to the satellite, which demodulate and translate on DVB as 2.
Of course, this is received, all the participants receive the multiplex broadcast DVB as 2.
So how does all it work? How does all your text and data go out of interlocutors,
all the web interfaces is working? Well, you have here a microphone speaker keyboard,
terminal browser, and then you have, well, one, become a line, or the web interface.
As I told before, it's mainly based on Python scripts.
So this is the example of the web interface and just the common line, and you see that there is
a lot of common blocks on that. On the web browser, we use web circuit and going to the Python class,
and on the terminal one, we have already we have a direct transmission on that.
So here you can see more in data, and you can see that we can have some option of
transcription, for example with Whisper, to a voice, to a text transmission.
So this is on the received side of, well, it is the side,
instead of the here it is the transmit side, and here's the received side.
So a lot of components are in common. So what does an operating voice,
based on data? So here we are coming back to the baseband, we have developed in order to go to the
mode, okay? So the first one, so this is, there is several packet type, which is audio, text,
control, but a feature one is data, which is any data. First of all, the operating voice here,
as a station ID, which could be your call sign, for example, or a derived of the call sign.
You can have a notification token, which is not a military, but just if we need that in a
feature release. After that, we have a constant over a bit surfing, which means that here,
so on the payload. Why that? Because when we transmit data, we have variable length of data,
and this constant over a bit surfing can be used to keep track of all the data,
rear-sumble packets, and can also do some surfing in order to have a constant frame.
Because we have a constant frame format. So for example here, we have several
civil packets, and we can see that there is the cups at each start of packet, okay? Not on the
voice, but on the data. So now, we are on the audio side, okay? So we are 80 bytes of
office audio at each time. We use RTPA data, which is real-time protocol, which is there to have
the synchronization, and to see if we recreate a clock at the receiver side.
So the audio frame is the audio payload, and the office packet and the RTPA packet.
Sorry. So on the RTPA data, so we are going deeper and deeper on the protocol,
and on the RTPA, we have a hash of this station ID. We have a sequence number in order to
if we lose some packet, and we can then try to resumble to skip some synchronization.
The timestamp is increments normally every 40 milliseconds, so if we have
skip in timestamp, we know that we have lose some packets, and we have we have a failed type,
which is for now the office codec, but maybe in the future we can switch to another codec.
So now we are in text control message. So the payload is NUTF8F8Data's. The RTPA is not used, because
we use some data, and we don't have to synchronize all that. As the text control message
are variable lengths, it could be much longer than the frame, and then we use the cups
to resumble all that. The UDP data is in the internal port number, which we can
payload tip. So we use this to prioritize the incoming data, and we want that the voice
is priority to the control, and then the text and the data. So we use this UDP
either for that, and so we can prioritize all that. The UDP data is a source and destination
IP, and a protocol field. So there is a first tip of data defined to transport
any IP data. This is a future update. I think that we are developing right now.
So now we have as we have analyzed all the protocol, the baseband protocol, how
can we modulate and go into radio frequency? Well, we use civil stage before modulating in MSK.
First, there is a randomization process, which is a city SDS common LFS process, then there is a
forward error correction, then an interliver with 30 rows, a sync word insertion and sub-detection
in order to help to demodulate it. The MSK modulation is a design which has been
influenced by MSK outcomes. So when we get this process, so the frame is coming in, then we have
feeful and some plug domain crossing, then we run the mice and encode in VTRB, then have an
interliver, we add a sync word, and then we have the modulation king and the same on the
receive path. So what is the performance and the characteristic? Well, the cutting gain is about
5 dB from the VTRB decoder and we have 2 dB more because we have a soft decision.
The sync word performance is quite good and has a pick to side up to 1.1, which seems to be
optimal. The sync word detection has two three sold. We have one, when we try to hunting
the demodulation, when we have MSK, we have the radio frequency arriving and we first and
globally, to know how is some power rate and try to synchronize it. So we have first
three sold for the first hunting and then as soon as we have ants, then we have another
three sold to verify the sync word. For the latency, because it's important, the main
latency is under the device, which means that the modem latency is quite short, but right now this
is more the device, which is the PC, for example, which has 50 to 100 minutes of full frame.
You have OSD days, put a shown playback queue and on the receive side, it's the same. So it's
mainly some issue with the device. We can have less latency device, but right now we have
so around 100 minutes again. On the latency of the modem itself, well, we work with the
711.4 megats clock, which is the puto as they are maximum sample rate clock. So the
transmit is at the bond 63 microsecond. On the receive side, well, we need some data, so we
have, we need enough data to have a sub-decision of the VRB decoder. So it's about one
millisecond, which is very short compared to the interlocutor latency. There is an implementation
of the modem in C++, but we need to do that in each gear. Why? Because as soon as you have
developed something in each gear, you can create an AZIC. Outwear is also fast-efficient and compact,
so it's a good way to learn FPGA, which means that there is a lot of volunteers who learn
at the same time on this kind of project. So it could be FPGA, it could be software.
And why we use the amateur radio band? Well, because it's coordinates for the
space and it's non-commentsure and we can use sub-band. As soon as it is UHF, we can experiment on that.
Why MSK, not JMSK? We have a lot of even on satellite. We are not constrained by bandwidths,
really, as a commercial satellite, so we can have a little more bandwidth for MSK and we have
a better SNA on that. We have lower, well, the JMSK has lower side, side-lapse, but we don't really
need to pack a lot of channels. Why is 16 kilobits for code? Well, it's very good for security.
And going up is occupying more bandwidth and in the contrary, it's a minimum to have a good quality one.
Yeah, so we use Opus, but why not codec two, which is also an open source,
developed by an amateur radio hand guy. Well, the codec two is mainly focused on very low bit rate,
and so for amateur is more on the HF band instead of UHF, where you don't have a lot of bandwidth,
only 2.5 kilobits, bandwidths. Here it's another case, because we have plenty of bandwidths.
But this codec two is also very good. There is just several aspects and we can choose one on the other.
The important thing and what we want is mainly some quality on the audio.
So we try to have some benchmark on that, try to comparing with other, and there is several
it's not very easy to open as a comparison, but we try to do that.
So we use the Pictus Cycle Hub ratio comparison for the FEC comparison interleving comparison.
And so there is a lot of other metrics we can try to use.
It will be published in future work. So here you have the, the component, the, is it for each
codec, so open, open voice protocol and 17 p25, discharge the MR, and it's in, or use,
you, you use a fusion, and you can see that, yes, we want to be open source, and so only,
only few are good and especially for the vocal license,
because all of the other DVSI license.
And this is for the synchro lens, so 8.1 is quite good compared to the other.
I'm not especially on on this metrics, so I will, I give you all the, the comparison that
I'm not, I'm not very specialist on that, sorry.
Here you have a comparison with all the FEC, the code rate, et cetera, and we can see if we have
a FEC architecture, is a soft decision, which, which is, okay, to, well, the soft decision,
increase, well, increase the quality of the decoding also.
Here is the interior lever, so the interior lever is, to, you know, that to, on, if, if you have
an interference on the radio frequency, we want that if there is a burst on one, we don't
lose all the bits at the same time, so we try to spread it and enter it, enter it.
So there is several mechanics to do that, so we use 32 row here.
We are to find all this component, all these open tools, so you can have all the, this link on that.
You can, and as soon as you're interesting in this project or in other, you can get involved
with this link here on getting started, and we have weekly meeting with all the, all the projects.
Thank you.