58: Message Box
Message Box keeps up to 1024 bytes of server-managed data cached on the device for a connected application. GET reads the local cache, SUBSCRIBE delivers later cache updates, and SET replaces or clears the cached bytes.
Applies to Viper devices only
Unsupported products
The cached feature requires supporting firmware. Unsupported products return Not Supported (Status header 4, code 7). Independent Transmit Now uploads are documented separately below and do not imply support for the cached feature.
How syncing works
The device reports its cached-message checksum during a tracking session. If a completed session contains a valid report and the server's configured data has a different checksum, the server can send a version 2 SET with the desired bytes. Unconfigured or invalid server data leaves the cache unchanged; an explicitly configured empty payload requests a clear. When the device accepts the SET, it replaces the cache, saves it when persistent storage is enabled, and publishes to current subscribers. GET reads this local cache; subscribing does not itself fetch data from the server. Later tracking-session reports let the server check the reported cache checksum and offer the update again if it still differs. Sending an update or receiving an ACK alone does not confirm that the cache is synchronized.
2026-10 formatCurrent
Complete payload and CRC-16 format. GET and SUBSCRIBE explicitly select wire Message Version 2 with header 22; omitting it selects the legacy format. SET requires 2.
Message fields
Fields specific to Message Box. Operation sections below explain when each field is used.
| Field | Type | Description |
|---|---|---|
| CRCField 2 | uint16 | CRC-16/XMODEM of the cached payload (polynomial 0x1021, initial value 0x0000, no input or output reflection, final XOR 0x0000), separate from the outer message-frame CRC. Returned in version 2 responses and tracking-session messages, including an empty cache as zero (0x0000). Optional and ignored in SET; the device calculates it from field 129. One- or two-byte little-endian encoding may omit a high zero byte. Implemented only on Viper devices. |
| Full PayloadField 129 | bytes | Complete message-box bytes in SET requests, GET responses, and subscription updates (up to 1024 bytes). SET must include this field; an explicit zero-length value clears the cache. Uses an extended-length field with a uint16 little-endian length prefix. Tracking-session uploads may use this field for independent Transmit Now data instead. |
Read the cached message
GET chooses its own response format, regardless of the selected subscription format. A successful GET returns MT58 directly, rather than a separate success ACK.
Select the complete extended payload and its CRC-16/XMODEM.
Request
No payload fields are needed.
Request headers
- MethodHeader 5
uint8requiredValue
2· GETRequest a service to be perform an action
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2A one-byte value of 2 selects version 2.
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
Expected response (MT58)
Cached payload
A successful GET returns this MT58 payload. An unsuccessful request returns MT5 (ACK) with Status instead.
Correlation, status and acknowledgment rules
Response-specific headers
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2Identifies the format of this response payload.
Response data fields
- CRCField 2
uint16requiredDevice-calculated CRC-16/XMODEM of the cached payload, including 0 for an empty cache. One- or two-byte little-endian encoding may omit a high zero byte.
- Legacy ChecksumField 1
uint16omittedThe legacy additive checksum is absent from version 2 responses.
- Full PayloadField 129
bytesoptionalMaximum 1024 bytesComplete cached payload in an extended-length field with a uint16 little-endian length prefix. Empty payload data is omitted.
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
4Invalid Parameter- Invalid Parameter: a decoded Message Version value above 2.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Replace or clear the cached message
Every accepted SET updates the cache, writes it to persistent storage when enabled, and publishes to current subscribers, even for identical bytes. SET does not change the selected subscription format.
Request
Message Version 2 and field 129 are required. The device calculates the payload CRC; the outer message-frame CRC protects the SET request itself. Optional supplied checksum fields 1 and 2 are ignored.
Request headers
- MethodHeader 5
uint8requiredValue
1· SETRequest a service to be perform an action
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2A one-byte value of 2 selects version 2.
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
Request data fields
- Full PayloadField 129
bytesrequiredMaximum 1024 bytesComplete new cache bytes. An explicit zero-length field clears the cache; omitting the field is an error. Extended-length encoding uses a uint16 little-endian length prefix.
Expected response (MT5 - ACK)
For a request with a nonzero Message ID, successful SET returns an ACK. It does not return the cached bytes; subscriber publications are separate asynchronous messages and are not this reply.
Correlation, status and acknowledgment rules · MT5 packet format
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
2Missing Parameter- Missing Parameter: field 129 is absent.
4Invalid Parameter- Invalid Parameter: Message Version is missing, malformed-width, or any value other than 2; or field 129 exceeds 1024 bytes.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Subscribe to cached-message updates
The latest valid SUBSCRIBE selects one shared format for all Message Box publications, not a format per subscriber. A decoded version above 2 leaves both the existing format selection and subscription unchanged. Control acknowledgment and later publications are distinct messages.
Explicit version 2 selects the shared extended-payload and CRC publication format.
Request
Request headers
- MethodHeader 5
uint8requiredValue
3· SUBSCRIBERequest a service to be perform an action
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2A one-byte value of 2 selects version 2.
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
- IntervalHeader 6
uint32optionalOptional publication interval in milliseconds. If omitted, updates are sent when new data is available.
- DurationHeader 7
uint32optionalSubscription duration in milliseconds; 0 is indefinite until explicitly unsubscribed.
- Message LevelHeader 16
uint8optionalMinimum publication level.
1· Info-Watch: Receive all messages if and when available, without explicitly requesting that the underlying hardware be turned on.2· Info-Auto: Receive all messages and explicitly request underlying hardware be activated to provide the requested data where needed10· Valid: Activate the relevant hardware but only receive valid data. May be used with subscription timeout feature to request usable data without leaving the hardware on indefinitely
- Subscription IDHeader 17
uint8[]optionalSubscription ID; omit for the default subscription (0). Use the same ID when unsubscribing.
Expected response (MT5 - ACK)
For a request with a nonzero Message ID, successful SUBSCRIBE returns a control ACK confirming the subscription request only. It does not contain the cache. Success ACKs are suppressed for an omitted or zero Message ID; error ACKs are not suppressed for this reason. Updates arrive as asynchronous MT58 publications, not as direct replies to SUBSCRIBE.
Correlation, status and acknowledgment rules · MT5 packet format
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
4Invalid Parameter- Invalid Parameter: a decoded Message Version value above 2; existing selection and subscription are unchanged.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Later publication (MT58)
Cached payload update
Version 2 updates include Message Version 2 and field 2. Field 129 carries the complete cached payload when nonempty; empty payload data is omitted.
Publication headers
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2A one-byte value of 2 selects version 2.
- Response toHeader 3
uint32omittedThis is an asynchronous publication, not a direct reply to the SUBSCRIBE request.
- Subscription IDHeader 17
uint8[]optionalIdentifies nonzero subscription IDs for this publication.
Publication data fields
- CRCField 2
uint16requiredDevice-calculated CRC-16/XMODEM of the cached payload, including 0 for an empty cache. One- or two-byte little-endian encoding may omit a high zero byte.
- Legacy ChecksumField 1
uint16omittedThe legacy additive checksum is absent from version 2 responses.
- Full PayloadField 129
bytesoptionalMaximum 1024 bytesComplete cached payload in an extended-length field with a uint16 little-endian length prefix. Empty payload data is omitted.
Tracking-session uploads
A separate device-to-server context, not a GET response or subscription update. Tracking-session messages always use Message Version 2. Field 129 may carry independent Transmit Now upload data, not the cached down-synced payload. Cached-message CRC reporting is Viper-only. Independent Transmit Now uploads can use MT58 without cached Message Box support; those upload-only messages omit field 2.
Target Viper or Transmit Now upload-enabled firmware
Device upload (MT58)
When Message Box support is enabled, field 2 reports the cached-message CRC, including 0 for an empty cache. Independent upload bytes in field 129 do not form part of that cached-message CRC.
Upload headers
- Message VersionHeader 22
uint8requiredMaximum 1 bytesValue
2A one-byte value of 2 selects version 2.
Upload data fields
- CRCField 2
uint16optionalPresent when Message Box support is enabled: CRC-16/XMODEM of the cached down-synced message, not a checksum of the upload in field 129. Zero for an empty cache.
- Full PayloadField 129
bytesoptionalIndependent Transmit Now upload data; do not compare its CRC with field 2 to validate the upload.
2025-10 formatLegacy
Earlier chunked payload and additive-checksum format, retained for existing integrations. GET and SUBSCRIBE use this format when header 22 is omitted or set to 1. No legacy SET is supported.
Legacy fields
Fields specific to Message Box. Operation sections below explain when each field is used.
| Field | Type | Description |
|---|---|---|
| Legacy ChecksumField 1 | uint16 | Legacy additive checksum (sum of payload bytes modulo 65536), used in version 1 responses with the legacy chunk fields. Absent from version 2 responses. Optional and ignored in SET. |
| Legacy Payload Chunk 1Field 10 | bytes | Message Version 1 GET response payload chunk; contains up to 255 bytes. |
| Legacy Payload Chunk 2Field 11 | bytes | Message Version 1 GET response payload chunk; contains up to 255 bytes. |
| Legacy Payload Chunk 3Field 12 | bytes | Message Version 1 GET response payload chunk; contains up to 255 bytes. |
| Legacy Payload Chunk 4Field 13 | bytes | Message Version 1 GET response payload chunk; contains up to 255 bytes. |
| Legacy Payload Chunk 5Field 14 | bytes | Message Version 1 GET response payload chunk; contains up to 255 bytes. |
Read the cached message
GET chooses its own response format, regardless of the selected subscription format. A successful GET returns MT58 directly, rather than a separate success ACK.
Use the unchanged legacy wire layout and additive checksum.
Request
No payload fields are needed.
Request headers
- MethodHeader 5
uint8requiredValue
2· GETRequest a service to be perform an action
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
- Message VersionHeader 22
uint8optionalMaximum 1 bytesOmitted, explicitly 0, or malformed-width values resolve to 0 and select version 1; an explicit 1 also selects version 1.
0: Version 1 (also the omitted/malformed-width fallback)1: Version 1
Expected response (MT58)
Legacy cached payload
A successful GET returns this MT58 payload. An unsuccessful request returns MT5 (ACK) with Status instead.
Correlation, status and acknowledgment rules
Response-specific headers
- Message VersionHeader 22
uint8omittedLegacy version 1 responses retain their original wire layout and omit Message Version.
Response data fields
- Legacy ChecksumField 1
uint16requiredAdditive checksum: sum of all cached payload bytes modulo 65536.
- CRCField 2
uint16omittedThe CRC field belongs to version 2.
- Legacy Payload Chunk 1Field 10
bytesoptionalMaximum 255 bytesLegacy payload chunk 1; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 2Field 11
bytesoptionalMaximum 255 bytesLegacy payload chunk 2; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 3Field 12
bytesoptionalMaximum 255 bytesLegacy payload chunk 3; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 4Field 13
bytesoptionalMaximum 255 bytesLegacy payload chunk 4; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 5Field 14
bytesoptionalMaximum 255 bytesLegacy payload chunk 5; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Full PayloadField 129
bytesomittedVersion 1 retains the legacy wire layout; it does not include the extended full-payload field.
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
4Invalid Parameter- Invalid Parameter: a decoded Message Version value above 2.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Subscribe to cached-message updates
The latest valid SUBSCRIBE selects one shared format for all Message Box publications, not a format per subscriber. A decoded version above 2 leaves both the existing format selection and subscription unchanged. Control acknowledgment and later publications are distinct messages.
Omitted, explicitly 0, malformed-width, or explicit version 1 selects the shared legacy publication format.
Request
Request headers
- MethodHeader 5
uint8requiredValue
3· SUBSCRIBERequest a service to be perform an action
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
- IntervalHeader 6
uint32optionalOptional publication interval in milliseconds. If omitted, updates are sent when new data is available.
- DurationHeader 7
uint32optionalSubscription duration in milliseconds; 0 is indefinite until explicitly unsubscribed.
- Message LevelHeader 16
uint8optionalMinimum publication level.
1· Info-Watch: Receive all messages if and when available, without explicitly requesting that the underlying hardware be turned on.2· Info-Auto: Receive all messages and explicitly request underlying hardware be activated to provide the requested data where needed10· Valid: Activate the relevant hardware but only receive valid data. May be used with subscription timeout feature to request usable data without leaving the hardware on indefinitely
- Subscription IDHeader 17
uint8[]optionalSubscription ID; omit for the default subscription (0). Use the same ID when unsubscribing.
- Message VersionHeader 22
uint8optionalMaximum 1 bytesOmitted, explicitly 0, or malformed-width values resolve to 0 and select version 1; an explicit 1 also selects version 1.
0: Version 1 (also the omitted/malformed-width fallback)1: Version 1
Expected response (MT5 - ACK)
For a request with a nonzero Message ID, successful SUBSCRIBE returns a control ACK confirming the subscription request only. It does not contain the cache. Success ACKs are suppressed for an omitted or zero Message ID; error ACKs are not suppressed for this reason. Updates arrive as asynchronous MT58 publications, not as direct replies to SUBSCRIBE.
Correlation, status and acknowledgment rules · MT5 packet format
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
4Invalid Parameter- Invalid Parameter: a decoded Message Version value above 2; existing selection and subscription are unchanged.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Later publication (MT58)
Legacy cached payload update
Version 1 updates use the additive checksum and legacy chunks. Empty payload data is omitted.
Publication headers
- Response toHeader 3
uint32omittedThis is an asynchronous publication, not a direct reply to the SUBSCRIBE request.
- Subscription IDHeader 17
uint8[]optionalIdentifies nonzero subscription IDs for this publication.
- Message VersionHeader 22
uint8omittedLegacy version 1 responses retain their original wire layout and omit Message Version.
Publication data fields
- Legacy ChecksumField 1
uint16requiredAdditive checksum: sum of all cached payload bytes modulo 65536.
- CRCField 2
uint16omittedThe CRC field belongs to version 2.
- Legacy Payload Chunk 1Field 10
bytesoptionalMaximum 255 bytesLegacy payload chunk 1; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 2Field 11
bytesoptionalMaximum 255 bytesLegacy payload chunk 2; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 3Field 12
bytesoptionalMaximum 255 bytesLegacy payload chunk 3; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 4Field 13
bytesoptionalMaximum 255 bytesLegacy payload chunk 4; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Legacy Payload Chunk 5Field 14
bytesoptionalMaximum 255 bytesLegacy payload chunk 5; concatenate present chunks in field-ID order. Empty payload data is omitted.
- Full PayloadField 129
bytesomittedVersion 1 retains the legacy wire layout; it does not include the extended full-payload field.
Format-independent operations
These operations do not select a message format.
Stop a subscription
Remove the addressed subscription. Neither UNSUBSCRIBE nor subscription expiry resets the shared publication-format selection.
Request
No payload fields are needed.
Request headers
- MethodHeader 5
uint8requiredValue
5· UNSUBSCRIBERequest a service to be perform an action
- Message IDHeader 1
uint32optionalInclude a nonzero Message ID to correlate the reply.
- Subscription IDHeader 17
uint8[]optionalUse the Subscription ID to remove, or omit it for the default subscription (0).
- Message VersionHeader 22
uint8ignoredUNSUBSCRIBE does not select or reset the publication format.
Expected response (MT5 - ACK)
For a request with a nonzero Message ID, successful UNSUBSCRIBE returns a control ACK confirming the unsubscribe request, not a final cached-message publication. Success ACKs are suppressed for an omitted or zero Message ID; error ACKs are not suppressed for this reason.
Correlation, status and acknowledgment rules · MT5 packet format
Unsuccessful replies
Operation-specific causes. Codes are values of Status header 4, not payload fields.
7Not Supported- Not Supported: the product or firmware does not support this operation.
Format dates and wire selectors
The date labels identify when each documented format was introduced in source, not a firmware release date. The 2026-10 format uses Message Version 2; the earlier 2025-10 format uses Message Version 1. This header-22 selector is separate from protocol version 3. The numeric values remain visible in the request and response header documentation.
Payload CRC and frame CRC are different
The device calculates and stores CRC-16/XMODEM of the cached payload: polynomial 0x1021, initial value 0x0000, no input or output reflection, final XOR 0x0000. The outer message-frame CRC protects the complete frame. The 16-bit payload CRC can collide for different payloads; an accepted SET still applies changed bytes even when their CRC matches the previous CRC.
Message and field constants
Identifiers for this message type and its fields. See the operation sections above for rules and limits.