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



Search Forums

(Advanced Search)

Forum Statistics
» Members: 210
» Latest member: iazwii9
» Forum threads: 84
» Forum posts: 548

Full Statistics

Online Users
There are currently 27 online users.
» 0 Member(s) | 25 Guest(s)
Bing, Google

Latest Threads
China Zinc Plated Wood Sc...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Discount Ship To FBA
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Air Mesh Fabric suppliers
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Activated Carbon For Chem...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
China Face Masks manufact...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
China Food Packing Machin...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
China white square dinner...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Integrated Ultrasonic Lev...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Copper Products China
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Custom Solid Aluminum She...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3

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

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 (3)

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 (11)

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

  Config File for TR-9
Posted by: md - 10-27-2020, 12:46 PM - Forum: Technical - No Replies

I think we should seperate the codeplug(frequencies, channel-wide settings etc.) file and settings file which contains radio-wide settings. Personally, I hate to set every button function, key tone, display options, ID, callsign fields and much more again and again when I wanted to try to use updated codeplug file. Here is my proposal template.

welcomeMsg: Hello TR9 //16 chars to be displayed at startup
powerOnPswd: 12345//4-8 digit int
lastCh: 3,5 //int zone, int channel
PF1: zoneToggle //Programmanble button 1 function
PF2: highLow //Programmanble button 2 function
Tones: 0 //Alert tones
DispBl: auto //Display Backlight (auto, key, on, off) auto enables during rx, key enables only keypress
keypadLock: off // off or duration in seconds
TalkPermit: on //on, m17, fm, off
TOT: 60
LowBatTone: 180 //Low battery alert tone interval in seconds, 0: No lowbat tone
APO: 6 //Auto power off time in hours

APRS_Path: WIDE2-2
APRS_Interval: 300 //in seconds
APRS_Smart: on //Smart Beacon
APRS_Comment: Hello M17
APRS_QRV: off //embed active frequency in comment
APRS_freq: 432500000 //enter 0 to tx into active frequency

rfPing: on //Remote radio check
rfPingAuth: on //Authenticated radio check
rfSelcalDecode: on //Selective calling/private call decode
rfSelcalDecodeAuth: on //Authenticated private call decode
rfRmtMon: off //Remote Monitor
rfRmtMonAuth: on //only trusted users can monitor
rfRmtMonEmg: on //Remote monitor is allowed if emergency call is initiated
rfRmtMonEmgAuth: on
rfRmtDisableDec: off //Remote disable decode for lost/stolen radio
rfRmtEnableDec: off //Remote enable
rfRmtDisableDec_Auth: on //Authenticated Remote disable decode
rfRmtEnableDec_Auth: on //Only trusted users can disable/enable radio
RmtDisableSdCardEnc: on //Encrypt sd card when remote disable
RmtDisableSdCardDel: off //Delete sd card when remote disable

CVEM: off //Clear voice receive in Encrypted Mode
EVCM: on //Enrypted voice receive in Clear Mode
CVAlert: off //Clear voice transmission alert at ptt in encryption enabled channel.
ClearResponse: off //Answer in clear mode if clear signal is received, ! use with caution !
EncResponse: on //Answer in encrypted mode if encrypted signal is received
MultiKeyEnc: off //Randomly select one of the installed keys.
MultiKeyDec: on //Decrypt using necessary key, if set to off only programmed key is used to decrypt.
EncryptID: off //Encrypt user ID/TG when using encryption.
OTAR: off // Over the air rekeying, unsafe
OTAR_Auth: on // Otar using previous keys or public encryption.
OTIR: off // Rekeying over the internet
OTIR_Auth: off
FpRekey: on //Entering keys using front panel.
FpRekeyPass: 99887766 //8 digit rekey pass

EncryptSDCard: off
DecryptSDPin: 1234 //Pin code to decrypt sd card.
EncryptKeyfile: on //Encrypt encryption keys file, this cannot be undone.

Print this item