Note that at the time of writing this article this information is captured incorrectly in the data sheets. The following minimum preambe length requiements are needed for packet loss free reception and no sensitivity loss compared to non antenna diversity applications (less the the insertion loss of the T/R switch and the longer traces obviously).
When AFC is not enabled antenna diversity requires 80 bits of preamble.
When AFC is enabled antenna diversity requires 88 bits of preamble.
Si446x revC2A and A2A devices support antenna diversity with DSA. This operation requitres 64 bits of preamble. Note however that co-channel rejection with DSA in antenna diversity mode is poor so this configuration is not recommended.
Leave all the antenna diversity parameter calculations to WDS. Make sure you transmit the minimum length of preamble and Rx will just work.
What is causing spectral splatter?
Let’s have a look at this concept through a simple example. Suppose you transmit a pure CW signal. Your spectrum will look like a single tone at the carrier frequency. When you start switching this CW tone on and off with a square wave pattern the spectrum of the square wave pattern will be convolved with the CW spectrum resulting in a sinx/x like overall spectrum profile around the carrier. If the switching is not part of the core modulation (in this example a CW tone) than the increased spectral components induced by switching are not desired and referred to as spectral splatter.
If you substitute the CW tone in above example with an arbitrary modulated signal and the switching pattern with an RF packet start / stop ramp you arrive at real example that will behave the same way as the simplified case.
How do we control spectral splatter?
Spectral splatter can be kept at bay by controlling the ramp profiles in time domain at the beginning and end of the packets. As a rule of thumb the longer the ramp the narrower its splatter spectrum. The goal here is to keep the splatter spectrum within the modulated signal’s own spectrum so no out of band splatter occurs at all. Although this cannot be achieved for all modulating formats on Si446x there are turning knobs the issue can be mitigated with.
What are the knobs on mitigating spectral splatter on Si446x?
1) The first knob is field PA_TC in API property PA_TC. This field directly controls the ramp time on the PA. WDS configures this filed to a value of 0x1D by default which leaves two notches until the maximum ramp time is achieved at 0x1F. If a loner ramp is needed adjust this field manually to one of the higher values.
Note1: If you have increased this value you may want to readjust API property PA_RAMP_DOWN_DELAY to prevent the PA from shutting off before the ramp down has finished. Increase this value if you see issues at ramp down.
Note2: This scheme applies to all ramp up/down events in OOK modulation.
2) On Si446x revC2A (and Si4467/68 revA2A) a digital power ramping feature was introduced that sequentially steps through PA_POWER_LVL values (from min to max with a configurable step size) with a configurable dwell time on each of these steps. Much longer ramp times can be achieved with this approach.
You can enable this feature by setting field DIG_PWR_SEQ in API property PA_MODE. You can configure the dwell time and the step size in API property PA_DIG_PWR_SEQ_CONFIG.
Note that with this method the built-in PA ramp (discussed at (1)) is not applied between the steps only at the 1st step at minimum power level.
The digital power ramp feature has a bug that is not fixed with released FW patches: the power ramp only takes effect at ramp up but does not take effect at ramp down.
There is a SW workaround to the issue:
1) Do the following SPI write 0xF1474B00. Wait for CTS.
2) Make a transition to SLEEP state
3) Make a transition back to READY state
On Si4467/Si4468 A2A devices there exists an API command called OFFLINE_RECAL. The description of this API is rather confusing so I am trying to make things clear here.
The purpose of the API function is to allow the application to perform certain calibrations at its earliest convenience (rather than the FW doing it regardless of application state, i.e., doing a calibration while a message is being received ruining so the reception.)
Note that all calibrations are performed at POWER_UP. The OFFLINE_RECAL command repeats some of these calibrations if a temperature change makes this necessary.
There are two parameters to the API command:
OFFLINE_CAL: This bit tells the FW the type of calibration it must perform. There are two types of calibrations: OFFLINE_CAL and OFFLINE2_CAL. Which one the application needs to perform shall be read back from GET_CHIP_STATUS: INFO_FLAGS: CAL_TYPE.
TEMP: This bit tells the FW which temperature range the calibrations should be performed to. Use LOW_TEMP (0) if the application operates in the -40 to 85C range and use HIGH_TEMP if the application operates in the -40 to 135C temperature range.
Note that this field is missing from the public API. The public API should look like this:
The FW notifies the application when to run the offline calibrations. When a pending interrupt shows up in GET_CHIP_STATUS: CHIP_STATUS: CAL the application shall run the offline calibration type defined in GET_CHIP_STATUS: INFO_FLAGS: CAL_TYPE at its earliest convenience. The OFFLINE_RECAL command is recommended to be invoked in READY state. If it’s not invoked in READY state it will go back to READY state regardless which may interrupt Tx/Rx operations.
Note that a calibration notification for the 32k oscillator also shows up in GET_CHIP_STATUS: CHIP_STATUS: CAL. This means that if the 32k oscillator calibration and offline re-calibrations are used together the notification will not distinguish between the two rendering it not so useful. Note that the 32k oscillator calibrations will be run automatically at the next SLEEP transition without any application interaction so this is truly just a notification in this case. (More on the 32k oscillator calibration you can read at API properties GLOBA_WUT_CONFIG and GLOBAL_WUT_CAL in the API documentation.)
If you are in the unlucky situation of running the 32k clock calibration as well as the offline calibrations in one application, you can do one of the followings:
Measurement results show that EFR32 MG1 complies with EN300 328 category1 blocking requirements with good margin in 802.15.4 OQPSK DSSS mode (ZigBee PHY).
The blocking test has been performed as per chapter 188.8.131.52.1.
RFIC: EFR32 MG1
Board: PCB4252A 2.4 GHz
SDK: Flex 184.108.40.206
RAIL: RAIL 220.127.116.11
App: RAILTest 1.4.2
This command set configures the part to the 802.15.4 OQPSK DSSS ZigBee PHY.
Payload length is 16 bytes.
ZigBee packet: Agilent E4432B
Blocker: HP 8665B
Conducted PER curve
1% PER Sensitivity: -97.5 dBm
10% PER Sensitivity: -98.5 dBm
Conducted Blocking at various channels
Desired signal power level is set to (10% PER sensitivity + 6 dB) = -92.5 dBm.
f_Channel11: 2405 MHz
f_Channel18: 2440 MHz
f_Channel26: 2480 MHz
Since you will only see the release notes once when you install the new version, here it is for reference:
Maximum data rate restriction based on XO frequency introduced in Range Test project
Help text added to Enable IQ calibration control
DSA detection offered in antenna diversity Rx mode on Si446x C2A/A2A revisions
PSM (Preamble Sense Mode) Rx mode configuration update
Description of Custom packet Rx with PSM project updated
New FW patch added for C2A Si446x revision that fixes a PSM related bug
New FW patch added for A2A Si446x revision in PSM Rx mode that fixes a PSM related bug
Auto frequency hop Rx configuration update when DSA is enabled
Introduced preamble pattern selection "Std. 1010 pattern (>= 16 and < 32 bits)" for DSA detection
Help text updated at Enable DSA control
Data rate and preamble length unit changed to ksps and sbytes, respectively in 4(G)FSK mode for clarity
Description of Manual frequency hop Rx project updated
PSM (Preamble Sense Mode) Rx mode introduced
High power PA ramp down early shut off issue fixed
Labels updated on CRC check boxes in 802.15.4g bidirectional packet project
Manchester decoding on preamble restricted to no-standard preamble pattern selections
Manchester on Constant 1's or 0's control restricted to Tx projects only
Bit order radio button behavior changed on the Packet configuration to fix a Si446x B1B revision related bug
Non-standard preamble pattern byte order reversed to match over the air pattern with GUI
Direct Tx project configuration updated with matching Rx configurations
PA power level control made unavailable in the Range Test project
Although there is no explicit AFSK demodulation support on our Si446x product portfolio, with a carefully chosen receive configuration and a piece of decoding SW running on the host MCU it may be pulled off.
AFSK modulation is typically two audio tones 2FSK modulated onto a carrier. One tone represents marking the other spacing.
Form the EZRadioPro receiver’s perspective an AFSK signal is an FSK signal whose DR changes with the two audio tones’ frequency. As an example take the Bell 202 modulation format where one audio frequency is 1200 Hz while the other is 2200 Hz. From the receiver’s perspective these signals translate to 2400 bps and 4400 bps DR streams, respectively. The reason the DR is twice as much as the audio tone frequency is that a full cycle on the audio tone translates to two bits: a 1 and 0 (or vice versa).
There are a couple of limitations on EZRadiPro that make the demodulation of such a signal troublesome. (1) EZRadioPro’s receive architecture is designed to operate on a single data rate throughout the whole radio packet and (2) there are no analog signals available from anywhere within the demodulation process, only digital signals come out.
The solution to overcome above issues is:
The limitations (and their mitigation) of above solution are:
The ultimate question after such a receive algorithm implementation is sensitivity. You will have to verify this for yourself on your own implementation.
From WDS start off from a direct Rx mode project with above considerations and you can start measuring straight away. As a 1st check hook up your GPIOs with both RX_DATA and RX_RAW_DATA on a scope (that is triggered off of the beginning of the AFSK packet in air) and observe (eyeball) the signal quality. Change the input power level and check where the signals fall apart, this quick experiment will give you a 1st feeling on sensitivity performance.
This is a little tip for LDC Rx mode operation on Si446x that could possibly save you some frustration. When LDC Rx is running do not attempt to change the state of the radio without stopping the LDC Rx operation first. These attempts may lead to unexpected and funny behavior.
After LDC Rx is enabled the radio state machine will automatically enter into LDC Rx mode and will stay there until LDC Rx is disabled. No START_RX command is needed to start the operation, and it follows than that the automatic state transitions as defined by the START_RX command will not take place either.
If an action including a state change (i.,e Tx operation) is required upon either packet reception or a timeout event in LDC Rx mode, disable first LDC Rx and then proceed.
For enabling LDC Rx operation the WUT (Wake Up Timer) must be enabled too. As both bit fields that enable LDC Rx (WUT_LDC_EN) and the WUT (WUT_EN) reside in the same property (GLOBAL_WUT_CONFIG) one write to this property that enables both is a legitimate way of starting LDC Rx.
For disabling LDC Rx it is enough to disable LDC Rx only (in field WUT_LDC_EN) but disabling the WUT too (in field WUT_EN) will not make any harm either.
In a direct Rx configuration the received data is directly output to an IC pin that in turn directly feeds another MCU pin for further processing. Typically in such applications all the signal detection (in form of preamble and / or sync word detection algorithms) are done by the processing MCU as opposed to the receiver’s own frame controller (FRC) block.
In the RAIL library there exist a function that places the receiver into this mode: RAIL_DirectModeConfig. When enabled the RX_DATA will be output to EFR32_PC11. This output data has the following properties:
Note that at the writing of this article it is stated in RAIL documentation that parallel to RX_DATA an RX_CLK signal is also output. This is not correct, not the least because there is no RX_CLK signal RX_DATA is synchronized to.
Above direct mode operation can also be referred to as asynchronous direct mode operation. What about synchronous direct mode operation, you may quite rightly ask. Synchronous direct mode operation also provides an RX_CLK signal RX_DATA is synchronized to. Such a mode does not exist on the Wireless Gecko (EFR32).
The reason it does not exist is that a successful sync word detection gates the availability of the RX_CLK signal. So without sync word detection there is no RX_CLK, if you have sync word detection, however you may as well carry on and use packet mode. If for some reason RX_CLK and RX_DATA (placed on pins) still come useful in your packet mode application keep an eye on the radio related PRS signals (see below the current offering) in the RAIL documentation, sooner or later RX_DATA and RX_CLK will show up.
How do I know what receive bandwidth has been configured on the Wireless Gecko (EFR32)?
The selected receive bandwidth in the EFR32 radio configurator (also referred to as IF bandwidth or channel bandwidth) depends on many input parameters.
Primarily the bandwidth is derived from the modulation format and the XO accuracy parameters at the Tx and Rx sides.
There is also an option to bypass the calculation and set the bandwidth explicitly in the advanced section.
If this latter option is not used it is a rather useful information to know what the bandwidth has been set to. You can extract this information from a log file that gets updated every time generation is run. At the preview section select the efr32_configurator_log.txt file that in turn will appear in the window below. Somewhere in the log file you will find the bandwidth the receiver has been configured to (as well as the IF frequency that is also an important piece of information especially when image rejection is to be tested.)
The auto frequency hopping feature on EZRadioPro (Si4x6x) devices is an Rx feature only where the receiver autonomously scans through a predefined channel table for the expected packet.
It is primarily meant for applications where the transmitter changes its frequency channel between packets but stays on the currently selected channel for the duration of the whole packet transmission. In auto frequency hopping mode the receiver has no prior knowledge where to expect the next packet so it duly keeps scanning all the possible channels until it finally “finds” the signal. This mode of frequency hopping operation may be referred to as asynchronous hopping as the Tx and Rx nodes have no knowledge which frequency channel the other is staying at at any given time.
Typically in such asynchronous hopping applications the Tx node has to transmit a relatively long preamble to allow the Rx node enough time to find the right frequency channel.
To sum it up what the auto frequency hopping feature supports is asynchronous hopping operation in the receive node.
Now, if the receiver knows at what frequency and at what point in time the Tx will transmit there is no need for it to scan a wide range of frequency channels. It “simply” has to be on the right channel at the right time to receive the packet. This mode of frequency hopping operation may be referred to as synchronous hopping as the Tx and Rx nodes are moving together both in frequency and time.
Now, the auto frequency hopping feature does not support synchronous frequency hopping in neither the Tx nor the Rx node.
This does not mean however, that synchronous hopping systems cannot be built with EZRadioPro devices. It is, however the task of the host MCU to direct the Tx and Rx nodes to the right frequency at the right time. It is important to note, however that the auto frequency hopping feature is of no help whatsoever in synchronous hopping applications.
This article is part of a series that discusses various aspects of auto frequency hopping. Find the links to the other articles below.