What are the M, P, N, C, A, and S decoder messages?
These are legacy ASCII decoder output records. An M record is metadata. It is followed by either a P record for the decoded AirLink packet or an N record for the decoded MANT PDU.
What is the M,P message format?
M,P,YYYY,MM,DD,HH,MM,SS.UUUUUU,FEC=<fec_mode>,NLVL=<noise_level>
This is metadata for the following P record. The timestamp is the packet receive time. FEC is the forward error correction mode used for the AirLink decode. NLVL is the
receive quality/noise-level value reported by the decoder.
What is the P message format?
P,<airlink_reserved>,<time_quality>,YYYY,MM,DD,HH,MM,SS.UUUUUU,<airlink_frame_length>,<block_length>,<byte_1>,...,<byte_n>,<symbol_errors>
[,<block_length>,<byte_1>,...,<byte_n>,<symbol_errors>...],<first_block_decode_usec>[,<remaining_blocks_decode_usec>]
The P record contains the decoded AirLink frame. Each block is represented by a block length, that many hexadecimal byte values, and the Reed-Solomon symbol error count for that block. Multi-block
frames include additional block sections. Some legacy output may omit time_quality.
If a block after the first block is uncorrectable, its symbol_errors value is reported as -1. The decoder still emits the P record and attempts to continue using the recovered
bytes. If the corrupted bytes affect a normal MANT PDU, that PDU is dropped and no M,N or N record is emitted for it. If the corrupted bytes are in a MANT header, the decoder emits an
S,12 error and drops the remainder of the AirLink packet.
ALERT concentration PDUs are the exception. When the concentration PDU metadata is usable, the decoder rebuilds the PDU from the valid CCN entries, emits M,N and N for the rebuilt PDU, and
emits C and A records for the recovered CCN values.
What is the M,N message format?
M,N,YYYY,MM,DD,HH,MM,SS.UUUUUU,ENC=<0_or_1>
This is metadata for the following N record. ENC=0 means the MANT PDU was not authenticated by decryption. ENC=1 means an encrypted MANT PDU was decrypted successfully and
treated as authentic.
What is the N message format?
N,YYYY,MM,DD,HH,MM,SS.UUUUUU,<mant_version>,<mant_protocol>,<timestamp_request>,<add_path>,<include_destination>,<port>,<reserved>,<ack>,<added_header>,<hop_limit>,<payload_length>,<source_address>[,<destination_address>][,<payload_id>][,<route_length>,<route_1>,...,<route_n>],<payload_byte_1>,...,<payload_byte_n>
The optional destination address is present when include_destination is set. The optional payload ID is present when the MANT header includes a payload ID. The optional route list is present when
add_path is set. Payload bytes are hexadecimal.
What is the C message format?
C,<source_count>,<source_address>[,<route_address_1>,...,<route_address_n>],YYYY,MM,DD,HH,MM,SS,<alert_id>,<alert_data>[,...]
The C record is a compact ALERT concentration summary generated from a MANT concentration PDU. It starts with the source path, then includes one or more ALERT CCN values. Each CCN value contains the
ALERT timestamp, ALERT ID, and ALERT data value.
What is the A message format?
A,YYYY,MM,DD,HH,MM,SS,<alert_id>,<alert_data>
The A record is one individual ALERT CCN value extracted from a concentration PDU. A concentration PDU may produce one C record and multiple A records.
What is the S,1 message format?
S,1,<airlink_reserved>,<airlink_frame_length>,<block_length>,<byte_1>,...,<byte_n>,<symbol_errors>,*Bad First Block, uncorrectable bit errors; discarding packet
S,1 reports a bad AirLink first block. The decoder could not correct the first block, so the packet is discarded.
What is the S,11 message format?
S,11,<time_quality>,YYYY,MM,DD,HH,MM,SS,<total_packets>,<packets_not_processed>,<total_blocks>,<bad_blocks>,<errors_corrected>,<n_messages>,<c_messages>,<a_m
essages>,<n_messages_not_app_layer>,<rebuilt_n_messages>
S,11 is the periodic decoder statistics record. Some legacy output may omit time_quality, in which case the timestamp immediately follows S,11.
Does the A2X support ALERT concentration messages?
Yes. The A2X supports ALERT concentration. Received ALERT CCN messages are decoded from ALERT2 concentration PDUs and are forwarded over the configured IP output.
The A2X can also carry received CCN messages over the ALERT2 AirLink/Radio interface. CCN messages are queued for transmission by the encoder and packed into ALERT2 concentration PDUs for radio forwarding.
How do I log in to the A2X to change decoder configuration?
Configuration options are available through the API and the A2Control configuration application, so there is no need to log in to the A2X to configure it.
To retrieve data from a remote unit, the A2X supports fetching data via SFTP on port 4422. The username is "alert2", but the account is disabled by default for security purposes. Set a password through the API or A2Control to enable it.
How do I forward decoder output to a cloud-based data collector?
Under the IP Settings tab in A2Control, use the IP Forward fields to configure one or more outbound TCP connections from the A2X to your data collector. Enter collectors as a comma-separated list of hostnames or IP
addresses, with an optional port number, for example primary.example.org:4402,secondary.example.org:4402.
API2 Binary IP Forward is the preferred format when the collector supports it. API2 binary messages are sent with an AL22b header followed by the binary payload.
Use ASCII IP Forward only when the collector expects the legacy ASCII decoder stream, such as M,P, P, M,N, N, C, A, and S records.
Use CSV IP Forward for the human-readable CSV format. This sends decoded data as newline-terminated CSV records, including AirLink, MANT, ALERT CCN, Sensor Report, Sensor Get, and Sensor Set records.
Use Binary IP Forward when the collector expects the legacy binary stream. Binary messages are sent with an ALERT2 header followed by the binary payload.
If no port is specified, the A2X uses the default port for that output type: 4200 for ASCII, 4201 for Binary, 4202 for CSV, and 4203 for API2 Binary.
The A2X initiates the TCP connection to the configured collector. The collector must be reachable from the A2X network and must listen on the configured port. If the connection fails or drops, the A2X retries automatically.