Motorola LRRP, or Location Request/Response Protocol, is the Motorola data service IPSC3 uses to request and decode GPS positions from Motorola radios that have registered with ARS. This page documents the IPSC3 implementation and field observations. It is practical interoperability documentation, not a complete vendor specification.
waiting state without disturbing the last valid GPS position.IPSC3 handles several GPS mechanisms. They share storage and map display, but they are different protocols:
| Mechanism | Radio Path | IPSC3 Name |
|---|---|---|
| APRS over DMR private data | AnyTone-style private data to the IPSC3 data ID | ANYT / APRS over DMR |
| Motorola LRRP | Motorola private IP/UDP data after ARS registration | ARS plus LRRP GPS |
| OpenGD77 TA-GPS | In-band Talker Alias style GPS during voice | GD77 |
Motorola private data carries an embedded IPv4/UDP payload. IPSC3 currently recognises these UDP service ports:
| Service | UDP Port | Purpose in IPSC3 |
|---|---|---|
| LRRP | 4001 | Location request and location response. |
| ARS | 4005 | Automatic registration, keepalive, and deregistration. |
| TMS/SMS | 4007 | Text message transport and acknowledgement. |
| BMS | 4012 | Battery/status style discovery and partial decode. |
9998.600 seconds.Scheduled Motorola radio-check and LRRP GPS transmissions must not cut across live user traffic. Before transmitting a queued LRRP request or Motorola radio check, IPSC3 checks the target repeater and timeslot for active or very recent activity. If the slot is busy, the request remains pending and the signal worker retries on a later pass.
5 seconds.
IPSC3 generates LRRP requests as Motorola private IP/UDP data, using UDP
source and destination port 4001. The generated LRRP UDP payload
starts with a packet type byte, a length byte, and then a token body.
| Mode | Packet Type | Body Tokens |
|---|---|---|
| Immediate location request | 0x09 | Request ID token 0x22, then 0x33. |
| Triggered/periodic request | 0x09 | Request ID token, location tokens 0x51 0x54 0x62 0x34, trigger interval token 0x31, then encoded interval. |
| Stop triggered request | 0x0F | Request ID token only. |
The request ID token is encoded as:
22 03 aa bb cc
where aa bb cc is the 24-bit request ID. IPSC3 currently uses
the service/source radio ID, normally 9998, as the request ID for
scheduled LRRP polling.
The LRRP UDP payload is wrapped in Motorola private data frames. IPSC3 builds:
The embedded IPv4/UDP packet identifies radio-side and server-side Motorola network addresses. IPSC3 supports a server-source mode and a radio-source mode because different Motorola services and firmware paths have been observed to require different embedded source network styles.
IPSC3 treats these LRRP packet types as response packets:
| Type | IPSC3 Label | Meaning |
|---|---|---|
0x07 | 07-immediate | Immediate response style. |
0x0B | 0B-trigger-start | Triggered report start/status style. |
0x0D | 0D-triggered | Triggered report response. This is the most useful field-tested position response. |
0x11 | 11-trigger-stop | Triggered report stop/status style. |
0x15 | 15-version | Version/status style response. |
IPSC3 scans LRRP response tokens and stores a position only when latitude and longitude are present and within valid ranges. The currently decoded tokens include:
| Token | Decoded Data |
|---|---|
0x22 | Request ID. |
0x34 | LRRP timestamp. |
0x51 | Latitude, longitude, and radius. |
0x55 | Latitude, longitude, radius, and altitude. |
0x56 | Heading/course. IPSC3 currently treats the byte value as two-degree units. |
0x66 | Latitude and longitude point. |
0x69 | Latitude, longitude, and altitude. |
0x6C | Horizontal speed, converted by IPSC3 to knots. |
Latitude and longitude are decoded from Motorola LRRP point tokens using a 32-bit scaled coordinate value. IPSC3 stores decimal degrees internally and keeps the original LRRP packet type and compact payload hex for diagnostics.
A Motorola radio can answer an LRRP request before it has a usable GPS fix.
IPSC3 records this as waiting in the roaming status. If a later
LRRP response contains a valid latitude/longitude pair, IPSC3 changes the
status to fix and updates the radio's GPS position.
waiting updates the ARS/LRRP status display but does not overwrite the last valid GPS position.fix writes the latest position to radio_gps_positions.LRRP status is stored on the roaming row so operators can see whether a Motorola ARS radio has recently answered GPS polling. IPSC3 stores:
waiting or fix
The roaming screen, IPSC3view, and IPSC3qt show Waiting when the
LRRP status is newer than the last valid GPS fix. Once a valid fix arrives,
the normal GPS position display is shown instead.
OpenGD77 in-band TA-GPS is displayed separately with the GD77
badge. IPSC3 can detect this metadata on supported MMDVM voice paths and on
Motorola IPSC voice packets where the decoded Link Control payload contains
the TA-GPS block.
Motorola LRRP fixes use the same APRS-IS worker as other IPSC3 GPS sources. The APRS source callsign is looked up from the DMR RadioID database. If the callsign is valid for APRS, IPSC3 emits an APRS-IS position packet with the IPSC3 software identifier and configured APRS symbol.
APRS-IS forwarding is rate-limited per radio ID and runs outside the live voice path. TCP, DNS, APRS-IS server delays, and database history writes must not block packet routing.