AIS Baseband IC with/without RF Synthesiser
CMX7032/CMX7042
In AIS burst mode, once an RXB1 task has been issued, the Rx1 channel state changes to Receiving
when a valid training sequence and start flag are detected. The CMX7032/CMX7042 then performs NRZI
decoding and bit de-stuffing on the received data stream, and calculates the CRC checksum.
Note: in AIS burst mode, the data words are automatically reversed so that they are presented to the host
most significant bit first. At the end of the message the receive channel state changes from Receiving to
either Idle or one of four error states (below). At the same time, an “Rx State Change” interrupt is flagged.
The four error conditions that the CMX7032/CMX7042 can detect in a received message (in burst mode)
are:
Message too long or missing end flag
This indicates that the received message, after bit de-stuffing, is too long to fit into the internal
message buffer. This condition could be caused by a missing or corrupted end flag.
CRC mismatch
This indicates that the received frame checksum does not match that calculated by the
CMX7032/CMX7042, most probably as the result of one or more message bits being corrupted.
New frame header found when message buffer full
This happens if the internal message buffers are still in use when another message arrives. This is
caused by a failure of the host µC to read the received messages out quickly enough.
End flag not on byte boundary
This indicates that the received message, after bit de-stuffing, is not a multiple of 8 bits. Assuming
that the message was transmitted correctly, probably caused by an end flag being missed due to
noise, and a subsequent message’s start flag being mis-identified as the expected end flag or a bit
error causing the bit de-stuffer to fail.
If any one of these error conditions is detected in a received message the CMX7032/CMX7042 discards
the message data.
Messages with a CRC error may be reported back to the host if the appropriate bit in the System Options
Config register has been set. The CRC error state is reported in the Status2 register. The host should
implement its own validity checks on messages received with a CRC error.
If a message with no error is found, the Rx1 channel state changes from Receiving to Idle (causing an “Rx
State Change” interrupt); the decoded message, comprising the burst information, three training sequence
bytes, start flag, message payload, CRC bytes and end flag, is then copied to one of the
CMX7032/CMX7042’s internal message buffers. When its turn comes around to be read out, it is copied to
the Rx1 Data Buffer and an “R1BRDY” interrupt is generated. At this point the host can issue Read Data
tasks to read back the burst and its associated parameters. Note: a new message will only generate an
“R1BRDY” interrupt when any previous message has been read out from the Rx1 Data Buffer in its
entirety.
The Rx1 channel state will stay in Idle until another RXB task is issued.
For any particular message, the three received (NRZI-decoded) training bytes in AIS burst mode will all be
either $55 or $AA depending on the configuration of the remote transmitter, although the first few bits may
be corrupted depending on the power-up characteristics of the remote transmitter and local receiver
circuits.
The host must read the Rx data buffers sufficiently quickly to avoid an overflow condition occurring. This is
only likely in a very heavily loaded AIS network. The worst case would involve the reception of a 5-slot
burst followed by a single slot and then a third burst in contiguous slots. In this case the host would need to
read the entire 5-slot burst out of the Rx Data buffer during reception of the single slot burst, such that the
buffer is then available for the third burst in the sequence. This is further compounded by the need to
monitor both Rx channels. Single slot AIS messages contain 168bits of data, which can be read by the
host in 3 x C-BUS RxData Read tasks. The maximal length 5-slot message contains upto 840 bits which
can be read by the host in 15 x C-BUS RxData Read tasks during the 26ms of a single slot. This implies
that the C-BUS must be running at a speed greater than 128kHz.
2012 CML Microsystems Plc
39
D/7032/42_FI1.2/13