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



Search Forums

(Advanced Search)

Forum Statistics
» Members: 357
» Latest member: kk66oo
» Forum threads: 95
» Forum posts: 627

Full Statistics

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

Latest Threads
The format of the M17 GPS...
Forum: Technical
Last Post: VK3DCU
10-08-2021, 12:57 AM
» Replies: 2
» Views: 313
Last stream/packet BER pu...
Forum: Technical
Last Post: G4KLX
10-04-2021, 10:42 PM
» Replies: 1
» Views: 237
Change Profile name
Forum: General discussion
Last Post: KC1AWV
09-27-2021, 12:53 AM
» Replies: 3
» Views: 451
M17 - SDR & GNU Radio
Forum: Technical
Last Post: Radiomix2000
09-26-2021, 09:15 PM
» Replies: 11
» Views: 6,698
Standardizing M17 BER Tes...
Forum: Technical
Last Post: David.cureton@dcureton.com
09-23-2021, 12:10 AM
» Replies: 5
» Views: 869
Remove CRC from Audio Pay...
Forum: Technical
Last Post: David.cureton@dcureton.com
09-22-2021, 11:20 PM
» Replies: 2
» Views: 900
Encoding of GNSS (GPS) in...
Forum: Technical
Last Post: David.cureton@dcureton.com
09-22-2021, 11:03 PM
» Replies: 0
» Views: 212
Forum: Technical
Last Post: AD8DP
09-22-2021, 07:56 PM
» Replies: 16
» Views: 6,350
Callsigns and Extended Us...
Forum: Technical
Last Post: G4KLX
09-22-2021, 06:09 PM
» Replies: 0
» Views: 199
New Reflector M17-DMR
Forum: Reflectors
Last Post: shaymez
08-21-2021, 11:39 AM
» Replies: 0
» Views: 373

  The format of the M17 GPS Data
Posted by: G4KLX - 10-04-2021, 10:44 PM - Forum: Technical - Replies (2)

This is a follow up to the previous document which explained how the META field has been used to pass extended callsign and text data, in addition to the existing callsign and voice data. This document should be read in conjunction with the previous document.

For GPS data the Encryption Type is 0b00 as per the other types of extended META data, and the Encryption Subtype is set to 0b01. Unlike the other forms of data previously documented, this data is expected to be dynamic during the course of a transmission and to be transmitted quickly after the GPS data becomes available. To stop the LSF data stream from being overrun with GPS data relative to other data types, a throttle on the amount of GPS data transmitted is needed. The M17 Client sends GPS data every five seconds, for example.

The GPS data fits within one META field, which equates to six audio frames, and takes 240ms to transmit.

For this description C/C++ style array nomenclature is used. The META field is referred to as an array named meta and with an index of 0 referring to the first byte of that array, and therefore the first byte of the META field.

meta[0] is the software/hardware used to generate this GPS data. The current defined values are 0x00 for the M17 Client, and 0x01 for OpenRTX, other hardware and software will be added as they become available. This is used to modify the message added to the APRS message sent to APRS-IS.

meta[1] is the type of station that transmitted the data. 0x00 is for a fixed station, 0x01 is for a mobile station, and 0x02 for a handheld. These are translated into suitable APRS symbols when gated to APRS-IS.

The latitude and longitude are encoded as positive values with their ranges set to +90 to -90 for the latitude, and +180 to -180 for the longitude. The sign i.e. North/South and East/West are encoded separately.

meta[2] is the whole number of degrees of latitude.

meta[3] and meta[4] are the decimal degrees of latitude multiplied by 65535, and stored with the MSB first.

meta[5] is the whole number of degrees of longitude.

meta[6] and meta[7] are the decimal degrees of longitude multiplied by 65535, and stored with the MSB first.

If the latitude is south of the equator then meta[8] is ORed with 0x01. If the longitude is west of the Greenwich meridian then meta[8] is ORed with 0x02.

If altitude data is available from the GPS device then meta[9] and meta[10] contain the whole number of feet above sea level plus 1500 to always make it a positive number. This value is stored MSB first. The reason for using feet is two fold, firstly this is what APRS-IS expects, and secondly there are a little over three feet per metre, and so an integer number of feet gives finer granularity than metres in this context. meta[8] is ORed with 0x04 to indicate that valid altitude data is available.

If speed and bearing data is available from the GPS device then meta[11] and meta[12] contain the whole number of degrees of the bearing which is expected to be between 0 and 360 degrees. This value is stored MSB first. The speed if converted to miles-per-hour and the integer value is stored in meta[13]. The reason for using mps is this is what APRS-IS expects. meta[8] is ORed with 0x08 to indicate that valid speed and bearing data is available.

This is a simple format of the GPS data and doesn't require too much work to convert into, and provides enough flexibility for most cases. This has been tested on-air and successfully gated to APRS-IS, showing a location very close to the position reported by the GPS receiver.

Print this item

  Last stream/packet BER publishing
Posted by: VK3DCU - 09-30-2021, 12:23 AM - Forum: Technical - Replies (1)

   I've been thinking a bit about the M17 protocol and I think it would be also very good for a transmitter to publish the BER of the last received stream/packet as part of the protocol. 

This  information could be send preceding the next transmission or after some timeout if the channel goes idle.

This would only be a RF-LINK thing between direct tranmistters/receivers and would not extend to internet linking as it only makes sense at the RF level. 

This also gives the previous transmitter that has just gone quiet enough time to turn around and be ready to receive an indication of theBER for its last transmission . 

On the turn around of a link (i.e. a repeater)  this would allow all clients to gets an indication of the BER or some other performance metric of the last stream/packet received by the repeater

It would allow users to have a very good indication their link reliability and in the case of a repeater, show which segment of the link is performing  poorly..   the uplink to the repeater or the downlink to the receiver(s). 

With a few tweaks to the protocol we could add support for a high rate codec2 voice and low rate codec2 voice... with the low rate using a lower codec2 rate and adding much more redundancy to the bitstream.

This keeps the fundamental bit rate of the link consistent, but for the low rate adds much more energy per bit for a more reliable copy with a lower codec2 rate. 

I see this beneficial as it gives you a high performance or a high reliability option.    As with digital systems, when you approach a certain error rate the performance falls off a cliff.  

This high/low rate would be used generally with the high rate/high performance in normal conditions, however it gives users the option to switch to the low codec2 rate/ high reliability link to finish the QSO gracefully when things get marginal. 

I expect it would also be desirable to have a high rate/ low rate encoding for packets as well.   In the case of APRS or other unidirectional transmissions, the low rate/ reliable option may be used as there is no acknowledgements.  Better spend a few more bits to get a reliable transmission, especially for low power trackers and alike. 

However for protocols link TCP/IP where there is inherent ack/nak in the protocol or in a well dimensioned fixed (non mobile)link, the extra performance of a high rate can be utilized reliably. 

Whilst something like this does not  have to be entirely specified now, adding a bit for highrate/lowrate convolutional encoding may facilitate the extension of the protocol to support this. 

Please note that this is only in relation to the extra redundancy in the convolutional encoders... the physical layer remains identical so that the bit modems can do their thing and it is all handled in the datalink layer. 

This is not a well formed proposal, however I would like to get ideas from others as to why this would be a good idea or reasons as to why it is not. 


 Best Regards, 
David  VK3DCU

Print this item

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

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