23 Aug 2022
See https://openrtx.org to support OpenRTX
see @M17 Project to find M17's videos.
see @M17 Project to find M17's videos.
- 5 participants
- 4 minutes
5 Aug 2022
The modifications mentioned at the end of Part 3 to @M17 Project VHF/UHF narrowband have been completed. A 16kbps OPUS codec has been integrated. A variety of other changes to parameterize the codebase for increased utility and flexibility for space and terrestrial microwave band use have been made.
A channel impairment block added to the GNU Radio flow-graph. This is an over-the-air demonstration of a transmitter and receiver for Opulent Voice at 905 MHz, with the baseline16kbps OPUS codec integrated.
Flow-graphs and information about the simulators can be found here: https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
More information about Opulent Voice can be found here:
https://www.openresearch.institute/2022/07/30/opulent-voice-digital-voice-and-data-protocol-update/
Thank you to all who support the work.
A channel impairment block added to the GNU Radio flow-graph. This is an over-the-air demonstration of a transmitter and receiver for Opulent Voice at 905 MHz, with the baseline16kbps OPUS codec integrated.
Flow-graphs and information about the simulators can be found here: https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
More information about Opulent Voice can be found here:
https://www.openresearch.institute/2022/07/30/opulent-voice-digital-voice-and-data-protocol-update/
Thank you to all who support the work.
- 2 participants
- 6 minutes
28 May 2022
Walks through the creation of a Phase 4 uplink simulator using M17 signals in an FDMA scheme. Details at https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
- 2 participants
- 5 minutes
26 May 2022
Walks through the creation of a Phase 4 uplink simulator using M17 as the signals in the FDMA scheme.
Details at https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
Details at https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
- 9 participants
- 2 minutes
26 May 2022
Walks through the creation of a Phase 4 uplink simulator using M17 signals in an FDMA scheme. Details at https://github.com/phase4ground/documents/tree/master/Engineering/Uplink%20Modem/Simulator
- 3 participants
- 3 minutes
6 May 2022
Paul KB5MU demonstrates the M17 transmit modulation from a TYT MD-380 handheld transceiver modified with open source OpenRTX firmware. Versions from April 30 and May 5, 2022, are compared.
Both versions display an anomaly during the first few seconds of the first transmission after powerup. This anomaly is clearly seen on a Rigol RSA5065A spectrum analyzer.
The Rigol instrument also has a Vector Signal Analyzer mode, which displays a one-dimensional constellation diagram for M17's 4FSK modulation. This analysis clearly shows that the April 30 firmware version produces inadequate frequency deviation, about one-third of nominal. The May 5 firmware version corrects this problem.
The VSA analysis also shows that the signal from the May 5 version is not as clean as it might be. A signal from a reference GNU Radio flow graph is shown for comparison. The reference signal has much more precise modulation of the four nominal tones. This may point to a further issue with the OpenRTX firmware, or a limitation of the MD-380 hardware, or perhaps a weakness in the test procedure due to the much stronger signal from the MD-380 as compared to the ADALM Pluto SDR used to transmit the reference signal.
OpenRTX: https://openrtx.org
OpenRTX firmware for M17 on MD-380: https://github.com/OpenRTX/OpenRTX/
Hardware modifications required for OpenRTX on MD-380: https://openrtx.org/#/md380_mods
M17 Project: https://m17project.org
Open Research Institute: https://m17project.org
Both versions display an anomaly during the first few seconds of the first transmission after powerup. This anomaly is clearly seen on a Rigol RSA5065A spectrum analyzer.
The Rigol instrument also has a Vector Signal Analyzer mode, which displays a one-dimensional constellation diagram for M17's 4FSK modulation. This analysis clearly shows that the April 30 firmware version produces inadequate frequency deviation, about one-third of nominal. The May 5 firmware version corrects this problem.
The VSA analysis also shows that the signal from the May 5 version is not as clean as it might be. A signal from a reference GNU Radio flow graph is shown for comparison. The reference signal has much more precise modulation of the four nominal tones. This may point to a further issue with the OpenRTX firmware, or a limitation of the MD-380 hardware, or perhaps a weakness in the test procedure due to the much stronger signal from the MD-380 as compared to the ADALM Pluto SDR used to transmit the reference signal.
OpenRTX: https://openrtx.org
OpenRTX firmware for M17 on MD-380: https://github.com/OpenRTX/OpenRTX/
Hardware modifications required for OpenRTX on MD-380: https://openrtx.org/#/md380_mods
M17 Project: https://m17project.org
Open Research Institute: https://m17project.org
- 1 participant
- 3 minutes
17 Mar 2022
Welcome to Practical Open Source Engineering: International Standardization and the M17 Protocol. My name is Michelle Thompson and I'm your host for today. Thank you for being here.
Practical Open Source Engineering is a series of talks from the San Diego Chapter of Information Theory Society of the Institute of Electrical and Electronics Engineers, or IEEE for short. IEEE is the world's largest professional engineering society.
Open Research Institute, a non-profit dedicated to open source research and development of digital radio in all aspects, is the co-sponsor of the Practical Open Source Engineering series and is the fiscal sponsor of the M17 Project. To learn more about ORI's work, please visit openresearch.institute on the web.
M17 project development is the subject of today's talk. To find out more about M17, please visit m17project.org
Technologies do not grow and mature in isolation. To maximize utilization, organizations often turn to ecosystems of partners to drive collaboration and integration of these technologies. One structured and proven way of establishing such an ecosystem is via standardization. Standards provide vehicles to establish best-practices and define interfaces for compliance, allowing users to have confidence that the products they employ are safe, reliable, and are of good quality.
M17 Project has developed a new digital radio protocol for data and voice, made by and for amateur radio operators.
The protocol's voice mode uses the free and open Codec 2 voice encoder. This means there are no patents, no royalties, and no licensing or legal barriers to scratch-building your own radio or modifying one you already own.
This freedom to build, understand, and innovate is core to amateur radio, but has been missing from the commercially available digital voice modes. This is part of why amateur radio digital voice modes have largely stagnated since the 1990s and we're almost wholly dependent on commercial products that aren't well designed for amateur radio users.
Protocol specification can be found here: https://spec.m17project.org/
Erin Bournival is a Distinguished Engineer from the Office of the Corporate CTO at Dell Technologies.
She is an experienced Technologist with a demonstrated history of working in the Information Technology industry. Skilled in system architecture, Virtualization, Storage, the Internet of Things, Digital Twin, and National/International Standards development, Erin illuminates the process of international standardization for a promising open source communications protocol called M17.
Please welcome our speaker.
Practical Open Source Engineering is a series of talks from the San Diego Chapter of Information Theory Society of the Institute of Electrical and Electronics Engineers, or IEEE for short. IEEE is the world's largest professional engineering society.
Open Research Institute, a non-profit dedicated to open source research and development of digital radio in all aspects, is the co-sponsor of the Practical Open Source Engineering series and is the fiscal sponsor of the M17 Project. To learn more about ORI's work, please visit openresearch.institute on the web.
M17 project development is the subject of today's talk. To find out more about M17, please visit m17project.org
Technologies do not grow and mature in isolation. To maximize utilization, organizations often turn to ecosystems of partners to drive collaboration and integration of these technologies. One structured and proven way of establishing such an ecosystem is via standardization. Standards provide vehicles to establish best-practices and define interfaces for compliance, allowing users to have confidence that the products they employ are safe, reliable, and are of good quality.
M17 Project has developed a new digital radio protocol for data and voice, made by and for amateur radio operators.
The protocol's voice mode uses the free and open Codec 2 voice encoder. This means there are no patents, no royalties, and no licensing or legal barriers to scratch-building your own radio or modifying one you already own.
This freedom to build, understand, and innovate is core to amateur radio, but has been missing from the commercially available digital voice modes. This is part of why amateur radio digital voice modes have largely stagnated since the 1990s and we're almost wholly dependent on commercial products that aren't well designed for amateur radio users.
Protocol specification can be found here: https://spec.m17project.org/
Erin Bournival is a Distinguished Engineer from the Office of the Corporate CTO at Dell Technologies.
She is an experienced Technologist with a demonstrated history of working in the Information Technology industry. Skilled in system architecture, Virtualization, Storage, the Internet of Things, Digital Twin, and National/International Standards development, Erin illuminates the process of international standardization for a promising open source communications protocol called M17.
Please welcome our speaker.
- 2 participants
- 19 minutes
5 Feb 2022
Jump to:
M17 - CODEC2 work https://youtu.be/dou6hyj7SIc?t=86
M17 - Beyond RRCs https://youtu.be/dou6hyj7SIc?t=2263
M17 - Module 17 https://youtu.be/dou6hyj7SIc?t=2580
OpenRTX - RC-1 Board https://youtu.be/dou6hyj7SIc?t=2766
P4DX - End to End Demo progress https://youtu.be/dou6hyj7SIc?t=4677
Remote Labs - Polar Codes with MATLAB workflow https://youtu.be/dou6hyj7SIc?t=7306
M17 - CODEC2 work https://youtu.be/dou6hyj7SIc?t=86
M17 - Beyond RRCs https://youtu.be/dou6hyj7SIc?t=2263
M17 - Module 17 https://youtu.be/dou6hyj7SIc?t=2580
OpenRTX - RC-1 Board https://youtu.be/dou6hyj7SIc?t=2766
P4DX - End to End Demo progress https://youtu.be/dou6hyj7SIc?t=4677
Remote Labs - Polar Codes with MATLAB workflow https://youtu.be/dou6hyj7SIc?t=7306
- 11 participants
- 2:18 hours
2 Sep 2020
Specification of M17:
https://spec.m17project.org/
P4DX architecture document:
https://github.com/phase4ground/documents/blob/master/Engineering/Requirements/Architecture/20200902-AREx-System-Architecture.pdf
M17 is P4DX native digital uplink protocol.
There are at least three use cases of M17.
One, 9600 bps voice for VHF/UHF.
Two, the idea of 9600 bps data or packet mode, also VHF/UHF.
Three, higher bitrate mode for microwave.
There is a data type specifier in the current specification. Reserved protocol types are RAW, AX.25, APRS, 6LoWPAN, IPv4, SMS, and Winlink.
What we're talking about today is what, if anything, needs to be added to the specification in order to enable high bitrate operation for microwave, and also to figure out if anything needs to be done for IP over M17 or M17 over IP.
From Slack:
Ron
What needs to be defined is how to do IP over M17. In the M17 specification, there's a protocol identifier for IPv4, but that's it.
And here is a review of the conversation from 2021. This was the starting point for the conversation in this video recording.
Ron
M17 supports IPv4, but I'm not exactly sure how. The M17 specification seems pretty vague on that particular point
Howie
Assume we consider M17 stream mode operating in an FDM manner with a receiver for each uplink channel. Each channel can be given a GSE label that could map to an uplink center freq. The 4FSK modulated data is demodulated but not decoded. Instead, the data streams are clocked into individual buffers and used to generate the GRE frames. The idea is to keep the M17 frames intact so that on the ground earth station the demodulated data is identical to the uplinked frame which can be processed by the existing M17 decoder software. You listen to a channel by selecting the label for the stream you want to listen to. The limiting factor becomes how fast you can assemble the uplink channels into GRE frames.
I don't think there is any need or desire to use anything other than native M17 on the uplink. While GSE is normally used for IP transport I think we could put the M17 frames into the GSE data field. At that point the only overhead is on the downlink with the addition of the GSE headers and LSF management. I have not looked closely at the sizes of the required fields are or how much processing it would take to multiplex multiple uplink streams into a composite downlink. At this point I am just brainstorming.
Anshul
looks like we don't need IP as an intermediate step. I agree with @ab2s that there is no need to use anything other than native M17 on the uplink. GSE should encapsulate M17 frames and produce BBFRAME as it normally does for IP packet.
It implies we will be not using any IP stream/packets on uplink. Everything uplink will be M17 based.
Do you see any concerns here . Else, I will proceed with implementation of GSE block in firmware keeping this decision in mind.
https://spec.m17project.org/
P4DX architecture document:
https://github.com/phase4ground/documents/blob/master/Engineering/Requirements/Architecture/20200902-AREx-System-Architecture.pdf
M17 is P4DX native digital uplink protocol.
There are at least three use cases of M17.
One, 9600 bps voice for VHF/UHF.
Two, the idea of 9600 bps data or packet mode, also VHF/UHF.
Three, higher bitrate mode for microwave.
There is a data type specifier in the current specification. Reserved protocol types are RAW, AX.25, APRS, 6LoWPAN, IPv4, SMS, and Winlink.
What we're talking about today is what, if anything, needs to be added to the specification in order to enable high bitrate operation for microwave, and also to figure out if anything needs to be done for IP over M17 or M17 over IP.
From Slack:
Ron
What needs to be defined is how to do IP over M17. In the M17 specification, there's a protocol identifier for IPv4, but that's it.
And here is a review of the conversation from 2021. This was the starting point for the conversation in this video recording.
Ron
M17 supports IPv4, but I'm not exactly sure how. The M17 specification seems pretty vague on that particular point
Howie
Assume we consider M17 stream mode operating in an FDM manner with a receiver for each uplink channel. Each channel can be given a GSE label that could map to an uplink center freq. The 4FSK modulated data is demodulated but not decoded. Instead, the data streams are clocked into individual buffers and used to generate the GRE frames. The idea is to keep the M17 frames intact so that on the ground earth station the demodulated data is identical to the uplinked frame which can be processed by the existing M17 decoder software. You listen to a channel by selecting the label for the stream you want to listen to. The limiting factor becomes how fast you can assemble the uplink channels into GRE frames.
I don't think there is any need or desire to use anything other than native M17 on the uplink. While GSE is normally used for IP transport I think we could put the M17 frames into the GSE data field. At that point the only overhead is on the downlink with the addition of the GSE headers and LSF management. I have not looked closely at the sizes of the required fields are or how much processing it would take to multiplex multiple uplink streams into a composite downlink. At this point I am just brainstorming.
Anshul
looks like we don't need IP as an intermediate step. I agree with @ab2s that there is no need to use anything other than native M17 on the uplink. GSE should encapsulate M17 frames and produce BBFRAME as it normally does for IP packet.
It implies we will be not using any IP stream/packets on uplink. Everything uplink will be M17 based.
Do you see any concerns here . Else, I will proceed with implementation of GSE block in firmware keeping this decision in mind.
- 5 participants
- 1:13 hours
