Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 248
» Latest member: Zdam09
» Forum threads: 85
» Forum posts: 593

Full Statistics

Online Users
There are currently 33 online users.
» 0 Member(s) | 32 Guest(s)

Latest Threads
Re-use of NONCE space
Forum: Technical
Last Post: tarxvf
05-08-2021, 07:40 PM
» Replies: 11
» Views: 388
USRP2M17 make error
Forum: General discussion
Last Post: G0VGS
05-08-2021, 10:57 AM
» Replies: 0
» Views: 33
new version of mvoice
Forum: General discussion
Last Post: G0VGS
05-07-2021, 11:32 AM
» Replies: 20
» Views: 3,503
Audio quality initial rea...
Forum: General discussion
Last Post: G0VGS
05-05-2021, 06:21 AM
» Replies: 2
» Views: 108
register reflector M17-EA...
Forum: Reflectors
Last Post: on6dp
04-28-2021, 11:17 PM
» Replies: 2
» Views: 711
How to turn an old Motoro...
Forum: Technical
Last Post: md
04-26-2021, 10:24 PM
» Replies: 4
» Views: 770
Use of the DST field with...
Forum: Technical
Last Post: G4KLX
04-19-2021, 10:22 PM
» Replies: 0
» Views: 82
USRP2M17 added to MMDVM_C...
Forum: Technical
Last Post: N4IRS
04-11-2021, 02:02 PM
» Replies: 1
» Views: 241
M17 Protocol Proposals
Forum: Technical
Last Post: G4KLX
04-05-2021, 03:53 PM
» Replies: 7
» Views: 442
TR-9 RF power amp and low...
Forum: Technical
Last Post: SP5WWP
04-01-2021, 09:02 AM
» Replies: 2
» Views: 506

  KISS Protocol
Posted by: WX9O - 12-23-2020, 05:50 PM - Forum: Technical - Replies (4)

I am starting to document an implementation of M17 over KISS.  This entails using a KISS TNC (modem) for M17 baseband modulation and demodulation.

This is very much a work in progress at the moment, and major design decisions are still to be worked out.

Please refer to the KISS protocol documentation here: http://www.ax25.net/kiss.aspx

We will discuss both audio streaming mode and packet mode.

There are a number of design trade-offs.  KISS is an acronym for "Keep it simple, stupid."  And it's hallmark is that very little protocol work is actually done in the KISS TNC.  Only layer 1 (physical layer, baseband modulation) and layer 2 (HDLC framing and CSMA) is typically done in a KISS TNC.  The packet, typically an AX.25 packet, is sent over a SLIP-encoded channel with a 1-byte header.  The lower nibble of the header defines the KISS data frame type.  A data frame is represented by frame type 0.  There are 5 control frames defined.

The upper nibble of the header byte defines the modem identifier for systems with multiple modems.  The default is 0.  We can consider different M17 interfaces as distinct modems in a KISS TNC implementation.

M17 is a bit more complex than AX.25 over AFSK or FSK using HDLC framing.  M17 defines 3 frame types (link setup, stream, packet), and the stream frame contains two data channels, the LICH and the payload (possibly 3 channels if you consider V/D mode).  The data link layer requires both a source and destination identifier.  The first issue we run into is that KISS modems handle the physical and data link layer, and there is no protocol defined for setting things like source, destination or, should it be used, encryption nonce.

We are going to define three (3) modem types.  Two for packet and one for streaming.  We are also going to define extended KISS commands for setting source, destination and nonce.


In order to provide the most backwards-compatible implementation, packet mode using TNC identifier 0 will send packets with the source identifier set to a device type identifier, similar to the APRS TOCALL identifier.  The destination address is "M17PACKET".  Packet type 0, RAW, will be used for the packet payload.  The TNC will be responsible for constructing the packet frame, attaching the type field and computing the CRC.  It is also responsible for unwrapping received packet frames, dropping packets with invalid CRCs and passing received raw data back to the host, discarding the packet type identifier and CRC.

The goal of this mode is that all applications that currently function with KISS TNCs can use M17 as the physical and link layer.  Station identification must be done inside the payload, such as with an AX.25 MYCALL identifier.


For M17 modems, modem identifier 1 is the full-featured M17 packet interface.  It expect to receive a single frame of data containing a 30-byte link setup frame followed immediately by a 3-800-byte payload.  The payload includes the type field and CRC. It returns the same data to the host when packet data is received.


Modem identifier 2 is the M17 stream interface.  It expects to receive a single 30-byte LSF frame, followed by a series of 20-byte data frames.  The last frame in the sequence must have the end-of-stream bit set.

Received stream packets are sent to the host in the same manner.  The TNC must provide a packet every 40ms.  The host must be able to handle missing/dropped packets or streams that end without an EOS bit set, possibly due to loss of signal mid-stream.  [This needs to be more fully fleshed out.]

The LSF is 30 bytes.
Stream data is 20 bytes (FN, payload, CRC).

For host to TNC:

In streaming mode, the TNC receives a single 30-byte LSF payload.
It verifies that the CRC is correct and that the packet/stream bit indicates "STREAM".
It starts transmitting the preamble, then LSF.
The host sends 20-byte data frames containing Codec2 audio payload, frame number and CRC.
The TNC checks the FN for the end-of-stream indicator, and optionally checking the CRC.
The TNC will have a backlog of up to 2 frames of audio data, collected while sending the preamble and LSF.
The TNC can insert up to 2 frames with empty payload data (and proper CRC) if the stream is interrupted. (What to do with FN?)
The TNC will end the stream if 3 or more frames have been missed.  It will end the stream by sending an empty payload with the EOS bit set.


For packet mode, the TNC will receive a 33-830 byte packet containing LSF and packet payload.
It will send the preamble, LSF and split the packet into frames.

For TNC to host:

For packet mode, the TNC will capture the LSF and payload.
It will verify the CRC on both the LSF and the payload.
By default, the full-featured M17 packet modems (id 2) should operate in PASSALL mode, allowing the host to drop packets with bad checksums.

Print this item

  PTT & OTA Requirements
Posted by: WX9O - 12-23-2020, 04:18 AM - Forum: Technical - Replies (1)

This is regarding the OTA protocol.

When PTT is keyed, what are the requirements?

What is required to happen if PTT is released while the preamble is being sent?

What is required to happen if PTT is released while the link setup frame is being sent?

What is the expected behavior when PTT is released while an audio stream is in progress?  Are there any requirements for how quickly the radio must stop transmitting?

Print this item

  new mrefd release 0.3.5
Posted by: n7tae - 12-22-2020, 03:53 AM - Forum: Reflectors - Replies (2)

This is not a critical update. 0.3.5 will allow multiple clients with the same IP and callsign to link as long as their connection ports are different.

Both mvoice and DudeStar use ephemeral ports making this possible. There is a very small chance (~1 in 10^4) that a subsequent client might try to connect on the same port as an existing client. If this happens, it will be refused. The solution is simply to restart the client so that it will choose another ephemeral port. This feature is configurable, so after you do a "git pull", be sure to rewrite your configuration file using "./rconfig".

This release also keeps its list of peers in alphabetical order, so the dashboard peers table will also be alphabetized.

Print this item

  An M17 gateway to HF
Posted by: alanVK2ZIW - 12-09-2020, 09:40 PM - Forum: General discussion - Replies (1)

Many country areas are not covered by VHF/UHF repeaters, can HF be made useful?

Our Australian emergency services are required by law to have an independent communication system.
So our country ambulance service vehicles and their bases have been fitted with HF radios and are going to
use the TWELP © digital modes.

In the FreeDV project, there are two apps and a stand-alone box to interface to one's HF radio. 
1) The FreeDV GUI app, PC and MAC.
2) The FreeBeacon reverse beacon
3) The SM1000 stand-alone interface box

But with so few amateurs using any of these, there's rarely anybody to talk too.
What's more, doing search and rescue, HF in vehicles is  easy on 40m and 20m
but if the HF conditions put one's signal 1000Km away, how does one  contact the
in town HQ. This is where a network of HF base stations comes to play. (as in my ambulance example)

I'm not a C or C++ guru programmer, so this is my approach (on Linux):
"connect" modified FreeBeacon (cnode.c) to "mvoice" via the loopback pseudo devices.
Pass PTT too and fro via semaphores.

Any thoughts?

Print this item

  packet data format
Posted by: ah-huh - 12-04-2020, 12:33 PM - Forum: Technical - Replies (2)


The format of the M17 protocol packet data communication is undefined?
I will implement short messages client on M17.

Print this item

  M17 Reflectors Open Alpha
Posted by: KC1AWV - 11-28-2020, 06:21 PM - Forum: Reflectors - Replies (6)

In order to separate tasks and duties, a new M17 Reflector and Group registration system is available and open for open alpha testing.

M17 Reflectors

Using the alpha M17 Reflectors system, you can self-register and update your reflector information. You will need to register your reflector yourself on the new alpha system, the records from the old list and the new one are incompatible.

Registering your reflector requires the following information:

  • Designator - This is the 3 characters after the M17- that identifies your reflector, i.e. USA, or BRO
  • Dashboard URL - This is the address for your reflector dashboard. This must start with https://
  • IPv4 - The public IPv4 address to your reflector
  • IPv6 - The public IPv6 address to your reflector (optional)
  • Port - The UDP port your reflector is listening on (generally 17000 unless you've changed it)
  • Sponsor - The sponsoring amateur radio station or club
  • Country - The country served by the reflector

Once your reflector is added, it will be in a Pending state until reviewed by a Reflector Admin. Once approved, the status will change to Published and cannot be accidentally deleted. You can change the status to Deleted and remove the reflector yourself if needed.

Features to be added:
  • Group Registration
  • Email reflector and group admins on new registrations
  • Reflector and Group list API (to generate host files)
Questions, comments, and ideas can be sent here as a reply to this thread.

Steve KC1AWV

Print this item

  new version of mvoice
Posted by: n7tae - 11-19-2020, 05:40 PM - Forum: General discussion - Replies (20)

A new version of mvoice (201118) is available. It's now easier than ever to connect to an M17 reflector. Start mvoice with "./start-mvoice" from your build directory and this script will download the latest connection information about all registered M17 reflectors. Select a reflector from the drop down list, select a module and link and you are connected. Once you've selected a registered reflector, use the "Open Dashboard" button to see its dashboard.

Depending on how you set up your system, you can still start movice with "./mvoice" or "bin/mvoice" or simply "mvoice" if you don't need to update your registered reflectors list.

If you've selected IPv6-only operation, your drop down list will only contain those registered reflectors that support IPv6. There are only two currently, M17-M17 and M17-USA.

The format for saved destinations has been changed and so mvoice now uses a different file, ~/etc/M17Hosts.cfg. The downloaded registered M17 reflectors are in ~/etc/M17Hosts.csv. (Thanks to the dudestar guy for this!) Your previously saved Destination callsigns/IPs are still in the original file, ~/etc/M17-destinations.cfg.

Several bugs with the settings dialog have been fixed.

If you already are using mvoice, go to your build directory and do "git pull" followed by "make install".

Print this item

Smile ORI sponsors the M17 Project
Posted by: EA7IYR - 11-17-2020, 11:15 AM - Forum: General discussion - No Replies

Open Research Institute is proud to formally sponsor M17, an open source digital radio protocol, code, voice codec, and hardware project. The designs and technology are highly useful for digital radio uplinks for a wide variety of amateur satellite projects. The project is dynamic, international, accessible, modern, and welcoming. Open Research Institute is a 501©(3) dedicated to open source research and development for the amateur radio satellite service and beyond. Find out more at https://openresearch.institute

Print this item

  TR-9 RF power amp and lowpass part
Posted by: SP5WWP - 11-14-2020, 03:42 PM - Forum: Technical - Replies (2)

I have a test setup comprised of an ADF7021 tied directly to a circuit shown below

[Image: E5KMytC.png]

The problem is that the power output is too low and the RF MOSFET gets hot pretty fast.
The frequency response of the lowpass part is far from being optimal. 2nd harmonic is at -10dBc. I have already proposed a change here: https://github.com/M17-Project/TR-9/issu...-727211097

http://www.elenota.pl/datasheet-pdf/1613...448ed59464 (page 10)

Print this item

  New mrefd release 0.3.4
Posted by: n7tae - 11-13-2020, 12:57 PM - Forum: Reflectors - No Replies

Mrefd 0.3.4 is available. This is an important release and everyone should upgrade.

This release more efficiently handles the whitelist, blacklist and interlink files. Any invalid entries in these files will be flagged with an error message and be ignored. If you want an open reflector, remove all entries in the whitelist file, including the "*" entry. An empty file means "all are welcome". If you are having trouble with a user on your reflector, add their callsign to the blacklist with a trailing "*". If they are currently logged in, their transmissions will be blocked. You will see this in the log. Once they log out, they will no longer be able to log in. All configuration files are case insensitive.

The C++ container used to internalize the mrefd.* configuration files have been changed to more efficient containers. the black and white list now use std::unordered_set and the interlink now uses std::unordered_map. These new containers are much more efficient and will save cpu cycles on your server, particularly so for the interlink data.

An important bug was corrected having to do with how streams are terminated.

Please upgrade your system at your earliest convenience.

Print this item