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



Search Forums

(Advanced Search)

Forum Statistics
» Members: 250
» Latest member: niki12345
» Forum threads: 85
» Forum posts: 594

Full Statistics

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

Latest Threads
New mrefd release 0.3.6
Forum: Reflectors
Last Post: niki12345
41 minutes ago
» Replies: 1
» Views: 291
Re-use of NONCE space
Forum: Technical
Last Post: tarxvf
05-08-2021, 07:40 PM
» Replies: 11
» Views: 420
USRP2M17 make error
Forum: General discussion
Last Post: G0VGS
05-08-2021, 10:57 AM
» Replies: 0
» Views: 51
new version of mvoice
Forum: General discussion
Last Post: G0VGS
05-07-2021, 11:32 AM
» Replies: 20
» Views: 3,533
Audio quality initial rea...
Forum: General discussion
Last Post: G0VGS
05-05-2021, 06:21 AM
» Replies: 2
» Views: 122
register reflector M17-EA...
Forum: Reflectors
Last Post: on6dp
04-28-2021, 11:17 PM
» Replies: 2
» Views: 721
How to turn an old Motoro...
Forum: Technical
Last Post: md
04-26-2021, 10:24 PM
» Replies: 4
» Views: 805
Use of the DST field with...
Forum: Technical
Last Post: G4KLX
04-19-2021, 10:22 PM
» Replies: 0
» Views: 91
USRP2M17 added to MMDVM_C...
Forum: Technical
Last Post: N4IRS
04-11-2021, 02:02 PM
» Replies: 1
» Views: 270
M17 Protocol Proposals
Forum: Technical
Last Post: G4KLX
04-05-2021, 03:53 PM
» Replies: 7
» Views: 452

  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

  Other codecs
Posted by: G4KLX - 10-27-2020, 11:35 AM - Forum: Technical - Replies (1)

As currently defined, there is a two bit field to distinguish between the type of payload. There is an inference that voice-only means one particular type/rate of codec, and data+voice means another.

Codec2 is still an active project and it seems to me that M17 would be best served by adding another bit field to the type bits which indicates the particular type of codec. At the very least it would stop old firmware versions trying to decode newer codecs which they don't understand. Typically newer firmware would include the old codecs already.

This question was raised on the MMDVM forum where someone suggested a HF gateway, and of course HF codecs are different, but in theory understandable by other Codec2 based systems without transcoding.

Print this item

Lightbulb Short Text Messages
Posted by: SP5WWP - 10-26-2020, 09:17 PM - Forum: Technical - Replies (14)

How do we want to send Short Text Messages via M17?

Bonus question: do we need to differentiate between M17 streams and packets? Every packet can be sent as a stream anyway.

Print this item

  test M17 in MMDVM
Posted by: ea5gvk - 10-24-2020, 06:21 PM - Forum: Technical - Replies (1)

I have made the first tests in a logical way, I don't have radios yet, but if I have put to work the M17 branch of the MMDVMHost and I have loaded Firmware for my DMO, STM32F446RE with the M17 branch, it connects perfectly to the M17 reflector, but when it receives the traffic, which drives the mvoice, in the MMDVHost log, it exposes this:

M17, network packet received with an invalid CRC and blocks the modem.

Tests carried out on the M17-SPA 1 Reflector


Print this item

  Reflector Registration
Posted by: KC1AWV - 10-23-2020, 02:47 PM - Forum: Reflectors - Replies (108)

Until there is an official central registration system for M17 Reflectors, listing of the reflectors on the M17 Website is a manual process.

If you would like your reflector listed, please provide the following required information as a post to this thread:

  • The URL to a working dashboard on an SSL enabled site
  • The IPv4 and/or IPv6 address to be added to the host file
  • The port the reflector is listening on
  • The hosting or sponsoring station or organization
  • The country the reflector is primarily used in
  • A Github username for the person responsible for maintaining the reflector - Optional
An SSL certificate is a requirement for properly displaying the dashboard on the M17 website. Free certificates can be obtained through LetsEncrypt, and automated tools can be used to automate the process, such as certbot or acme.sh.

If a Github username is provided, issues with the uptime of your dashboard will be created and assigned to you. This can be helpful when trying to diagnose up/down problems.

Please allow 24-48 hours for your reflector to be listed. Confirmation of the listing will be provided to you with a reply to your post here.

Print this item

  M17 and multiple repeaters
Posted by: G4KLX - 10-19-2020, 11:26 AM - Forum: Technical - Replies (3)

Hi All

One of the criticisms that I have of System Fusion, is that there is nowhere within the RF protocol that allows you to address an individual repeater. On FM we have CTCSS, on D-Star RPT1, Color Code on DMR, RAN on NXDN, and NAC on P25 phase 1. This is an issue in the UK, and many other European countries, where frequency reuse is high and there is the very real possibility of being able to hear two repeaters on one frequency.

Like System Fusion, M17 doesn't include any form of selective calling, and that worries me. Has anyone thought about this?

Jonathan  G4KLX

Print this item

  Test and verification data
Posted by: G4KLX - 10-19-2020, 11:22 AM - Forum: Technical - Replies (4)

Hi All

Having implemented all of the code in the MMDVM for M17, I am now at the testing stage. Things like the checksum and callsign encoding and decoding have been tested and known to work. However the rest of the code is unknown currently.

I plan on taking known valid M17 network frames, and feed them into my network receiving code, dumping the data at every stage, and feeding the result back into the RF receiving code to ensure that the data is decoded in the opposite way. It would then go out of the network, and I can compare that with the original incoming network data.

The only problem with that is that I will be testing against myself and therefore am only testing for internal consistency. What would be nice would be some example data, as an appending to the specification, that did the same as I am doing for one (or more) RF frame showing what the results should be at each stage. In the absence of hardware, this would allow for independent developments to be sure that they are following the correct route.

Jonathan  G4KLX

Print this item

  Fragment LICHs
Posted by: G4KLX - 10-19-2020, 11:17 AM - Forum: Technical - Replies (13)

Hi All

I've just finished implementing M17 on the MMDVM, although it is almost completely untested in any meaningful way. I have included a network client for the reflector protocol, but it's hardcoded in the ini file currently, I will probably add a simple minded gateway with parrot at some point. I'll also add a gateway into APRS-IS once there is a standard for APRS/GPS data for M17.

One area that bothers me (apart from being able to distinguish between the link setup and normal data) is the handling of fragment LICH data.

You need to receive five frames to be able to recover the full LICH from the fragments. As an aside, I assume that an FN=0 is the first fragment, FN=1 is the second fragment, and then continuing in a round-robin fashion? This needs documenting.

My issue is with the integrity of the received fragment LICH data. In cases where it is needed for late entry, the overall checksum can be used to determine if you have a complete uncorrupted LICH, which is fine as far as it goes. The problem comes when receiving the fragments, some may have bit errors and you don't know which they are, so you try and rebuild the FICH with faulty data, and it fails. This could keep happening as you don't know which fragment is good or not. Would it not be better to dispense with the overall checksum on the LICH (saving 16-bits) and instead have a short checksum on each LICH fragment? That way we can be sure that each fragment is not corrupted, and can be used for the overall LICH without problems.

If that is not good enough, then maybe keep the overall checksum in the LICH and have the LICH spread over six frames, or more, instead of five to allow for the extra space for a local fragment checksum as above.

Jonathan  G4KLX

Print this item

  NONCE field
Posted by: SP5WWP - 10-18-2020, 04:40 PM - Forum: Technical - No Replies

Moving a topic from IRC here.

Me, nortti and md were talking about changes to the NONCE field structure:
TIMESTAMP - 64 bits -> change to 32 bits, just take the lower part of UNIX timestamp
NONCE - 32 bits -> change to 64 bits
CTR_HIGH - 16 bits

Print this item

  Distinguishing between frame types and FN
Posted by: G4KLX - 10-16-2020, 03:57 PM - Forum: Technical - Replies (14)

Hi All

When receiving M17 frames, for stream mode there are two frame types, the Link Setup frame and the rest. They are the same length and use the same sync vector. How is it possible to distinguish between them? I can think of a way, but it is computationally expensive and appears sub-optimal. Is there an easier way?

I have an observation: why is there a 16-bit FN field? On a network packet I can understand it, but on RF frames I do not, they cannot appear out of order. I think the FN is used so that it is possible to put the LICH chunks back together if you missed the initial Link Setup frame and perform a late entry, this is what NXDN does for example. However to do this, you only need a counter to five, and an extra pattern or bit to indicate the end of transmission as now, and you save a great number of bits.

For comparison P25 phase I has no header (it has an optional encryption header but that is a different thing) and all incoming transmissions are late entry.

Jonathan  G4KLX

Print this item