This describes the APRS over DMR data path currently implemented in IPSC3.
It is the private DMR data path used by radios such as AnyTone for GPS/APRS
position reporting. It is not the same as Motorola LRRP, Motorola ARS, SMS/TMS,
or OpenGD77 in-band TA-GPS embedded in voice frames.
The purpose of the protocol is simple:
Default destination radio ID:
9998
Default accepted timeslot mode:
both TS1 and TS2
These values are configurable in the IPSC3 dashboard. A radio implementation
should not hard-code the destination if it can be configured by the user, but
the VKDMR/IPSC3 default is private data to radio ID 9998. The VKDMR user
configuration guidance for AnyTone GPS/APRS is to use Timeslot 1.
The DMR call type must be private data. Group calls, private voice calls, SMS,
TMS, ARS and LRRP are handled by other paths and are not this protocol.
The source radio ID is the user's normal DMR radio ID. IPSC3 uses that radio ID
to look up the APRS source callsign from the RadioID database. The callsign is
not taken from the NMEA sentence.
The implemented decoder currently consumes DMR rate 1/2 packet data blocks.
For MMDVM DMRD packets this means:
DMRD byte 15 low nibble == 0x07
For Motorola/IPSC private data packets this means:
payload_type == 7
Only data type 7 contributes user payload bytes to the APRS decoder. Data type
6 data headers may be present and are captured, but they are not used as NMEA
payload. Other data types are ignored by this APRS payload extractor.
Each accepted rate 1/2 data block contributes 12 bytes of user payload after
DMR BPTC decoding. IPSC3 concatenates those 12 byte chunks for one stream until
the position sentence is complete or the data call ends.
For MMDVM DMRD input, the decoded payload comes from the DMRD burst payload.
The DMRD framing observed by IPSC3 is:
bytes 0..3 ASCII "DMRD"
byte 4 sequence number
bytes 5..7 source radio ID, 24-bit big-endian
bytes 8..10 destination ID, 24-bit big-endian
bytes 11..14 hotspot/repeater peer radio ID, 32-bit big-endian
byte 15 frame/type flags; low nibble is the data type
bytes 16..19 stream ID, 32-bit big-endian
bytes 20..52 encoded DMR burst payload
A radio firmware normally does not need to build MMDVM DMRD packets itself.
It should emit a standards-compliant DMR private data transmission that the
hotspot or repeater presents as the above packet data blocks.
IPSC3 scans the concatenated user payload for the first ASCII "" are ignored for decoding and stored only as diagnostic prefix data.
This allows radios that wrap GPS data in a small private-data application header
to still work.
The position sentence ends at the first of:
CR LF
NUL byte
end of collected payload
For best interoperability a radio should terminate the sentence with CR LF.
A NUL terminator is also accepted.
The payload sentence must be an NMEA RMC sentence. IPSC3 accepts any NMEA talker
that ends in "RMC", for example:
$GPRMC,...
$GNRMC,...
The minimum useful RMC fields are:
field 0 sentence ID, for example GPRMC or GNRMC
field 1 UTC time, hhmmss.sss
field 2 status, A means valid
field 3 latitude, ddmm.mmmmm
field 4 N or S
field 5 longitude, dddmm.mmmmm
field 6 E or W
field 7 speed in knots, optional but recommended
field 8 course in degrees, optional but recommended
field 9 UTC date, ddmmyy, optional but recommended
field 12 mode indicator, optional
The checksum is parsed and stored. A correct checksum should be generated by
the radio. IPSC3 currently stores a valid position when the RMC status is "A"
and latitude/longitude decode, even if the checksum is bad. Do not rely on that
tolerance in a radio implementation; send a correct NMEA checksum.
If IPSC3 receives a sentence that starts with $GPRMC but the checksum matches
the same body with a $GNRMC talker, it normalizes the stored talker to GN. This
exists because some radios have been observed sending GPRMC text with a GN
checksum.
Use a single ASCII RMC sentence with a valid checksum and CR LF terminator.
Example:
$GNRMC,120912.000,A,3352.47783,S,15113.24314,E,0.00,337.76,150626,,,A*6B\r\n
The same example split into 12 byte rate 1/2 data block payload chunks:
00: 24 47 4E 52 4D 43 2C 31 32 30 39 31 "$GNRMC,12091"
01: 32 2E 30 30 30 2C 41 2C 33 33 35 32 "2.000,A,3352"
02: 2E 34 37 37 38 33 2C 53 2C 31 35 31 ".47783,S,151"
03: 31 33 2E 32 34 33 31 34 2C 45 2C 30 "13.24314,E,0"
04: 2E 30 30 2C 33 33 37 2E 37 36 2C 31 ".00,337.76,1"
05: 35 30 36 32 36 2C 2C 2C 41 2A 36 42 "50626,,,A*6B"
06: 0D 0A "\r\n"
The final DMR data block may be padded by the radio/modem data layer. IPSC3
will stop at CR LF or at a NUL byte if one is used.
IPSC3 groups packet data by:
protocol
peer ID
stream ID
For each stream IPSC3 remembers the source radio ID, destination ID, timeslot
and concatenated payload. Stale partial streams are discarded after 300 seconds.
For MMDVM hotspot input, IPSC3 can finalize early as soon as it sees a complete
sentence terminator in the concatenated payload. For IPSC repeater input, the
normal end-of-data-call indication finalizes the stream.
This means a radio should send a proper end-of-data transmission after the
payload. Do not leave the DMR data call open.
IPSC3 marks a GPS position valid only when:
RMC status field == A
latitude is present and decodes
longitude is present and decodes
Latitude format:
ddmm.mmmmm,N
ddmm.mmmmm,S
Longitude format:
dddmm.mmmmm,E
dddmm.mmmmm,W
The decoded decimal position is stored against the source radio ID.
Speed is stored in knots if present. Course is stored in degrees if present.
When sending to APRS-IS, course and speed are formatted as:
ccc/sss
where ccc is rounded course degrees and sss is rounded speed in knots.
After storing a valid position, IPSC3 queues APRS-IS forwarding in a worker
thread. This avoids blocking the RF/audio path on TCP or DNS work.
The APRS-IS source callsign is looked up from the source DMR radio ID in the
RadioID database. The callsign must be a valid AX.25-style callsign:
1 to 6 alphanumeric characters
optional SSID -0 through -15
If the radio ID cannot be resolved to a valid callsign, IPSC3 stores the GPS
position internally but does not send it to APRS-IS.
The APRS-IS packet format currently generated is:
CALLSIGN>APZVKD,TCPIP*:!DDMM.mmH\DDDMM.mmHYccc/sss IPSC3-DB DMR GPS
Where:
CALLSIGN RadioID lookup result for the DMR source radio ID
APZVKD IPSC3 APRS software identifier
! APRS position without messaging
\Y current configured APRS symbol table/code
ccc/sss optional course/speed if RMC provides both
Example generated APRS-IS packet from the sample position:
VK2FLY>APZVKD,TCPIP*:!3352.48S\15113.24EY338/000 IPSC3-DB DMR GPS
APRS-IS forwarding is rate limited per radio ID. The current default minimum
interval is 60 seconds, configurable in IPSC3. Operationally, radios should
avoid excessive beaconing. VKDMR guidance is not to beacon more often than
every 10 minutes; beaconing more often than every 10 minutes can result in
transmissions being blocked from the network for 1 hour.
APRS over DMR, Motorola LRRP, and OpenGD77 TA-GPS all write into the IPSC3 GPS
position model once a valid position has been decoded. The latest valid fix is
stored by radio ID for roaming and map display. Historical GPS records may also
be stored for later track display and analysis.
Only valid position fixes update the latest GPS position. Status-only Motorola
LRRP responses, such as waiting/no-fix replies, update Motorola LRRP status but
do not overwrite the last valid position.
The APRS over DMR data decoder does not use:
SMS/TMS message text
Motorola ARS packets
Motorola LRRP packets
Motorola BMS packets
OpenGD77 in-band TA-GPS embedded in voice LC
DMR voice embedded LC
group data calls
private voice calls
data types other than 7 for user payload
Those mechanisms are handled by separate IPSC3 code paths or are not part of
this APRS over DMR data protocol.