Packet handling
The RFFE can be used as standalone radio where the Arm Cortex-M33 processor can interface and communicate with the RFFE through IRQs and TX/RX FIFOs. Test Mode in this case needs to be disabled (value 0x0) and the Bluetooth Low Energy stack of RSL15 and its related Bluetooth Low Energy hardware cannot be used. This standalone mode is called Packet Handling Mode.
The digital TX and RX contain a full packet handler. It has various features, including:
- Automatic preamble and pattern insertion
- Pattern detection
- Fixed and variable packet length with various tunings
- Automatic address insertion and checking
- Automatic full custom CRC insertion and checking
- Support for Multi-Frame Mode (preamble – pattern – data – CRC – data – CRC)
Packet Format
The packet handler supports several packet formats. Some of the possible packet formats are shown in the "Serializer-Supported Packet Formats (Partial List)" figure. The bytes shown in blue can be inserted automatically.
Preamble
The preamble can be added automatically to the data, even if the packet structure is handled completely by the Arm Cortex-M33 processor or the firmware.. This feature can be turned on by setting the RF_PACKET_HANDLING_PACKET_HANDLING_EN_PREAMBLE field of the RF_PACKET_HANDLING register to 1. The length of the preamble in bytes is found in the RF_REG0C_PREAMBLE_LENGTH_PREAMBLE_LEN field of the RF_REG0C register increased by 1, and the preamble itself is located in the RF_PACKET_HANDLING register.
Pattern
The pattern (or synchronization word) is introduced automatically if the preamble is present. The length of the pattern is contained in the RF_PACKET_EXTRA_PACKET_EXTRA_PATTERN_WORD_LEN field of the RF_PACKET_EXTRA register. The pattern itself is found in the RF_SYNC_PATTERN register. In the case of 8 or 16 bits, it is always the LSBs that are used. Pattern detection is enabled by setting the RF_PACKET_HANDLING_PACKET_HANDLING_EN_PATTERN bit of the RF_PACKET_HANDLING register. Pattern detection can accept some errors: this is useful with very short preambles, since the clock recovery is not yet complete in those cases. The maximum number of errors accepted in pattern recognition is located in the RF_PACKET_EXTRA_PACKET_EXTRA_PATTERN_MAX_ERR field of the RF_PACKET_EXTRA register.
Packet Length
If the RF_PACKET_HANDLING_PACKET_HANDLING_EN_PATTERN bit of the RF_PACKET_HANDLING register is set to 1, the packet structure is used, and so the serializer needs to know the length of the packet. This can be either fixed or variable. If the fixed format is chosen, the RF_PACKET_HANDLING_PACKET_LENGTH_OPTS_EN_PACKET_LEN_FIX field of the RF_PACKET_HANDLING register must be set to 1. In such a case, the length of the packet is found in the RF_PACKET_HANDLING_PACKET_LENGTH_PACKET_LEN bit of the RF_PACKET_HANDLING register. In the case of a variable packet length, this is normally specified as one of the first bytes of the packet. The RF_PACKET_HANDLING_PACKET_LENGTH_OPTS_PACKET_LEN_POS field of the RF_PACKET_HANDLING register specifies the position of this byte. If it is set to 0, this means that the first byte of the serializer contains the packet length; if it is set to 1, the second byte contains the packet length; and so on.
The packet length can be specified in several ways: for instance, it can take into account the CRC, or the packet length itself. The RF_PACKET_HANDLING_PACKET_LENGTH_OPTS_PACKET_LEN_CORR field of the RF_PACKET_HANDLING register contains the correction to apply to the packet length byte.
The packet handler always considers the length of the packet, from the first byte after the packet length byte, until the last byte before the CRC. This field corrects the packet length. For example, if a standard protocol, such as Bluetooth Low Energy technology, considers that the CRC is taken into account in the packet length, a packet length of 5 means that there are 3 data bytes and 2 CRC bytes. So the RF_PACKET_HANDLING_PACKET_LENGTH_OPTS_PACKET_LEN_CORR field has to be set to -2. the "Packet Length Definition and Associated Correction Examples" figure shows the length definition of the packet.
In the case of a variable packet length, the RF_PACKET_HANDLING_PACKET_LENGTH_PACKET_LEN field in the RF_PACKET_HANDLING register has another meaning: on the RX side, this field can be used to specify the maximum packet length. If a protocol supports only packets with a maximum of 64 bytes, this field can be set to 64. If a received packet has a length greater than 64, a packet length error is generated by the deserializer.
Address
An address can be inserted automatically after the packet length, if the RF_REG0C_ADDRESS_CONF_EN_ADDRESS_TX field of the RF_REG0C register is set to 1. The address is given by the RF_REG0C_ADDRESS_ADDRESS bit of the RF_REG0C register. On the RX side, if the RF_REG0C_ADDRESS_CONF_EN_ADDRESS_RX field of the same register is set to 1, an address comparison is made. If the addresses do not match, an address error is generated by the deserializer.
A broadcast address can be specified in the RF_PACKET_EXTRA_ADDRESS_BROADCAST_ADDRESS_BR bit of the RF_PACKET_EXTRA register. The RX broadcast address reception can be enabled by setting the RF_REG0C_ADDRESS_CONF_EN_ADDRESS_RX_BR of the RF_REG0C register to 1; in such a case, the RX accepts the normal address and the broadcast address during reception. Confirmation of broadcast address reception is found in the RF_DESER_STATUS_DESER_STATUS_IS_ADDRESS_BR_IS_ADDRESS_BR field of the RF_DESER_STATUS register. The address length can be 8 or 16 bits, depending on the value of the RF_REG0C_ADDRESS_CONF_ADDRESS_LEN field of the RF_REG0C register.
Multi-Frame
If the RF_PACKET_HANDLING_PACKET_HANDLING_EN_MULTI_FRAME bit of the RF_PACKET_HANDLING register is set to 1, Multi-Frame Mode is enabled. (A frame is composed of the data and the corresponding CRC.) In this mode, a preamble and a single synchronization word are followed by multiple frames. As long as the RF_PACKET_HANDLING_PACKET_HANDLING_EN_MULTI_FRAME bit is set to 1, Multi-Frame Mode is enabled.
CRC
The CRC is a hash function of the data, used to detect errors during transmission. The value of the CRC is added at the end of the packet. Errors during transmission are detected by a difference between the calculated CRC and the received one. The CRCs are generally specified by a polynomial.
The digital baseband can calculate the CRC on the fly, and insert it at the end of the packet. The CRC polynomial is programmable, and it can have a length from 1 to 32 bits. The length of the polynomial is specified by the polynomial itself. The CRC polynomial is contained in the RF_CRC_POLYNOMIAL register. The polynomial is represented in Koopman notation: the nth bit specifies the (n+1) order; the order 0 (the 1 at the end of the polynomial) is ignored. Some examples:
- The CCITT CRC16 polynomial x16+x12+x5+1 is given by 0x8810.
- The IBM CRC16 polynomial x16+x15+x2+1 is given by 0xC002.
- The Bluetooth LE CRC24 polynomial x24+x10+x9+x6+x4+x3+x+1 is given by 0x80032D.
This hardware CRC implementation works on the serialized stream, so the bit order depends on the value of the RF_PACKET_HANDLING_PACKET_HANDLING_LSB_FIRST bit in the RF_PACKET_HANDLING register. At the insertion of the CRC, the value of the CRC is simply shifted out. The start value of the CRC register is contained in the RF_CRC_RST register. CRC calculation, insertion, and validation are performed automatically if the RF_PACKET_HANDLING_PACKET_HANDLING_EN_CRC field of the RF_PACKET_HANDLING register is set to 1.
The CRC calculation of the packet length value can be controlled through the CRC_ON_PKTLEN field of the same register. This is useful for the standards in which the CRC is on the MAC layer – for example, the IEEE 802.15.4 standard.
Bluetooth Low Energy Direct Test Mode
The Direct Test Mode (DTM) of the Bluetooth Low Energy standard specifies the packet format that needs to be used to test the PHY layer performance. For the TX mode, these packets can be provided by activating the Bluetooth Low Energy DTM mode; do this by setting the RF_PROT_TIMER_BLE_DTM_EN_BLE_DTM bit of register RF_PROT_TIMER to 1. Then the packet type and the packet length are defined by the the RF_PROT_TIMER_BLE_DTM_BLE_DTM_PKT_TYPE[3:0] and RF_PROT_TIMER_BLE_DTM_LEN[7:0] fields of the same register.
NOTE: When the BLE_DTM_EN_BLE_DTM Mode is enabled, the TX FIFO is completely bypassed.
Bluetooth Low-Energy Direction Finding
The RFFE supports the direction finding feature introduced in Bluetooth version 5.1. This feature allows calculation of the Angle of Departure (AoD) or the Angle of Arrival (AoA), based on the IQ samples taken during the constant tone extension (CTE) of the packet. The presence of the CTE is determined by the CTEinfo Present bit (CP bit, only present in the data connection packets). When this bit is present, the packet header is 1 byte longer, since it contains the CTEinfo byte that provides information on the CTE. The description here is used when the RFFE is used as standalone (Packet Handling Mode); otherwise, by default for the RSL15 Bluetooth Low Energy stack, the RFFE communicates to Bluetooth Low Energy hardware internally through dedicated signals.
TX Mode
In TX there are 3 possibilities to handle the CTEinfo.
- Put the CTEinfo byte in the FIFO and let the packet handler process the packet. This can be done by setting the RF_CTE_OPTS_CTE_OPTS_EN_READ_CP bit of register RF_ CTE_OPTS. In this case, the information stored in the FIFO at the CTEinfo position is saved and used for the CTE.
- Force the CTEinfo insertion in the packet. This functionality is activated by setting the RF_CTE_OPTS_CTE_OPTS_CP_INSERT bit of register RF_CTE_OPTS to 1. In this case, the packet in the FIFO needs to be a CTEinfo clear packet. The CP bit is automatically set to 1 by the packet handler, and the value in the RF_CTE_OPTS_CTE_OPTS_CTE_INFO[7:0] field of the RF_CTE_OPTS register is inserted at the correct spot.
- Force the CTE without modifiying the packet header (this mode is used in cases of CTE for the advertisement packets). This mode is activated with the RF_CTE_OPTS_CTE_OPTS_USE_CTE_WO_CP field of the RF_CTE_OPTS register. In this case, at the end of the packet, the CTE is inserted based on the information in the RF_CTE_OPTS_CTE_OPTS_CTE_INFO[7:0] field of the same register.
RX Mode
On the RX side, there are only two possibilities:
- Read the CP bit to parse the packet correctly for CTE information. This is done with the RF_CTE_OPTS_CTE_OPTS_EN_READ_CP bit of register RF_CTE_OPTS.
- Force the CTE analysis through the RF_CTE_OPTS_CTE_OPTS_USE_CTE_WO_CP bit from the RF_CTE_OPTS register. In this case the packet handler goes to the CTE phase after the CRC. The sampling information is provided by the RF_CTE_OPTS_CTE_OPTS_CTE_INFO[7:0] field of register RF_CTE_OPTS.
CTE Sampling
The CTE sampling is done automatically at the end of the packet, during the CTE phase. For AoD, the sampling period is determined by the CTEinfo. In case of AoA, it is possible to choose between 1 μs and 2 μs with the RF_CTE_OPTS_CTE_OPTS_DF_AOA_SLOT_TIME bit of register RF_CTE_OPTS. The IQ samples are available in the IQ_FIFO and can be read in register RF_IQFIFO. The samples are 8 bits wide and are stored I first. The number of available samples is stored in the RF_IQFIFO_STATUS_IQFIFO_COUNTIQFIFO_COUNT field of the RF_IQFIFO_STATUS register.
The sampling time and the antenna switching time have to be tuned to the RX and TX data path delays. The antenna switching delay in case of AoD is tuned through the RF_CTE_IF_CTE_CTRL_DELAY_TX_DF_DELAY_TX[9:0] field of the RF_CTE_IF register. The granularity of this delay is 62.5 ns. When this value is increased, the antenna switching happens at a later point. In the case of AoA, the antenna switching happens in RX and the delay is specified by the RF_CTE_CTRL_CTE_CTRL_DELAY_RX_DF_DELAY_SWITCH_RX[9:0] field of register RF_CTE_CTRL. This value represents the delay from the antenna to the deserializer. By increasing the value, the user anticipates the antenna switching. The sampling delay is controlled by the RF_CTE_CTRL_CTE_CTRL_DELAY_RX_DF_DELAY_SAMPLE_RX[9:0] field of the RF_CTE_CTRL register. This value represents the delay from the matched filter to the deserializer. By increasing this value, the user anticipates IQ samplings.
By its receiver architecture, the IQ signals doesn’t have an amplitude information, since the phase is obtained through the phADC block. In order to provide an amplitude information, the RSSI instant value has to be combined with the phase to generate two real IQ values. This feature can be activated by setting the RF_CTE_OPTS_CTE_OPTS_CTE_AMPLl bit of the RF_CTE_OPTS register. Note that the quality of the I & Q samples can be slightly degraded if this feature is activated (noisy).
Antenna Switching Pattern
The antenna switching pattern is specified through a lookup table (LUT): the fields of this LUT specify the state of the antenna controls, and the LUT is parsed linearly. The RF_CTE_IF_ANTENNA_CONF_* fields in the RF_CTE_IF register and the RF_LUT_ANTENNA_ARRAY_*_LUT_ANTENNA_ARRAY_*_ANTENNA_* fields in the RF_LUT_ANTENNA_ARRAY_* registers are used to specify the LUT and the number of fields that are parsed inside it. So if the RF_CTE_IF_ANTENNA_CONF_ANT_LUT_M[3.0] field in the RF_CTE_IF register is set to 3 (meaning that a 4-antenna configuration pattern is being used), then the antenna is at the value of the RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_0[3:0] field in the RF_LUT_ANTENNA_ARRAY_1 register during the packet and the reference period, after which it follows this pattern:
a1, a2, a3, a0, a1,...
Where a0 is RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_1[3:0], a1 is RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_2[3:0], a2 is RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_1[3:0], and so on. The values inside the RF_LUT_ANTENNA_ARRAY_*_LUT_ANTENNA_ARRAY_*_ANTENNA_*[3:0] fields are completely arbitrary, so it is possible to specify one-shot coding as well as a binary code for the antenna switches. This is the basic antenna switching scheme. It is possible to code a separated antenna switching pattern from the rest of the packet. In this case, the RF_CTE_IF_ANTENNA_CONF_DF_IND_ANTENNA bit of register RF_CTE_IF needs to be set to 1. Then the packet is sent on RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_0[3:0], the reference period of the CTE is on RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_1[3:0], and the antennal switching pattern is:
a2, a3, a1, a2, a3,...
As an example, suppose that the RF_CTE_IF_ANTENNA_CONF_ANT_LUT_M field in the RF_CTE_IF register is set to 3. The switching pattern can also be separated from the reference by setting the RF_CTE_IF_ANTENNA_CONF_DF_INT_PATTERN field in the RF_CTE_IF register to 1. In this case, the switching pattern is as follows:
a2, a3, a2, a3, ...
If RF_CTE_IF_ANTENNA_CONF_DF_IND_PATTERN is set to 1 and RF_CTE_IF_ANTENNA_CONF_DF_IND_PATTERN_ANTENNA is set to 0, then the CTE reference period is on RF_LUT_ANTENNA_ARRAY_1_LUT_ANTENNA_ARRAY_1_ANTENNA_0[3:0] and the switching pattern is as follows:
a1, a2, a3, a1, a2,...
All possible switching schemes are represented in the "Possible Antenna Switching Schemes" figure.
Coding
The outgoing and incoming bit-streams often need to be encoded/decoded. There are several options available for both TX and RX.
Manchester Coding
Manchester encoding is available through the RF_CODING_CODING_EN_MANCHESTER bit of the RF_CODING_CODING register. This code is used in the IEEE 802.3 standard: a 1 is coded by a rising edge (01) and a 0 is coded by a falling edge (10). This can be inverted by using the bit_invert configuration.
Data-Whitening
The data can be whitened by setting the RF_CODING_CODING_EN_DATAWHITE bit of the RF_CODING register. The whitening sequence is a PN9. Whitening is used to avoid long sequences of 0 or 1.
For the Bluetooth Low Energy standard, the LFSR used is a Galois LFSR7 with a specific reset status. This particular LFSR can be activated by setting the RF_REG00_DATAWHITE_BTLE_DW_BTLE bit of the RF_REG00 register; the RF_CODING_CODING_EN_DATAWHITE bit from the RF_CODING register also has to be set. In the RF_REG00 register, the RF_REG00_DATAWHITE_BTLE_DW_BTLE_RST[6:0] field specifies the reset status of the LFSR. If the Bluetooth Low Energy channels are used (bit RF_CODING_CHANNELS_2_EN_CHN_BLE of register RF_CODING), the reset value of the Galois LFSR7 does not need to be programmed.
IEEE 802.15.4 Bit to Chip Conversion
The IEEE 802.15.4 standard specifies conversion from a sequence of four bits to a transmitted sequence of 32 chips. This conversion can be activated by setting the RF_CODING_CODING_EN_802154_B2C bit of the RF_CODING register to 1. On the RX side when this bit is set, the chip sequence synchronization is based on sequences of 0000: this is mainly because the IEEE 802.15.4 standard preamble is composed of this sequence. However, pattern recognition works transparently.
New IEEE 802.15.4 Chip to Bit Decoder
A new version of the IEEE 802.15.4 chip decoder that works on the oversamples side has been implemented. It can be activated with the RF_AGC_LUT5_IEEE802154_OPTS_USE_OS_802154 bit of the RF_AGC_LUT5 register. This algorithm uses a correlator with an adaptive threshold to detect the correct sequences, and synchronizes the clock recovery in consequence. As for the old algorithm, the “0000” sequences are tracked to synchronize the symbol reception. Three parameters are used to track this sequence; they affect how the correlation peaks are detected. The parameters are the values of the RF_AGC_LUT5_IEEE802154_OPTS_CNT_LIM_802154[1:0], RF_AGC_LUT5_IEEE802154_OPTS_CNT_OK_INC_802154[2:0], and RF_AGC_LUT5_IEEE802154_OPTS_C2B_THR[2:0] fields of the RF_AGC_LUT5 register.
The correlation peaks of these sequences are set to 0 when there is a perfect match; so ideally, the threshold is set also to 0. However, due to the low SNR that can be achieved in the IEEE 802.15.4 mode, this might not be a good solution. The adaptive threshold follows the correlation peaks, i.e., when a correlation peak is lower than the threshold, the threshold assumes the correlation peak value. After 2(RF_AGC_LUT5_IEEE802154_OPTS_CNT_LIM_802154+4) samples, the threshold is increased by 1. A correlation peak is considered correct if its value is lower than the actual threshold added to the RF_AGC_LUT5_IEEE802154_OPTS_C2B_THR[2:0] value. If a peak is considered valid, then an internal 4-bit counter is increased by the value of the RF_AGC_LUT5_IEEE802154_OPTS_CNT_OK_INC_802154[2:0]field in the RF_AGC_LUT5 register. If the counter is larger or equal to eight, then the block is determined to be synchronized and starts to provide samples to the rest of the radio.
Linear to Frequency
The IEEE 802.15.4 standard specifies an O-QPSK modulation. This can be considered as linear, since the In phase and Quadrature phases are encoded directly. However, on the RSL15 RFFE there is a direct modulation, meaning that the frequency is encoded directly. To maintain the linear code and be able to modulate in the frequency domain, a linear to frequency coding is available. It can be activated by setting the RF_CODING_CODING_EN_802154_L2F bit of the RF_CODING register to 1.
NOTE: On the RX side, a phase ambiguity can arise. To prevent it, the RX correlators work on the frequency spreading sequences, and not on the phase sequences.
Convolutional Codes
In the RFFE, a forward error correction (FEC) is available that is realized with programmable convolutional codes. The decoding is performed with the classic Viterbi algorithm. These convolutional codes are well known and documented, so their principles are not detailed here.
It is possible to specify up to three codes, which gives a minimum rate of 1/3. The convolutional codes are specified in the fields RF_REG10_CONV_CODES_POLY_CC_POLY_0 and RF_REG10_CONV_CODES_POLY_CC_POLY_1 in the RF_REG10 register, by inserting the bits of the generator polynomials in reverse order. For example, if the code (x3+x2+x+1, x3+x2+1) (written as (17,15) since convolutional codes are generally written in octal) has to be coded, the code in binary is (0b1111,0b1101). So the RF_REG10_CONV_CODES_POLY_CC_POLY_0[4:0] field of the RF_REG10 register is 0xF (0b1111), and the RF_REG10_CONV_CODES_POLY_CC_POLY_1[4:1] field of the same register is 0xB (0b1011).
The convolutional codes can be activated by setting the RF_PACKET_EXTRA_CONV_CODES_CONF_EN_CONV_CODE bit of the RF_PACKET_EXTRA register to 1.
It is good practice to add some encoded bits at the end of the packet, to supply more information to the Viterbi decoder. The additional bits can be activated by the RF_PACKET_EXTRA_CONV_CODES_CONF_CC_EN_TX_STOP bit of the RF_PACKET_EXTRA register. The number of stop words is specified by the RF_PACKET_EXTRA_CONV_CODES_CONF_STOP_WORD_LEN[1:0] field of the RF_PACKET_EXTRA register.
On the decoder side, the memory length of the Viterbi algorithm is given by the RF_PACKET_EXTRA_CONV_CODES_CONF_CC_VITERBI_LEN[1:0] of the RF_PACKET_EXTRA register.
Puncturing Codes
Puncturing codes can be added to the convolutional codes: this increases the coding ratio at the cost of degraded correction capability. Puncturing codes are specified in reverse order, using the fields RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_0[4:0] and RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_1[4:0] of the RF_REG10 register. For example, if the code specified above has a puncturing code (1 1 1;1 0 0), then RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_0 = 0x7, and RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_1 = 0x1.
4FSK coding
The Bluetooth 5 specification introduces three additional data-rates: 2 Mbps, and coded 125 kbps and 500 kbps. While the former is a straightforward implementation in the RFFE, the coded data-rates (also called Bluetooth Low Energy Long Range (BLR)) require some additional coding/decoding features. These data-rates are implemented through a pattern mapping and a coded stream. For the coded stream, the convolutional codes (see Convolutional Codes) need to be set correctly:
- RF_REG10_CONV_CODES_POLY_CC_POLY_0 field in register RF_REG10 = 0xF
- RF_REG10_CONV_CODES_POLY_CC_POLY_1 field in register RF_REG10 = 0xD
- RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_0 field in register RF_REG10 = 0x1
- RF_REG10_CONV_CODES_PUNCT_CC_PUNCT_1 field in register RF_REG10 = 0x1
The BLR feature can be enabled by setting the RF_BLE_LR_BLE_LONG_RANGE_EN_BLR field of the RF_BLE_LR register/ On the TX side, it is required to specify whether a 500 kbps or a 125 kbps data rate needs to be sent, by setting the bit RF_BLE_LR_BLE_LONG_RANGE_BLR_500_N125 in the RF_BLE_LR register to 1 for a 500 kbps packet, or to 0 for a 125 kbps packet. This is enough for a TX packet to be sent correctly. The preamble is set correctly without any need to change the RF_PACKET_HANDLING_PREAMBLE_PREAMBLE field of the RF_PACKET_HANDLING register. The pattern mapping and convolutional codes are activated automatically with the RF_BLE_LR_BLE_LONG_RANGE_EN_BLR bit, so there is no need to change any other registers.
On the RX side, some additional parameters need to be set. The packet detection is performed with the following steps:
- preamble synchronization
- synchronization word detection
- decoding
Preamble synchronization is used to align the sampling time to the pattern mapping of the preamble , to demap it correctly. This is done through a correlation filter; its threshold is set with the RF_BLE_LR_BLR_PREAMBLE_BLE_PRE_THR[3:0] field of the RF_BLE_LR register. The correlation peak increases towards 0; if this field is set to 0, the maximum constraint is given to this filter. In the case of bad SNR, the preamble synchronization can be missed.
The synchronization word detection is made in two sets: first, a demapped but still coded signal is processed with a correlator filter to match the coded sync word. If there is a match, the coded sync word is fed to the Viterbi algorithm to be decoded, and then another correlator filter matches it against the uncoded syncword. For the first correlator, the maximum value for the correlation peak is 64 (since a coded 32-bit sync word is 64 bits long). Matching is best not performed on the value of 64, to take into account the possibility of low SNR; but the packet can still be decoded because of the Viterbi algorithm. So the peak detection can be selected by changing the threshold field RF_BLE_LR_BLR_SYNC_THRESHOLD_BLE_SYNC_THR[6:0] in the RF_BLE_LR register. If the value 64 is chosen, the maximum requirement is set to the correlator.
The packet is then decoded through the Viterbi algorithm and fed to the deserializer; after this, the packet is simply received. However, the Viterbi algorithm introduces a long latency that can be greater than the inter frame space (IFS) time specified by the Bluetooth Low Energy standard. To prevent this latency, the bit en_blr_flush in the register needs to be set to 1. This sends a signal to the Viterbi algorithm, when the last bit is received, to flush out its queue, since the path in the trellis is now known (termination bits of the BLR packet).
Bluetooth Low Energy Long Range
Since there is no universal 4FSK coding in RFFE, it is possible to change the mapping of the 4FSK encoding in order to meet almost any possible coding.
The four levels of the 4FSK modulation are generally represented as {-3;-1;+1;+3}. The two bits per symbol have to be coded into these four possible symbols. To reduce the number of errors, a Grey coding is generally used. It is possible to prove that one bit is coding the sign, and the other one the absolute amplitude of the symbol; this means that one bit codes if it is 1 or 3, and the other if it is positive or negative.
In the coder block the bits are fed in two paths named I and Q (this is a legacy name that is no longer related to the I and Q paths of the RF). 4FSK coding allows you to choose which signal is coding the sign (I or Q), and if the value is inverted or not. Separate codings for the TX and the RX are provided. 4FSK coding is activated by setting the RF_REG00_FOURFSK_CODING_EN_FOURFSK_CODING bit of the RF_REG00 register, and the different types of coding are chosen with the RF_REG00_FOURFSK_CODING_TX_FOURFSK_CODING[2:0] and the RF_REG00_FOURFSK_CODING_RX_FOURFSK_CODING[2:0] fields of the same register.
In the normal stream, the I and Q order is chosen with the the RF_CODING_CODING_EVEN_BEFORE_ODD bit of the RF_CODING register. If this bit is set to 1, the first bit to enter the data path is fed to the I path; otherwise the Q path is chosen. Then the RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[0] bit from the RF_REG00 register specifies if the bit that determines the sign of the symbol is I or Q (0 => Q, 1 => I). If RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[2] is 0, the sign is positive if the sign bit is 1, and negative if is 0. If RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[2] is 1, the configuration is inverted. If RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[1] is 0 and the amplitude bit is 0, the absolute value of the symbol is 1; otherwise it is 3. If the RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[1] is 1 and the amplitude bit is 0, the absolute value of the symbol is 3; otherwise, it is 1.
Examples: RF_CODING_CODING_EVEN_BEFORE_ODD = 1, RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[2:0] = 0b011, and the message is 0b00111001 (LSB first). The first bit is 1 and, since RF_CODING_CODING_EVEN_BEFORE_ODD is set to 1, it is fed to the I path. So for the first symbol, the I path is 1 and the Q path is 0. RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[0] is set to 1, so the sign of the symbol is given by the I bit and so the amplitude is controlled by the Q bit. The RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[1] bit is set to 1, so the amplitude is inverted; since the amplitude bit (Q) is set to 0, the absolute amplitude is 3. Finally the RF_REG00_FOURFSK_CODING_*X_FOURFSK_CODING[2] bit is set to 0, so the sign is not inverted; since the sign bit (I) is set to 1, the sign is positive. In conclusion, the first two bits code the symbol +3. The others symbols are -1; -3, and 1.
The "4FSK Coding" figure contains a summary of all available modes. Note that it is always a Grey coding.
Miscellaneous and Encoding Order
Several minor encoding options are available, including:
- Differential encoding: this can be activated by setting the RF_REG00_MODE2_DIFF_CODDING bit of the of the RF_REG00 register. This encoding is not available for every coding option. However, on the RX side every coding option (especially the 2 bits/symbol modulation) is available.
- Bit inversion: when the RF_CODING_CODING_BIT_INVERT bit of the RF_CODING register is set to 1, the encoding stream and the decoding stream are inverted.
- Bit order in quadrature modulations: this bit order (especially in O-QPSK) can be determined by the RF_CODING_CODING_EVEN_BEFORE_ODD, RF_CODING_CODING_OFFSET, and RF_CODING_CODING_I_NQ_DELAYED bits of the RF_CODING register.
The encoding order on the TX side is the following (on the RX side it is the opposite):
Data whitening => Manchester => Bit2Chip => Lin2Freq => Bit invert => QuadMod => Diff coding