Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Callsigns and Extended Use of the META Field in M17
#1
Introduction

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
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)