2.8.1 RX Overview
The ATA8510/15 contains two receive paths A and B whose parameters, such as the modulation type, data rate and telegram settings, can be set separately and are described in more detail in RX Telegram Handling and General RX Settings. 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.
| Address | Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|---|
| 0x0019 | sysStartConfig | RF_CAL | ANT_TUNE | VCO_TUNE | IDLEModeSelector | — | TMDEN | OPM[1:0] | |
Furthermore, it can be activated 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. For more information, see Set System Mode.
| Name | Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
|---|---|---|---|---|---|---|---|---|
| systemModeConfig | RF_CAL | ANT_TUNE | VCO_TUNE | IDLEModeSelector | — | TMDEN | OPM[1:0] | |
| serviceChannelConfig | enaPathB | enaPathA | ch[1:0] | — | ser[2:0] | |||
The data reception is split into RXMode(transparent) and RXMode(buffered), selectable by the transparent mode data enable (TMDEN) bit. Both modes are described in more detail in the following subsections.
The RXMode can be used for all services without any restrictions. It supports service independent features such as:
- Subchanneling (see Subchanneling for more information)
- RSSI measurement (see RSSI Measurement for more information)
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) as shown below.
| 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 | DFIFO_TX |
| 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, pin 29 (PB7) can be configured as the RX_ACTIVE signal to monitor the status of the RF front end. The RX_ACTIVE pin can be configured in the eepEventConf.sysEventConf.RX_ACTIVE_EN and RX_ACTIVE_POL EEPROM variables. The RX_ACTIVE signal can also be used for biasing an external LNA, see External LNA Control.
| 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 RXMode is activated, 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 the RF frontend is activated.
The start-up of the RF front end is done 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 error code is stored in the SRAM variable debug, which contains the firmware error code (debug.errorCode) and the SSM error code (debug.ssmErrorCode). For more information, see Error Codes.
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. A detailed description of the Get RX Telegram state machine is given in RX Telegram Handling.
The event handling is performed by the firmware in parallel to the telegram reception.
During the shutdown of RXMode, the RX_ACTIVE pin is disabled and the system returns to IDLEMode.