Skip to main content

Application uplink

This section defines the frame format of uplinks sent to the network. The network can be either LoRaWAN or LTE.

Most of the messages are sized to fit the maximum LoRa payload size in the worst case (DR0), which is 51 bytes for EU-868 (repeater compatible). Note that only responses to a query can exceed this limit and restrict the MTU to 63, which may trigger a datarate change if configured in tx_start paramters.

Cellular network​

On cellular network only, the following message header is added:

Bytes [ 0- 7]

Bytes [8-9]

-

b15-0

b7-0

DevEUI

MSB Frame up counter

LSB Frame up counter

Byte 0-1 description

  • DevEUI. Device unique identifier. Used on cellular networks to discriminate the device which sent the uplink. For convenience, it is identical to the LoRaWAN DevEUI.

  • Frame up counter. Uplink frame counter. Incremented for each uplink. It wraps to 0 after reaching 65535. It is an emulation of the LoRaWAN uplink frame counter and serves the same purpose: to be able to detect and quantify uplink packet loss when using UDP transport.

Message header​

The uplinks are structured with a common header followed by a data section. The data section varies depending on the type of uplink.

Basic header​

The basic header has 4 bytes and is present in both single-frame and multi-frame modes.

Byte 0

Byte 1

Bytes [2-3]

b7

b6

b5-3

b2-0

b7

b6-0

b15-0

b7-0

M

S

Type

ACK-TK

F

Battery %

MSB timestamp

LSB timestamp

Byte 0 description

  • M. Multi-frame (0: single frame; 1: multi-frame).
    • 0 - Single frame.
    • 1 -- Multi-frame
  • S. SOS.
    • 0 --SOS mode not active
    • 1 -- SOS mode active
  • Type. Frame type.:
    • 1 -- Notification. Unsolicited message (System start, Critical/normal temperature, motion start/stop, SOS start/stop, geozoning, battery alert, etc.).
    • 2 -- Position. Unsolicited message. Geolocation positions.
    • 3 -- Query. Expects a response from the network (aiding position request, almanac request, etc.).
    • 4 -- Response: Solicited message. Response to network query (config get/set, POD, Almanac get/set, etc.).
    • Other values: Reserved for future use.
  • ACK-TK: Ack-token. Value (in [0..7]) extracted from the last downlink received. It is used to acknowledge the corresponding downlink.

Byte 1 description

  • F. Free for use
  • Battery: Remaining battery capacity expressed as percentage of full capacity. Special values:
    • 0: in charge
    • 127: unknown. Byte 2 -- 3 contains the timestamp indicating when the payload was generated. The value represents the number of seconds elapsed since the start of the most recent half-day period (a value of 0 corresponds to either noon or midnight).

Extended header​

This header is used when an application message needs to be fragmented to multiple uplinks ("multi-frame" case).

It consists of a basic header (with M = 1) extended with an extra byte called m-frame.

Bytes [0-3]

Byte 4

Basic header with M=1

Group

m-frame

 

b7-5

b4

b3-0

Group ID

Last

Fragment number

Byte 4 description

  • Group ID. Group identifier [0..7]. It is incremented each time a new group of uplinks are sent. It is used to uniquely identify a group. It should be used to avoid mixing uplinks belonging to two different groups.

  • Last. Set to 1 to indicate the last uplink in the group.

  • Fragment number. Fragment identifier inside a group [0..15]. It starts at 0 (first uplink) and is incremented for each subsequent uplinks belonging to the same group.

Notifications​

This section describes the notification uplinks.

Overview​

The notifications are categorized into classes, with each class containing different types. The class of notification allows a simple mechanism (and configuration) for requesting network acknowledgments: A user may require some classes of notifications to be acknowledged by the network.

The format of a notification is the following

Bytes [0-3]

Byte 4

Bytes [5-variable]

Basic header (Type =1)

Notification header

Data

 

b7-4

b3-0

 

 

Class

Type

 

Notification header

  • Class: Class of notification
  • Type: Type of notification

The classes and types are presented below

Class 0. System

Type

Name

Purpose

Data

0

Status

System status

Versions, temperature, reset cause (in case of crash)

1

Low-battery

Low battery detected

Consumption + battery voltage

2

BLE

BLE securely connected

Securely connected/disconnected

3

Tamper

Tamper detection

Casing open/closed

Class 1. SOS

Type

Name

Purpose

Data

0

SOS-on

SOS activated

None

1

SOS-off

SOS deactivated

None

Class 2. Temperature

Type

Name

Purpose

Data

0

Temp_high

Critically high temperature reached

Temperature

1

Temp_low

Critically low temperature reached

Temperature

2

Temp_normal

Temperature back to normal

Temperature

Class 3. Accelerometer

Type

Name

Purpose

Data

0

Motion_start

Motion start detected

None

1

Motion_end

Motion end detected

Acceleration vector + motion percent

2

Shock

Shock detected

Acceleration vector + GADD index + nb shock

Class 4. Network

Type

Name

Purpose

Data

0

Main_up

Main network is up.

Network data

1

Backup_up

Main network down. Backup is up.

Network data

Class 5. Geozoning 

Type

Name

Purpose

Data

0

Entry

Entry beacon detected

Beacon ID or MAC address

1

Exit

Exit beacon detected

Beacon ID or MAC address

2

In_hazard

Entry in a hazardous area detected

Beacon ID or MAC address

3

Out_hazard

Exit from a hazardous area detected

Beacon ID or MAC address

4

Meeting_point

Meeting point detected

Beacon ID or MAC address

System status notification​

The status is transmitted with a common section and a page section. Pages are used to publish information that does not require frequent updates, using a round robin method. Each time a status notification is sent, the page number increments until the last page is reached. Once the last page is sent, the page identifier resets to 0.

Common part

1 byte

1 byte

Current temperature

Reset cause and page ID

b7- 0

b7-3

b2-0

[-126 .. +127]

Reset cause

Page ID

Note

  • Current temperature. Current temperature. Signed integer (2's complement) expressed in degree Celsius.

  • Reset cause:

    • AOS_ERROR_NONE (0) : No error.
    • AOS_ERROR_HW_NMI (1): Hardware non-maskable interrupt fault.
    • AOS_ERROR_HW_FAULT (2): Hardware fault.
    • AOS_ERROR_HW_MPU (3): Hardware MPU fault.
    • AOS_ERROR_HW_BUS (4): Hardware bus fault.
    • AOS_ERROR_HW_USAGE (5): Hardware usage fault.
    • AOS_ERROR_HW_IRQ (6): Unexpected interruption.
    • AOS_ERROR_HW_WDOG (7): Watchdog
    • AOS_ERROR_HW_BOR(8): Brown out reset
    • AOS_ERROR_SW_ST_HAL_ERROR(9): ST HAL error.
    • AOS_ERROR_SW_FREERTOS_ASSERT (10): FreeRTOS assertion.
    • AOS_ERROR_SW_FREERTOS_TASK_OVF (11):FreeRTOS Task stack overflow.
    • AOS_ERROR_SW_BLE_ASSERT(12). BLE core assertion
    • AOS_ERROR_SW_RTC_FAIL (13): Real Time Clock peripheral fails to start.
    • AOS_ERROR_SW_LORA_FAIL (14): LoRa unrecoverable failure
    • AOS_ERROR_SW_DEBUG (15): Used to debug
    • AOS_ERROR_SW_APP_START (16): Application assertions.

  • Page Id

    • Max page ID = 1 for LoRaWAN only trackers (2 pages).
    • Max page ID= 3 for Cellular Combo tracker (4 pages).

Page 0. General status

3 bytes

4 bytes

3 bytes

2 bytes

AT3 version

Configuration version

LR-HW version

HW batch ID

b23-16

b15-8

b7-0

b31-24

b23-16

b15-8

b7-0

b23-16

b15-8

b7-0

b15-8

b7-0

M

m

i

M

m

i

u

HW

type

FW

MSB

LSB

2 bytes

1 byte

1 byte

1 byte

2 bytes

2 bytes

HW BOM ID

Max

temperature

Min temperature

Motion %

Battery

voltage (mV)

Total

consumption (mAh)

b15-8

b7-0

b7-0

b7-0

b7-0

b15-8

b7-0

b15-8

b7-0

MSB

LSB

[-126 .. +127]

[-126 .. +127]

[0..100]

MSB

LSB

MSB

LSB

2 bytes

2 bytes

2 bytes

2 bytes

2 bytes

2 bytes

Cellular

consumption (mAh)

GNSS

consumption (mAh)

WIFI

consumption (mAh)

LR GNSS

consumption (mAh)

BLE

consumption (mAh)

MCU

consumption (mAh)

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

MSB

LSB

MSB

LSB

MSB

LSB

MSB

LSB

MSB

LSB

MSB

LSB

Notes

  • M: AT3 major version (for firmware version and configuration version)
  • m: AT3 minor version (for firmware version and configuration version)
  • i : AT3 iteration (for firmware version and configuration version)
  • u: AT3 configuration user byte
  • HW: Hardware version
  • Type: Type of hardware
  • FW: Firmware version
  • Max temperature. Max temperature since the beginning of the product life. Signed integer (2's complement) expressed in degree Celsius.
  • Min temperature. Min temperature since the beginning of the product life. Signed integer (2's complement) expressed in degree Celsius.
  • Battery voltage: Current battery voltage **(**mV)
  • Consumption fields. All consumption fields are in mAh

Page 1. Almanac status

2 bytes

4 bytes

1 byte

2 bytes

5 byte

1 byte

LR1110

 GPS

date

LR1110

 GPS

 outdated

LR1110

 GPS

 good

LR1110

 BEIDOU

date

LR1110 BEIDOU

outdated

LR1110 BEIDOU

good

b15-8

b7-0

b31-0

b7-0

b15-8

b7-0

b39-0

b7-0

MSB

LSB

Bit field

[0..31]

MSB

LSB

Bit field

[0-37]

2 bytes

4 bytes

1 byte

2 bytes

5 byte

1 byte

GNSS

 GPS

date

GNSS

 GPS

 outdated

GNSS

 GPS

 good

GNSS

 BEIDOU

date

GNSS

 BEIDOU

outdated

GNSS BEIDOU

good

b15-8

b7-0

b31-0

b7-0

b15-8

b7-0

b39-0

b7-0

MSB

LSB

Bit field

[0..31]

MSB

LSB

Bit field

[0-37]

Notes

  • LR1110/GNSS GPS almanac date. Highest date ( GPS week number) over all GPS almanac entries.
  • LR1110/GNSS GPS outdated. Bitmap of outdated entries in the GPS almanac.
  • LR1110/GNSS GPS good. Number of entries matching the highest date.
  • LR1110/GNSS BEIDOU almanac date. Highest date ( GPS week number) over all BEIDOU almanac entries.
  • LR1110/GNSS BEIDOU outdated. Bitmap of outdated entries in the BEIDOU almanac.
  • LR1110/GNSS BEIDOU good. Number of entries having the highest date.

Each bit i of the bitmap represents satellite i (1 << i).

Page 2. Cellular part I

6 bytes

 21 bytes

16 bytes

FW version

ICCID

IMSI

b47-40

b39-32

b31-24

b23-16

b15-0

Ascii

Ascii

branch

mode

image

delivery

release

 

 

Note that the ICCID and IMSI are available only if a cellular connection has been established. Otherwise, these values are set to 0.

Page 2. Cellular part II

33 bytes16 bytes
EUICCIDIMEISV
AsciiAscii

Notes

  • The EUICCID is available only if a cellular connection using the eSIM has been established. Otherwise, this value is set to 0 (33 null bytes).
  • The IMEISV is not yet supported. It is set to a null value (16 NULL bytes).

Low battery

2 bytes

2 bytes

Consumption

Battery voltage

b15-8

b7-0

b15-8

b7-0

MSB

LSB

MSB

LSB

Notes

  • Consumption is in mAh
  • Battery voltage is in mV

BLE

1 bytes

State

b7-1

b0

RFU

state

Notes

  • State: 0: Disconnected, 1: Connected
  • RFU: Reserved for future use

Tamper

1 bytes

State

b7-1

b0

RFU

state

Notes

  • State: 0: Casing closed, 1: Casing open
  • RFU: Reserved for future use

Class SOS​

No data. The SOS status is in the basic header.

Class temperature​

Critical temperature high/low/normal

The 3 types of notification are : Critically high temperature / Critically low temperature / Return to normal temperature range

Each of these notifications includes the temperature which triggered the notification.

1 byte
Temperature
b7-0
[-126 .. +127]

The temperature is signed (2's complement coding) and is in degrees Celsius.

Class accelerometer​

The data part of this notification class depends on the type.

Motion start

No data

Motion end

2 bytes

2 bytes

2 bytes

1 byte

Acceleration X

Acceleration Y

Acceleration Z

Motion %

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

b7-0

MSB

LSB

MSB

LSB

MSB

LSB

[0..100]

The 3 axis measurement of gravity after the device has stopped allows to infer the angular position of the device. They are expressed as mg signed values (2's complement coding)

Shock

2 bytes

2 bytes

2 bytes

1 byte

1 byte

Acceleration X

Acceleration Y

Acceleration Z

GADD index

Nb shocks

b15-8

b7-0

b15-8

b7-0

b15-8

b7-0

b7-0

b7-0

MSB

LSB

MSB

LSB

MSB

LSB

[0..100]

[1-255]

The 3 axis measurement of maximum shock accelerations are expressed in mg signed values (2's complement coding), allowing to infer the direction of the shock.

Body damage is more accurately represented by the Gadd index, which integrates acceleration intensity over total shock duration.

Class network​

The data part of this class of notifications does not depend on the type and is the following:

1 byte1 byte1 byte
Active networkMain networkbackup network
b7-0b7-0b7-0
[0..2][0..2][0..2]

Each byte encodes a network technology:

  • 0: No network
  • 1: LoRaWAN network
  • 2: Cellular network in low power mode
  • 3: Cellular network in high power mode

Class geozoning​

Not yet supported

Positions​

The position messages can be sent in either single-frame mode or multi-frames mode.

Position header​

The basic position header is defined as follows:

Single frame mode

Bytes [0-3]Byte 4Bytes [7-variable]
Basic header (Type = 2)Position headerData

Multi-frame mode

Bytes [0-4]Byte 5Bytes [8-variable]
Extended header (Type = 2)Position headerData

The position header is defined as follows:

Position header 4 bytes

Information

Extended info

Triggers (2 bytes)

b7

b6-5

b4-0

b7-4

b3-0

b15-b0

M

Status

Position type

RFU

M-cnt

Trigger bit-map

Position header

Information

  • b7: M. Motion bit. Set if a motion event has been detected since the transmission of the previous position payload.
  • b6-5: Status. Status of the position
    • 0 -- Success. Data contains the position.
    • 1 -- Timeout. Max time allowed to acquire the position. Optional data.
    • 2 -- Failure. Position acquisition failed for other reasons. Data contains failure reason or no data.
    • 3 -- Not-solvable: The acquisition has been done but is not solvable (WIFI or BLE). Optional data.
  • b4-0: Position type
    • 0 -- LR1110 GNSS formatted Nav1
    • 1 -- LR1110 GNSS Semtech Nav1
    • 2 -- LR1110 GNSS Semtech Nav 2
    • 3 -- WIFI
    • 4 - BLE scan1 (report mode: MAC-address)
    • 5 -- BLE scan1 (report mode: Short IDs)
    • 6 -- BLE scan1 (report mode Long IDs)
    • 7 - BLE scan2 (report mode: MAC-address)
    • 8 -- BLE scan2 (report mode: Short IDs)
    • 9 -- BLE scan2 (report mode Long IDs)
    • 10 - MT3333 GNSS fix
    • 11 -- MT3333 LP-GNSS

Extended info

  • b7-4: RFU (Reserved For Future Use)
  • b3-0: M-cnt. 4-bit motion counter. Increments if a motion event has been detected since the transmission of the previous position payload. The counter rolls over once the max value is reached.

Note:

This 4-bit motion counter allows the geolocation back-end application to detect whether there has been motion between 2 successive
geolocation uplinks by comparing the value of the motion counter with its previously received value. This works even if we have lost up to
14 consecutive in-motion uplinks, and any number of static uplinks.
This enables the static position averaging filters to reset properly
if the location of the tracker has changed.

In order to work properly, a reliable deduplication algorithm should
be implemented in order to avoid comparing the counter value with the same value from a packet transmitted multiple times (custom
retransmit policy). In AT3, this can be based on the value of the
basic header 2-byte timestamp field.

Trigger

Bit-field providing the geolocation triggers that were active for this position. Refer to the geolocation manager section for the bit meaning.

LR1110 GNSS Formatted Nav1​

This position message can carry up to 10 satellite information. The multi-frame format can be used. In this case each frame carries a single scan.

2 bytes

4 bytes

4 bytes

Time

Sat 1 info

Sat 2 info

-

b31-30

b29-24

b23-22

b21-19

b18-0

Same as sat 1

-

C

ID

CN

000

PRN

Same

Time : LR1110 SW Time in step of 16 seconds.

Sat x info

  • b31-30: C. Constellation:
    • 0 -- GPS
    • 1 -- BEIDOU
    • 2, 3 - Spare
  • b29-24: ID. Satellite identifier starting at 0 regardless the constellation type.
  • b23-22: CN. Carrier to noise information
    • 0 -- C/N greater than 45 dB
    • 1 -- C/N in range [41.. 45] dB
    • 2 - C/N in range [37..41] dB
    • 3 - C/N less than 37 dB
  • b21-19: Unused. Set to 0
  • b18-0: PRN. Pseudo range value

To fit the LoRaWAN maximum payload size in the worst condition, the number of satellites info should be limited to 10.

LR1110 GNSS Semtech Nav1​

The data part is the actual data payload received from the LR1110. It is encoded and only Semtech (or licensed users like Abeeway) can decode it. It should be forwarded as-is to the Semtech cloud.

Note that the number of sniffed satellites should be set appropriately to allow LoRaWAN transmission with low data rate (DR0 -- DR2 for Europe).

The multi-frame format can be used. In this case each frame carries a single scan.

LR1110 GNSS Semtech Nav2​

The data part is the actual data payload received from the LR1110. It is encoded and only Semtech (or licensed users like Abeeway) can decode it. It should be forwarded as-is to the Semtech cloud.

The multi-frame format can be used. In this case each frame carries a single scan.

WIFI​

This uplink message can carry up to 6 BSSIDs per frame. To carry more BSSIDs, the multi-frame will be used if the payload size requires it.

Payload format

7 bytes

7 bytes

BSSID 1 info

BSSID 2 info

MAC address (6 bytes)

1 byte

Same as BSSID 1

MSB

 

 

 

 

LSB

RSSI

Same

Note

The RSSI is a negative value (2's complement) carrying the Received Signal Strength Information (in dB).

To fit the LoRa maximum payload size in the worst condition, the number of BSSI per frame is limited to 6. Above this value, the multi-frame is used.

BLE scan. MAC address​

This uplink message can carry up to 6 beacon information per frame. To carry more beacons, the multi-frame can be used.

Payload format

7 bytes

7 bytes

Beacon 1 info

Beacon 2 info

Identifier (6 bytes)

1 byte

Same as Beacon 1

MSB

 

 

 

 

LSB

RSSI

Same

Notes

  • The identifier is the MAC address if the report type is MAC address, otherwise it is 6 bytes extracted as the beacon identifier.
  • The RSSI is a negative value (2's complement) carrying the Received Signal Strength Information (in dB).
  • To fit the LoRaWAN maximum payload size in the worst condition, the number of Beacon info per frame is limited to 6. Above this value, the multi-frame is used.

BLE scan. Short ID​

This uplink message can carry up to 14 beacon information fields per frame. To carry more beacons, the multi-frame can be used.

Payload format

3 bytes

3 bytes

3 bytes

Beacon 1 info

Beacon 2 info

Beacon 3 info

Beacon ID (2 bytes)

1 byte

Same as beacon 1

Same as beacon 1

MSB

LSB

RSSI

Same as beacon 1

Same as beacon 1

Note

The RSSI is a negative value (2's complement) carrying the Received Signal Strength Information (in dB).

To fit the LoRaWAN maximum payload size in the worst conditions, the number of Beacon info per frame is limited to 14. Above this value, the multi-frame is used.

BLE scan. Long ID​

This uplink message can carry up to 2 beacon information fields per frame. To carry more beacons, the multi-frame format can be used.

Payload format

17 bytes

17 bytes

Beacon 1 info

Beacon 2 info

Beacon ID (16 bytes)

1 byte

Same as Beacon 1

MSB

 

 

 

 

LSB

RSSI

Same

Note

The RSSI is a negative value (2's complement) carrying the Received Signal Strength Information (in dB).

To fit the LoRaWAN maximum payload size in the worst condition, the number of Beacon info per frame is limited to 2. Above this value, the multi-frame is used.

MT3333 GNSS fix​

This uplink message carries a GNSS fix or the GNSS satellites tracking if the fix failed.

Payload format in case of success

4 bytes

4 bytes

2 bytes

2 bytes

2 bytes

1 byte

1 byte

Latitude

Longitude

Altitude

COG

SOG

EHPE

Quality

MSB

 

 

LSB

MSB

 

 

LSB

MSB

LSB

MSB

LSB

MSB

LSB

-

-

Notes

  • The latitude the longitude are signed value (2's complement) and expressed with a unit of 10^-7^ degree.
  • The altitude is signed and expressed in meters.
  • COG: Course Over Ground expressed in 1/100 of degrees
  • SOG: Speed Over Ground expressed cm/second
  • EHPE is encoded as follows:
Coded valueEHPE in meters
0 – 2500 – 250 meters
251250 < EHPE < 500
252500 < EHPE < 1000
2531000 < EHPE < 2000
2542000 < EHPE < 4000
255EHPE > 4000
  • Quality: Fix quality coded as follow:
    • Bits b7-5: Quality:
      • 0 -- invalid: The GNSS gave a fix but consider it as invalid
      • 1 -- valid: The GNSS gave a fix but has no idea if it is a 2D or 3D
      • 2 -- fix 2D: Fix valid for 2 dimension (latitude and longitude valid).
      • 3 -- fix 3D Fix valid for 3 dimension (latitude, longitude and altitude valid).
    • Bits b4-0: Number of satellites used for the fix. Max 12

Payload format in case of failure or timeout

1 byte

2 bytes

2 bytes

...

Status

Sat 0

Sat 1

...

-

svId

Info

svId

Info

...

Notes

  • The Status field is coded as follow:

    • b7 -- b5: Cause

      • 0: T0 timeout

      • 1: T1 timeout

      • 2: acquisition timeout

    • b4 -- b0: Number of satellites seen.

  • The info field is coded on 1 byte and is formatted as follow:

    • b7-b6: Constellation

      • 0: GPS

      • 1: GLONASS

      • 2: BEIDOU

      • 3: GALILEO

    • b5-0: C/N0 in dBm

MT3333 LP-GNSS​

This position message can carry up to 9 satellites information fields. The multi-frame format can be used. In this case each frame carries a single scan.

4 bytes

4 bytes

4 bytes

Time

Sat 1 info

Sat 2 info

-

b31-30

b29-24

b23-22

b21-0

Same as sat 1

-

C

ID

CN

PRN

Same

Time : MT333 SW Time (TOW) in microseconds. It is sent MSB first (big endian).

Bits31 - 2019 - 0
DescriptionNb seconds in the hourNb microseconds

Sat x info. Coded the same way than LR1110 NAV1 (with bit 21-19 used).

  • b31-30: C. Constellation:

    • 0 -- GPS
    • 1 -- BEIDOU
    • 2, 3 - Spare

  • b29-24: ID. Satellite identifier starting at 0 regardless the constellation type.

  • b23-22: CN. Carrier to noise information

    • 3 -- C/N greater than 34 dB
    • 2 -- C/N in range [28.. 33] dB
    • 1 - C/N in range [22..27] dB
    • 0 - C/N less than 21 dB

  • b21-0: PRN. Pseudo range value. Coded for a full scale of 1ms shifted by 2 to the right.

Query​

These messages expect a response. They are always sent in single-frame mode.

The queries are formatted as follows.

Bytes [0-3]Byte 4Bytes [5-variable]
Basic header (Type = 3)Query headerData

Query header

  • b7-b5: Spare bits
  • b4-0: Query type:
    • 0 -- Aiding-position. The aiding position is needed by the tracker. No data.
    • 1 -- Update system time. The system time update is needed. No data
    • 2 -- Update GPS almanac. GPS almanac entries need to be refreshed. Data contains the list of satellites for which the update is needed.
    • 3 -- Update BEIDOU almanac. BEIDOU almanac entries need to be refreshed. Data contains the list of satellites for which the update is needed.

Note

The tracker system time update could be done using the appropriate LoRa MAC request. However, remind that the application messages should not be based on the underlying transport protocol.

Update GPS almanac​

Several satellites may be requested at a time, The data part is a list of satellite identifiers defined as follow:

1 Byte1 Byte...
SV ID1 1 [0..31]SV ID 2 [0..31]...

Notes

  • SV ID means Space Vehicle identifier. First satellite identifier is 0.
  • Due to the limited payload size on the LoRa network (EU868, DR0-2, Max: 59 bytes), only 3 entries can be updated in a downlink. So the number of almanac entries requested in a single request is limited to 3.

Update BEIDOU almanac​

Several satellites may be requested at a time, The data part is a list of satellite identifiers defined as follow:

1 Byte1 Byte...
SV ID1 [0..34]SV ID 2 [0..34]...

Note

  • SV ID means Space Vehicle identifier. First satellite identifier is 0.
  • Due to the limited payload size on the LoRa network (EU868, DR0-2, Max: 59 bytes), only 3 entries can be updated in a downlink. So the number of almanac entries requested in a single request is limited to 3.

Response​

These messages carry the responses to network requests. Multi-frames format can be used.

Single frame mode

Bytes [0-3]Byte 4Bytes [5-variable]
Basic header (Type = 4)Response headerData

Multi-frame mode

Bytes [0-4]Byte 5Bytes [6-variable]
Extended header (Type = 4)Response headerData

Response header

  • b7-b5: Spare bits
  • b4-0: Response type
    • 0 -- Answer of a generic configuration set request.
    • 1 -- Answer of a parameter class configuration set request.
    • 2 -- Answer of a generic configuration get request.
    • 3 -- Answer of a parameter class configuration get request.
    • 4 -- Answer of a BLE connectivity status request.

Response to a generic configuration set request.​

The data part consists of up to 16 parameters can be acknowledged at a time.

 3 Bytes

3 Bytes

...

C-ID

L-ID

Status

C-ID

L-ID

Status

...

Notes

  • C-ID. Parameter class identifier
  • L-ID: Local parameter identifier
  • Status. Local status for the parameter.
    • 0 -- Success
    • 1 -- Not found
    • 2 -- Below lower bound. For string and byte-array, length below the minimum
    • 3 -- Above higher bound. For string and byte-array, length above the maximum
    • 4 -- Bad value. Value in acceptable range but not is not supported.
    • 5 - Type mismatch
    • 6 -- Operation error (operation failure)
    • 7 -- Read-only variable.

Response to a parameter class configuration set request​

The data part consists of up to 24 parameter status fields.

1 byte

 2 Bytes

2 Bytes

...

C-ID

L-ID

Status

L-ID

Status

...

Notes

  • C-ID. Parameter class identifier
  • L-ID: Local parameter identifier
  • Status. Local status for the parameter.
    • 0 -- Success
    • 1 -- Not found
    • 2 -- Below lower bound. For string and byte-array, length below the minimum
    • 3 -- Above higher bound. For string and byte-array, length above the maximum
    • 4 -- Bad value. Value in acceptable range but not is not supported.
    • 5 - Type mismatch
    • 6 -- Operation error (operation failure)
    • 7 -- Read-only variable.

Response to a generic configuration get request​

The data part consists of a list of parameters belonging to any classes. The multi-frame format can be used. Note that for some parameters, the size is variable. So it is advised to avoid requesting too many parameters at a time.

Parameter entry description

Parameter entry

…

 3 Bytes

Variable

...

C-ID

L-ID

S/T

Data

...

Notes

  • C-ID Parameter class identifier
  • L-ID: Local parameter identifier
  • S/T: Parameter size and type
    • Bit 7-3: Variable size
    • Bit 2-0: type
      • 0 -- Deprecated.
      • 1 -- Integer 32 bits
      • 2 -- Floating point (4 bytes)
      • 3 -- ASCII string
      • 4 -- Byte array
      • 5 - Error
  • Data: Variable data part
    • Deprecated. No data.
    • Integer 32 bits. 4 bytes in big endian (MSB first)
    • Floating point. Single precision, 4 bytes n big endian (MSB first)
    • ASCII string. Max 31 characters. It does not include the NULL char.
    • Byte array. Max 32 bytes. For 32 bytes, the parameter size will be 0.

Response to a parameter class configuration get request​

The data part consists of a list of parameters belonging to any classes. The multi-frame format can be used. Note that for some parameters, the size is variable. So it is advised to avoid requesting too many parameters at a time.

The data part starts with the parameter class identifier and is followed by a list of parameter entries.

Common

Parameter entry 1

Parameter entry 2

…

1 Byte

 2 Bytes

Variable

 2 Bytes

Variable

...

C-ID

L-ID

S/T

Data

L-ID

S/T

Data

...

Notes

  • C-ID. Parameter class identifier
  • L-ID: Local parameter identifier
  • S/T Parameter size and type.
    • Bit 7-3: Parameter size
    • Bit 2-0: type
      • 0 -- Deprecated
      • 1 -- Integer 32 bits
      • 2 -- Floating point (4 bytes)
      • 3 -- ASCII string
      • 4 -- Byte array
      • 5 - Error
  • Data: Variable data part
    • Deprecated. No data
    • Integer 32 bits. 4 bytes in big endian (MSB first)
    • Floating point. Single precision, 4 bytes n big endian (MSB first)
    • ASCII string. Max 31 characters. It does not include the NULL chan.
    • Byte array. Max 32 bytes. For 32 bytes, the parameter size will be 0.

Response of a system status request​

The response data format looks is identical to the status notification format, see section System status notification.

Response to a get GPS almanac entry request​

The multi-frame can be used to answer the GPS almanac entries. The data part is as follows:

Almanac entry 1

Almanac entry 2

...

 2 bytes

16 bytes

2 bytes

16 bytes

…

Date

Data-entry 1

Date

Data-entry 2

...

Notes

  • Date: Number of days since April 7^th^ 2019.
  • Data-entry is formatted as follow:

Almanac Entry

 1 byte

15 bytes

SV ID

Almanac data

  • SV-ID: Satellite identifier in the GPS constellation. Start at 0.

Response of a get BEIDOU almanac entry request​

TO BE DONE.

Response to a set GPS almanac entry request​

The multi-frame format can be used to provide the GPS almanac entries. The data part is as follows:

Almanac entry 1

Almanac entry 2

...

 2 bytes

16 bytes

2 bytes

16 bytes

…

Date

Data-entry 1

Date

Data-entry 2

...

Notes

  • Date: Number of days since April 7^th^ 2019.
  • Data-entry is formatted as follow:

Almanac Entry

 1 byte

15 bytes

SV ID

Almanac data

  • SV-ID: Satellite identifier in the GPS constellation. Start at 0.
Last updated on