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



Search Forums

(Advanced Search)

Forum Statistics
» Members: 318
» Latest member: nj2dx
» Forum threads: 93
» Forum posts: 620

Full Statistics

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

Latest Threads
Change Profile name
Forum: General discussion
Last Post: David.cureton@dcureton.com
Yesterday, 03:11 AM
» Replies: 2
» Views: 36
Standardizing M17 BER Tes...
Forum: Technical
Last Post: David.cureton@dcureton.com
Yesterday, 12:10 AM
» Replies: 5
» Views: 342
Remove CRC from Audio Pay...
Forum: Technical
Last Post: David.cureton@dcureton.com
09-22-2021, 11:20 PM
» Replies: 2
» Views: 610
Encoding of GNSS (GPS) in...
Forum: Technical
Last Post: David.cureton@dcureton.com
09-22-2021, 11:03 PM
» Replies: 0
» Views: 33
Forum: Technical
Last Post: AD8DP
09-22-2021, 07:56 PM
» Replies: 16
» Views: 5,005
Callsigns and Extended Us...
Forum: Technical
Last Post: G4KLX
09-22-2021, 06:09 PM
» Replies: 0
» Views: 23
New Reflector M17-DMR
Forum: Reflectors
Last Post: shaymez
08-21-2021, 11:39 AM
» Replies: 0
» Views: 145
PC encoder/decoder
Forum: Technical
Last Post: PA1VHF
08-18-2021, 08:15 AM
» Replies: 2
» Views: 178
M17 Voice Using Mobilinkd...
Forum: Technical
Last Post: VR2XKP
07-14-2021, 01:59 PM
» Replies: 3
» Views: 976
Hello all
Forum: General discussion
Last Post: vk3hjq
07-11-2021, 12:36 PM
» Replies: 2
» Views: 313

  Encoding of GNSS (GPS) information
Posted by: David.cureton@dcureton.com - 09-22-2021, 11:03 PM - Forum: Technical - No Replies

Hi Guys/Girls, 
  I have read the technical spec of the M17 protocol and what a breath of fresh! Hats off to the authors of this document.

One thing that I did choke on was the encoding of GNSS latitude/longitude coordinates in the application layer.

[font=Lato, proxima-nova, "Helvetica Neue", Arial, sans-serif]"32-bit fixed point degrees and decimal minutes (TBD)"[/font]

Given this not a presentation layer, surely the better approach is to store these quantities as decimal degrees rather than the mashup format that is integer degrees with decimal minutes. 

Using decimal degrees uses the space more efficiently allowing greater resolution and a simpler encoding to boot.  It is the default format that almost any modern software uses/accepts as input. 

Can this be changed before it it too late! I would hate M17 to become an mishmash of formats that is endemic in APRS. 

I look forward to joining you on the Friday Net. 


Print this item

  Change Profile name
Posted by: David.cureton@dcureton.com - 09-22-2021, 10:43 PM - Forum: General discussion - Replies (2)

Hi Guys, 
   I like the look of the M17 project.. Very cool. 

   I have already earned my newbie status by registering using my email address as a user name.  I wasn't aware that this would be my handle on all posts.  I can not see any way to change the user name in the User CP section, or any way to reach out to the formum morerators to fix this.. 

Can someone please help me by fiddling the database to change my user name to from my email address to my call sign VK3DCU. 

Many thanks, 

Print this item

  Callsigns and Extended Use of the META Field in M17
Posted by: G4KLX - 09-22-2021, 06:09 PM - Forum: Technical - No Replies


Having got an RF implementation of M17 working. I decided to investigate the use of the META field in the LICH/LSF to add extra functionality to the mode. This was implemented in addition to the standardisation of the use of the source and destination fields in my M17 client/repeater/gateway system which provides a rich environment for users and ensures that an M17 system is legal under all licencing regimes.

The Source and Destination Fields

The use of the source and destination callsigns in the LICH/LSF has been standardised in my implementation. The rule observed is that the source callsign is always that of the station transmitting, be it a client or a repeater. This is not a problem for a client, but for a repeater this raises issues about identifying the original source of a transmission.

Having a repeater always use its own callsign for the source field does ensure that their are no issues with licencing authorities.

The Client

Aside from the source always being that of the RF transmitting station, the destination has been defined as having certain values. This list is not exclusive but lists the values that are currently in use:

ECHO – Triggers the local echo function in a repeater/gateway.

INFO – Triggers a voice and text announcement of the current linked status of the repeater/gateway. This information is also triggered by a change of state, either explicitly from the client or due to a failure or timeout of the link.

UNLINK – Unlinks from a reflector, also triggers an INFO response.

ALL – This is in fact an alias for the broadcast address rather than the text “ALL”. This does not trigger a status change in the repeater/gateway, but any transmission is relayed to any connected reflector.

Reflector Name – If the destination is a valid reflector name, such as “M17-M17 C” then this causes the repeater/gateway to link to that reflector if it is not already done so, and trigger an INFO response. If the repeater/gateway is already linked to that reflector, no action is taken.

All other values of the destination are currently undefined.

The Repeater/Gateway

The current values of the destination field are:

ECHO – Used for the reply of the inbuilt echo functionality. Since the source callsign from the repeater is not of the originator of the echo transmission, the originators callsign is transmitted in the extended callsign data (see later).

INFO – Used for the voice and text transmission of the current repeater/gateway status. This is available in multiple languages. Since this is generated at the local repeater/gateway there is no need for any extra callsign data over and above that in the source and destination fields.

ALL – This is used for all transmitted reflector traffic. Since the originator callsign is not used for the source callsign, information about the originator and the currently linked reflector is transmitted in the extended callsign data (see later). Note that ALL is simply an alias for the M17 broadcast address which is what is transmitted over RF.

Locally repeated RF traffic retains its original destination address, and the originators calsigns is transmitted in the extended callsign data (see later) since the source callsign is that of the repeater itself.

Extended Use of the META Field

The META field is included in the LICH/LSF, and is 14 bytes in length. It is included in the Link Setup frame and then subsequently in the LSF so is potentially decodable every six Stream Data frames, which is every 240 ms. The extended data in the META field is transmitted in a simple round robin manner, with the only exception being GPS data which should be transmitted as soon as possible after the GPS data is received from its source.

This extra data payload, which doesn’t affect the bandwidth available for the audio, is useful for transmitting relatively small amounts of data. The following data is already being used. In all of these cases the Encryption Type in the LICH/LSF is set to NONE which is 0b00.

Text Data

In this case the Encryption Subtype is set to 0b00. A value of 0x00 in the first byte of the META field indicates that no text data is included and is backwards compatible with existing implementations that do not include text data.

There may be up to four blocks of data which after removing the control data, allows for a maximum text length of 52 bytes. The text is UTF-8 encoded, and is padded with space characters to fill any unused space at the end of the last used META field. This text data follows immediately after the control data byte in each META field used.

The control data is in the first byte of each META field and is split into two four bit fields. The top four bits are used to indicate the total length of the text data and is a bit map. There is one bit per used text field, with 0b0001 used for the one field, 0b0011, for the two, 0b0111 for three, and 0b1111 for four.

The bottom four bits indicate which of the text fields this text corresponds to. It is 0b0001 for the first, 0b0010 for the second, 0b0100 for the third, and 0b1000 for the fourth. Any received text META control data is OR-ed together by the receiving station, and once the top and bottom four bits are the same, all of the text data has been received.

It is up to the receiver to decide how to display this text. It may choose to wait for all of the text to be received, or display the parts as they are received. It is not expected that the data in the text field changes during the course of a transmission.

GPS Data

This has not been tested yet and so will not be described as there may be changes to the format. The data fits into one META field, and has an Encryption Subtype of 0b01.

Once tested a definition will be published and any local GPS data will be gated to APRS-IS in the M17 Gateway. It is expected that GPS data will be included in the outgoing data stream as soon as possible after the data is presented from the GPS device. However it should not be presented any faster than every thirty seconds nor when the vehicle has moved less than 500 metres.

Extra Callsign Data

This is only transmitted from repeaters/gateways and not from clients, who only receive and display this data. The Encryption Subtype is 0b10, and the data fits into one META field. These fields should not appear over M17 Internet links as they should only be used on RF from a repeater/gateway.

The META field is split into two callsign fields. The first is always present, and the second is optional. The callsign data is encoded using the standard M17 callsign compression scheme which takes six bytes to encode a nine character callsign. Any unused space in the META field contains 0x00 bytes. The first callsign field starts at offset zero in the META field, and the second callsign if present starts immediately after the first. There are two unused bytes at the end of the META field.

The use of these two callsign fields is as follows:

|                     | Callsign Field 1 | Callsign Field 2 |
| Locally Repeated RF | Originator       | Unused           |
| ECHO Reply          | Originator       | Unused           |
| Reflector Traffic   | Originator       | Reflector Name   |

The extended callsign data is not used under any other circumstances than the above currently.

It is not expected that the data in the extra callsign fields change during the course of a transmission.

Null Data

As mentioned in the Text Data section above, setting the Encryption Subtype to 0b00 and setting the first byte of the META field to 0x00 indicates that the META field contains no data. This is the default from many M17 Internet clients already.

Jonathan  G4KLX

Print this item

  New Reflector M17-DMR
Posted by: shaymez - 08-21-2021, 11:39 AM - Forum: Reflectors - No Replies

Hi, any chance you can look to authorising reflector M17-DMR, I’ve started the process on the reflectors site. Many thanks 

Shane M0VUB

Print this item

  PC encoder/decoder
Posted by: PA1VHF - 08-12-2021, 02:01 PM - Forum: Technical - Replies (2)

Hi there,

Maybe a very stupid question from an outsider.

Is there any chance the encoder will be available to run on mainstream computing hardware, giving the possibility to feed the signal into the analog input of a random mainstream VHF/UHF radio, just like voice over 9k6 packet?

Yours sincerely,


Print this item

  Standardizing M17 BER Testing
Posted by: WX9O - 07-26-2021, 03:52 AM - Forum: Technical - Replies (5)

It would be useful to have interoperable BER testing between conforming implementations, so that a transmitters, receivers, and test equipment from different vendors could be used for M17 equipment testing.  This would be useful for end users -- especially ham operators -- in tuning their equipment.

As a strawman, I propose using the reserved sync word (now BER SYNC WORD) for this purpose, along with a custom frame type which uses the P2 puncture matrix.  The frame would be 197 bits long (24 bytes + 5 bits).  The first two bytes would be a frame number and would seed a LFSR PRNG.  If we want to use more than one LFSR, we could use some of the reserved bits in the frame type word for this.

The LSF would be sent as-is, with the frame type set as STREAM and the stream type set to the reserved type "00".  This would be followed by BER frames using the BER SYNC WORD, containing a 16-bit frame number and 181 bits of pseudo-random data encoded similarly to the stream payload audio data (i.e. using the same puncture matrix).

197 bits gets extended to 201 bits with 4 bits of 0 used to flush the convolutional encoder.  This is encoded into 402 bits.  This is then punctured to 368 bits, which is a full frame.

Frame numbers would start at 1 in order to have at least on bit set in the LFSR.

Seeding the LFSR with a frame number allows for synchronization and recovery of the BER test.

We would use a 16-bit LFSR with the polynomial [img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMQAAAAXCAYAAABUDODqAAAFgUlEQVR4Ae3biZHsNBAG4CYDyAAygAg4EgAi4EiAIwEgAiACeBEAEQARABFABpAB1PdK/arXJc/Y8tjrpaartDosy38fv66pjbjL3QJ3C9wtcLfA3QK3tMCrEfFeZ8CXI+LLiPg6Il7vPD9LE5wfTsDQ6YOIeDMi3o2ITyfPz1b9pAPorWb7s9s/oX908jhJnLO5oPkmIn5vgV87evZLRAg2ZPmxPjxRGWHhlKoIpn9bgp0eZxRE/r7hfKkAZP+fW539/44IbWeV1xpGdn/yIqikKs8iAuMJJc88w8LXI8RTcQ4iIG8lBKJoI4igfGZ9kJoPzoyxmfN61iMEB7wfEV+0rcf1UR6vR48Qb7eVzZbpzNs9VusRoloTOf458SpnBWPv/y0hKIcQtlNEnuXWdKqsR4hsk5u9pivgmRRIQkwx2ebZ7v12YlLD+FUD/tiE6J2DpzZdVBcsqZQXkhCCichz+W5Np8oy+CsojspzQ245zroHT0LULVPVxQrnDHHGlc7WOu38GITge/Fr0hCjczas9rxanhKC4Q2eDkhCZP3qgKXDZwfsK3uEsM2oeOmj31p544DVpUcI5K0Ehv/bteBb/70uRNjXwd+2Wgz9GRHftQl1LVR2Hjmnmsg/n7mYWIvhRf8pITywZ80ASkK8eGFFAWArzp7SI8RfxcBbVgjY6+q5hx49Qpht3f6ljBLC2L/mIDvkxs+0ZYXYamc+YiNYZsVVWAa1TuqYmGKpc+j8oSXlXP6QBNuJfDQothDilYY/MWW9wXqewWyGMjsp56zqu36HIPCPnoG2Oor9ExMs1cbqZlm/k3CmPFc1s2XaPw/VdZznii34I0AE6qiIl8RkDPUpjowjPuCL6fMl395q56uEcJAUBHkoc4WaV2MfN4QU4TBgJOUMPl04AjG2HFZGCQEv7HSwf3bjpU4HKSXxy6XqjMQvHxVj0mGtCCKB6F2rLQzw59Yix9MvbS+vwafufan6Jd9dko8SwvcSv5WKHzJZfaudM47SF/XZEoz6jNo5x2ej2RXCQwGUoqMgskIoc8xRAgvHrhH9636ZYziBmIUE2FGSQbnme1ayOisjAbuzv0Oocg38NWOv7TtKiJ8aXt8TrDCbpCTlkf3+Jewjdq7jXSQEJqekMgiCyYixlzMYf5oAfafTrt+ceKfOiByQBKHblhVr7pvap9jVYYen92xuLLaukwBy5HkgV625d7e293D6fq997luI6zIkJQmN6GJHDFX/ZL+leQ/LiJ3r9y4SonZ0AhdQlNlTGMrhbZrM7IJh2l5n0Eu47Fnhryvepf5bnsE0xQk7Habt6ksnFlu+JPQWfNfeFcQ9nFbUXvvSraQdRRL6GoYlz/ew82JC3FqZJQrXPoDW2bI+W1Lm5CMIPYdl61KONEcRuqeD2Xjp5NN7X9sRhN5q54uEEESWoJ4yZtp609S67ZaNEMKWyF6VIPQfrSxzYFs6s5XXhosjjkIC2wzSI3Q+a112zUYIYTuUt0U9Qu+Bf8TO1XCzhDCwGcleW/Ar60woesulrw17MRshBMy2KfAq1xkOQY4k9Iij4IUbefMX1DQSgkhHyQghMrhMPOKILuxA2J4Pbi0jdq4YEjN9HwgnCCYsBtwZglPcCnDUkcEE2AghkNb/AMDvipg+/l/A7yW5cjxQesfKiKMEEawOn4KfPmZc7W6ZjpQRQphI3eaJGTpI9FF3FtlyoJ7TfcTOxvJLuWRbh7hiXf1BnCBFMtpLSKC+98G6p+wIIRi84nXroU6vo8V36bBWvAc3SX2Onox8e4QQ3oO14qWPtJeM2pmN6ThNjxEri2zjPLD0NmbRgAd3Ytgjzyx7qLfHnv/WONl5r+v0W2O9j3e3wN0CdwvcLfDkLfAfR9ZBM+MA48gAAAAASUVORK5CYII=[/img]


The least significant 8 bits would be used, then shifted 8 bits, then the next 8 bits extracted and so on.  On the final byte, only the most-significant 5 bits will be used.

Print this item

  Hello all
Posted by: vk3hjq - 07-10-2021, 04:02 AM - Forum: General discussion - Replies (2)

Hello all,

I only found out about M17 yesterday, what a great mode this is & nice audio too, thank you to all concerned.

We now have the M17 -432H up & running thanks to Tony VK3JED, which will be eventually connected to the *HAM* 69556 EchoLink node.

73  Smile

John vk3hjq

Print this item

  M17 Fullrate and Wideband
Posted by: Kooga - 05-29-2021, 12:53 AM - Forum: General discussion - Replies (1)

Hello! Are there any plans to add the ability to use fullrate codecs? The M17 air interface provides data rates up to 9600 and it would be nice to be able to use of higher rate codecs, by analogy with AMBE Fullrate. It would also be interesting to have a wideband radio interface for operation in the 25 kHz bandwidth, at a rate higher than 9600. In this case, it would be possible to use wideband codecs.

Print this item

  USRP2M17 make error
Posted by: G0VGS - 05-08-2021, 10:57 AM - Forum: General discussion - No Replies

Hi all,
Just starting to explore the USRP2M17 bridge and got as far as 'make'. Unfortunately I get an error.  I have reloaded from git and also tried a 'make clean' but I still get the same error.  I would appreciate any help with resolving it.  I have attached the error.



Print this item

  Audio quality initial reaction
Posted by: G0VGS - 05-04-2021, 01:30 PM - Forum: General discussion - Replies (2)

Hi all,
Newbie alert!

I have set up mvoice on a raspberry pi and also in a VM using Ubuntu.  On both, I find the audio coming back from the echo server rather gravelly.  Is this just the echo server?  I have checked the headset and it appears fine.
It may be that this is the current state and that is fine.  I am just trying to work out if I have done something wrong along the way Smile

73 Ian

Print this item