3.7.1 RX Overview
The ATA8210/15 contains two receive paths A and B whose parameters, such as the modulation type, data rate and telegram settings, can be set separately. See RX Telegram Handling and General RX Settings from Related Links. If individual settings are possible for the two paths, this is marked with a small x instead of an A or B in the subsequent sections.
The receive unit is split after the digital channel filter and merged again after the data decoding. This implies that:
- It is possible to search in parallel for telegrams with different modulation (ASK/FSK).
- It is possible to search in parallel for telegrams with different data rates.
- It is possible to search in parallel for telegrams with different FSK deviations as long as the channel filter setting suits both.
- It is possible to configure signal checks and error handling individually for both paths.
- It is possible to configure the preamble settings (WUP, SFID pattern) individually for both paths.
- It is not possible to search in parallel for telegrams on different RF carrier frequencies.
- It is not possible to receive the data payload in parallel on both paths, because one path is switched off after WUP or SFID detections on the other path.
The data Receive mode (RXMode) can be activated after the power-on if preselected by the Operating mode (OPM) bits of the sysStartConfig EEPROM variable. See sEEPromTrxCalib eepTrxCal from Related Links.
| Address | Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|---|
| 0x0019 | sysStartConfig | RF_CAL | — | VCO_TUNE | IDLEModeSelector | — | TMDEN | OPM[1:0] | |
In addition, activate by using the Set System Mode SPI command if the OPM bits
in the systemModeConfig parameter are set to 0b10. The required service/channel
configuration as well as additional settings, such as VCO tuning during mode ramp-up,
are part of the SPI command. See Set System Mode from Related Links.
| Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|
| systemModeConfig | RF_CAL | — | VCO_TUNE | IDLEModeSelector | — | TMDEN | OPM[1:0] | |
| serviceChannelConfig | enaPathB | enaPathA | ch[1:0] | — | ser[2:0] | |||
Init SRAM Service SPI command. See
Init SRAM Service from Related Links.The data reception is split into RXMode(transparent) and RXMode(buffered), selectable by the Transparent Mode Data Enable (TMDEN) bit (see the following subsections).
Use the RXMode for all services without any restrictions. It supports service-independent features such as:
- Subchanneling (see Subchanneling from Related Links)
- RSSI measurement (see RSSI Measurement from Related Links)
RXMode generally generates external events on pin 28 (EVENT) if a certain event occurs and the corresponding event mask in rxSysEvent is enabled. Events that are only relevant for the RXMode(transparent) and RXMode(buffered) are described in the associated sections. Commonly used events to indicate internal status information are located in the system (R15) and events (R14) (see the following table).
| Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|
| System (R15) events.system | SYS_ERR | CMD_RDY | SYS_RDY | AVCCLOW | LOWBATT | SFIFO | DFIFO_RX | — |
| Events (R14) events.events | IDCHKA | WCOKA | SOTA | EOTA | IDCHKB | WCOKB | SOTB | EOTB |
| Address Service0 | Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|---|
| 0x00E3 | rxSysEvent | IDCHKA_Mask | WCOKA_Mask | SOTA_Mask | EOTA_Mask | IDCHKB_Mask | WCOKB_Mask | SOTB_Mask | EOTB_Mask |
In RXMode, configure the pin 29 (PB7) as the RX_ACTIVE signal to monitor the status of the RF front-end. Configure the RX_ACTIVE pin in the eepEventConf.sysEventConf.RX_ACTIVE_EN and RX_ACTIVE_POL EEPROM variables. Use the RX_ACTIVE signal for biasing an external LNA. See External LNA Control from Related Links.
| Address | Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|---|
| 0x0095 | sysEventConf | SYS_ERR | — | SYS_RDY | AVCCLOW | LOWBATT | RX_ACTIVE_EN | RX_ACTIVE_POL | IRQ_POL |
After the activation of the RXMode, the firmware initializes the registers based on the settings in the selected service/channel configuration and configures the sequencer state machine for RXMode. If an RF calibration is selected, a temperature calibration of the XTO is carried out based on the latest available temperature value. A temperature measurement itself is not performed. If enabled, the RX_ACTIVE pin is set after the service/channel configuration is done and before activating the RF front-end.
The start-up of the RF front end is handled by the SSM and controlled by the firmware via a
software watchdog (Timer2 is used). If there is no hardware response or an error message
from the SSM, the firmware sets the SYS_ERR bit in the events.system event byte. The
SRAM variable debug stores the error code, which contains the firmware error code
(debug.errorCode) and the SSM error code
(debug.ssmErrorCode). See Error Codes from Related
Links.
It is possible to start up RXMode with or without VCO tuning at RXMode start-up. For more information, see the Set System Mode SPI command.
After a successful start-up of the RF front end, the RX DSP is enabled and the Get RX Telegram state machine is started. This state machine controls the entire telegram reception process including synchronization, signal checking, data reception and decoding. In RXMode(transparent), the received payload data are routed to pins PC3 (TMDO) and PC5 (TMDO_CLK). In RXMode(buffered), the data are written to the data FIFO (DFIFO) for later retrieval. For more details on the description of the get RX telegram state machine, see RX Telegram Handling from Related Links.
The firmware performs the event handling in parallel to the telegram reception.
During the shutdown of RXMode, the RX_ACTIVE pin is disabled and the system returns to IDLEMode.