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 41 online users.
» 0 Member(s) | 39 Guest(s)
Bing, Google

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

  A few notes about how to link reflectors
Posted by: n7tae - 11-10-2020, 09:08 PM - Forum: Reflectors - Replies (3)

Mrefd uses a mesh model of interlinking developed by the xlxd team. First of all, any particular connection has to be configured on both ends of the connection. We'll call a collection of interconnected reflectors a group. The smallest possible group contains  two reflectors. Once the link is established, clients on one reflector can hear and be heard from clients on the other reflector.

A group can share multiple modules. If they do, traffic on one of the shared modules will not be heard by clients linked to the other modules in that group. A reflector may participate in multiple groups, but any given module can only be in a single group. Once a module is assigned to a group, it should never be configured to be in another group.

With larger groups, each reflector in the group must link to every other reflector in the group. Consider a group of three reflectors, M17-001, -002 and -003. Each reflector needs two entries in its mrefd.interlink file pointing to the two other reflectors in the group. Traffic is managed in this more complex group by a "one hop" policy. This policy prevents "looping" that might arise in the the older styled "train-car" linking. Here is how mesh linking works:

When a client on one of the group modules sends a voice stream to its reflector, the reflector sends it to all its linked clients, including other linked reflectors. However, the voice stream directed to another reflector is marked with an extra byte. When the receiving reflector gets this voice stream, it can easily identify that it is from a reflector and not a normal client so it will only pass the stream to its normal clients, not to other reflectors in the group! A stream is only relayed one time within a group.

If a group is missing a link in one of the connections, all clients on the group may not be able to hear everyone else on the group. Let's say in the example above M17-003 hasn't yet got around to configuring the link to -002. In that case clients on -001 will hear everyone, but clients on -002 won't hear clients on -003 and vis versa. That can be very confusing for clients listening to the group module. Administrators can usually easily tell if something is wrong by monitoring the mrefd logs, "sudo journalctl -u mrefd -f". If a link is only configured on one side, both sides of the link will see the attempted link fail, over and over again. See the attached file for an illustration of a good and bad four-way group.

Administrators that want to join an established group need to communicate with all of the current group members. It's also a good idea for group members to occasionally look at the dashboards of each of their group reflectors to be sure there aren't "dangling" members connected somewhere on the group.

Attached Files
.pdf   M17Interlinking.pdf (Size: 11.15 KB / Downloads: 27)
Print this item

  register reflector M17-EA3
Posted by: ADER - 11-10-2020, 07:41 PM - Forum: Reflectors - Replies (2)

Please register this reflector:

Reflector Name : M17-EA3
url:  aderdigital.ddns.net/m17
IP6: none
The country: Spain
Sysop: EA3EIZ

Thank you, 73s

Print this item

  Voice FEC
Posted by: G4KLX - 11-10-2020, 11:42 AM - Forum: Technical - Replies (1)

This is something that I have been pondering.

Currently M17 uses a punctured convolution code for the audio segment of the transmission, this includes a checksum to check the integrity of the audio. This way you get all or nothing audio. However I think this will lead to sub optimal performance in weak signal conditions.

DVSI AMBE and IMBE use Golay (and Hamming) block coding, as well as some bits that have no FEC at all. This is important for a number of reasons. Firstly it means that you can easily get a BER value for the audio blocks. The codec used for DMR has rules put in place by DVSI that specify what BER is allowable on which FEC blocks before the audio is regarded as unrecoverable and should be silenced. This is why DMR (and NXDN and System Fusion DN mode) don't suffer from "R2D2" like D-Star whose codec has no such rules.

What it also says is that these codecs can stand a certain amount of corruption before the audio is regarded as unusable, and practical use of these codecs bears this out.

I am sure that the Codec2 codecs can also stand a certain amount of corruption before they are unusable. Maybe some bits don't even need FEC as their effect on the audio is minimal. Would it not be better to speak to the developer of the Codec2 and find out how the bits are organised and use targeted block FEC rather than the current all or nothing approach?

Even if the block FECs aren't as powerful as the convolution FEC in terms of bit errors, they would allow for decoding to lower signal strengths, allbeit with slightly corrupt audio. The human ear is a wonderful thing and shouldn't be underestimated.

You'd also gain 16-bits each frame because of the loss of the checksum :-)

Jonathan  G4KLX

Print this item

Lightbulb LICH Enhancements
Posted by: WX9O - 11-07-2020, 03:24 AM - Forum: Technical - Replies (5)

I have two proposals for the LICH.

1. Split the superframe into more segments

The current superframe (link setup frame) is split into 5 chunks of 48 bits (240 bits total).  I propose splitting this into 6 chunks of 40 bits each.  Use the first 8 bits in the LICH as an "info field" containing 3 bits for a superframe segment counter (0..5), and 5 bits in each frame for other uses.

2. Send the superframe less frequently

The current LICH is defined as sending the superframe back-to-back, 5 times a second (or about 4 per second for the previous proposal).  M17 transmits 25 frames per second.  We could send the superframe once or twice per second instead.  This would increase the time required to for receivers to sync with a channel.  But it would also provide a side channel for additional information, such as location information (APRS-like data), personal avatars, or many other uses.  The LICH is a 1200bps side channel (48 bits per frame, 25 frames per second = 1200bps).  By sending the superframe twice per second, we have about 600bps available.  By sending the superframe once per second we have a 900bps.

Combining these two ideas, we can use the 5 bits to encode 32 different types of information being sent (text message, location, status text, public key, avatar, etc).  Or we can just indicate that it is "data" and require the data format include a data type descriptor.  The type of data to be allowed in the LICH is outside the scope of this proposal.

If nothing needs to be sent, then the superframe can be be sent.  Or, one can think of this as allowing the superframe to be interrupted 2-3 times per second for additional data.

An argument against the second approach is that this data could be sent by switching to D/V mode.  If that approach is taken, it might be useful to be able to switch between 3200bps Voice and 1600/1600bps Data/Voice modes seamlessly during a transmission.  DMR uses different sync words for this.  But it also uses a longer sync word.

If we went with the second option, any receiver looking for the superframe would look at the new "info" field and start decoding when it indicates a superframe. It would collect all 6 segments and assemble the superframe.  If the info field indicates something else being sent, it could watch for that or ignore it.

Print this item

  Repeater TX/RX boards - help needed
Posted by: SP5WWP - 11-05-2020, 08:06 PM - Forum: Technical - No Replies

We need to update the design to use ADF7021 ICs instead of Si4463.


"rx_board" and "tx_board" directories contain old designs (Eagle 7.7.0). "rx_board_new" is F6ITU's attempt to transition the project to KiCAD, but the work isn't finished yet. Same thing has to be done with the TX board.

Print this item

  It's time to start working on M17 Mobile Radio!
Posted by: Eliot - 11-05-2020, 02:25 PM - Forum: Technical - Replies (2)

Hi! I'm going to start project of M17 mobile radio (code name MR-17?). I think that we could use the same CPU as in TR-9 and ADF7021. Display could be 320x240pix, maybe this one: https://www.tme.eu/pl/details/ph240320t-.../powertip/ . I was wondering how many switches should be on front panel next to LCD and if encoder with push button will be good idea?

Print this item

Lightbulb Baseband Demodulator Feedback
Posted by: WX9O - 11-04-2020, 10:45 PM - Forum: Technical - Replies (7)

Please use this thread to provide feedback or ask questions about the implementation of the M17 baseband demodulator posted here:


I plan to post my modulator notes and implementation, hopefully within a week, and then maybe another notebook with just my notes on the digital encoding/decoding bits.

Some of the implementation choices were made because I plan to re-implement the code in C++, targetting an 80MHz STM32L433.

If you know of a good GPL Viterbi implementation in C or C++ that handles erasure or accepts LLR inputs, please let me know.

Print this item

Posted by: AD8DP - 11-04-2020, 01:24 AM - Forum: Technical - Replies (14)

I just pushed M172DMR to git:


This is to connect a DMR master server or XLX server to an M17 reflector.  I have tested on my all mode xlx network and all modes Dstar, DMR, YSF, P25, NXDN, and Peanut all sound excellent coming out on the M17 reflector. As with DMR2M17, M17 transmissions from the currently available clients (mvoice, dudestar, droidstar) do not sounds as good out of these modes.


Print this item

Posted by: AD8DP - 11-02-2020, 07:04 AM - Forum: Technical - Replies (10)

I just pushed DMR2M17 to my fork of the MMDVM_CM repo:


The quality from DMR radio to M17 is excellent.  This is with the PCM data passed directly from the md380 vocoder to the codec2 vocoder.  I added a configuration option 'GainAdjustDb' in DMR2M17.ini with a default setting of -6dB for PCM data returned from codec2, because without this level of attenuation the M17 transmissions were blowing out my DMR radio speaker.  Values of -6dB to -10dB seem to get the audio to a reasonable level, but the quality from any of the current options for M17 (mvoice, dudestar, droidstar) to the DMR radio is far from excellent, as demonstrated in this video:


This should be considered a work in progress, but it's something to play with for now.


Print this item

  New Facebook Group
Posted by: EA7IYR - 10-30-2020, 09:12 AM - Forum: General discussion - No Replies

Hello SP5WWP and EA7IYR, they have created a facebook group for M17 in order to spread the information and help more people who want to enter the world of M17.

everyone is welcome to join this great project !!

Facebook group

Print this item