When you select the “Preamble pattern” in Rx projects on the “RF parameters” tab in WDS’s RCA you will see options starting with the notion “Non std. pattern”. This notion stands for non-standard preamble detection.
What exactly is non-standard preamble?
Non-standard preamble is *any* repeating pattern that is not a standard preamble. Standard preamble is a string of repeating 0101 (or 1010) pattern. It is important to note that these patterns are to be interpreted at the data rate the receive modem is configured to. For example a 0101 pattern at 4 kbps in the air does not look any different to a 00110011 pattern at 8 kbps; from the receive modem’s perspective, however the pattern will be standard when configured to 4kbps DR and non-standard when configured to 8kbps DR.
Why do we distinguish between standard and non-standard preamble patterns?
Before we answered the question let’s have a detour on why a preamble is needed for the receiver to start with? The reason for using a preamble is twofold:
As far as the 1st aspect is concerned the control loops will settle on a non-standard preamble much the same way as they would do on a standard preamble (their acquisition time will be a bit longer though ). Some of the algorithms however will be different (as they can only work on standard patterns) which in turn will lead to different modem configurations. As far as the 2nd aspect is concerned in the case of a non-standard preamble the detection (pattern recognition) must happen in the packet handler as the modem’s preamble detector algorithm can only work on standard patterns. This again will lead to different chip configuration and a *requirement* of configuring a non-standard preamble on WDS’s “Packet” – “Preamble” tab. Detecting a non-standard preamble is much the same procedure as detecting a sync word. Why do we bother than with the detection of the non-standard pattern as opposed to just detecting a sync word? There are still a few benefits of doing the detection.
To answer the question at the beginning of the paragraph we distinguish between standard and non-standard preamble as they ultimately require different modem / packet handler configurations. Non-standard preamble detection is essentially providing alternative means of detecting a preamble with all its benefits.
Why do I see two non-standard preamble patterns in the “preamble” pattern drop down menu in WDS?
The following paragraph holds for WDS version 188.8.131.52. The two different non-standard preamble pattern options only differ at length. One is greater than (or equal to) 32 bits the other is less than 32 bits. This length is the length of the whole preamble pattern transmitted to the receiver not just the core repeating pattern. If the length of the whole preamble is less than 32 bits we don’t recommend performing preamble detection. To avoid detection on noise we recommend a pattern (to be detected) length of at least 20 bits. Now, this would leave only 12 bits for the receiver to settle if a 32 bit long preamble is transmitted. It can still manage on this many bits but proper operation is not guaranteed any longer on less bits. Therefore no preamble detection will be done in the receiver if the “less than 32 bit” option is selected. This is somewhat misleading as even though there is “Non std. pattern” explicitly appearing in the descriptor text, if it is less than 32 bits long no preamble detection will be done whatsoever. In such a scenario preamble detection is skipped and only sync word detection is performed. If the pattern length is greater than (or equal to) 32 bits the previously described operation applies. *If you are willing to take the risk of having more false detects (i.e. the cost of a false detect is relatively low), than you may as well use a lower than 20 bit pattern detection threshold which will in turn shift the minimum required preamble pattern length accordingly. I.e. if you set a 16 bit pattern detection threshold you can get away with transmitting only 12 + 16 = 28 bits preamble to the receiver. In such a case do select the Non std. pattern > 32 bit from the drop –down menu.
How do I set up a non-standard preamble in WDS?
The following paragraph holds for WDS version 184.108.40.206. At the Rx side the only preamble pattern that requires configuring a non-standard preamble is: Non std. pattern > 32 bits. Once you have selected this preamble pattern, set up the non-standard pattern itself on the “Packet” tab under the “Preamble” section in the “Preamble pattern (on air interface)” segment. This entry is the core repeating pattern itself. As far as the Rx side is concerned you are done. At the TX side apart from filling in the aforementioned non-standard pattern entry (this is shared between Tx and Rx) define the “Preamble TX length” too. The TX will keep transmitting (over and over) the core preamble pattern until the transmitted number of bytes reaches the limit specified at “Preamble TX length”.
Good to know non-standard preamble related points on Si446x
How do I retrieve and re-apply the results of IQ calibration on Si446x?
Since the original writing of this article the C2 and A2 versions of the Si446x family have also became available where all the following "trickery" is not necessary. There is a standard API command through which retrieving and forcing IQ calibration parameters can be done. The API command is called IRCAL_MANUAL. For more information on this command, please refer to the API documentation. Read on if you have B1 versions of the ICs!
In a receive application after an IQ calibration has been performed (in order to improve image selectivity) it may be desired to retrieve the calibration values and apply them manually when the part enters into Rx state again after a RESET event. With this scheme the IQ calibration can be skipped (in subsequent receive functions) saving so a significant amount of time (~ 250 ms) where the receiver would otherwise be “blind” being busy with performing a calibration procedure.
This scheme can be applied if there is less than +/- 30 degreeC temperature change since the last calibration event and the receive frequency stays within the same frequency band. Same frequency band means that the division ratio from the VCO does not change. This is true for the following frequency ranges on Si4x60/1/3 revB1. 142-175 MHz; 213-262 MHz; 284-350 MHz; 420-525 MHz; 567-670 MHz and 850-1050 MHz. If a frequency shift is performed than spans over these ranges a new calibration is required. Note, that these ranges are different on Si4464.
Even though there is no direct API access to the IQ calibration results they are still stored in HW registers. These registers can be accessed with a special API command. The registers of concern are referred to as iq_calamp and iq_calph. Bits [4-0] contain the absolute value of the calibration result and Bit5 contains the sign of the result. Bits [7-6] have no meaning. Note, that for retrieving and then re-applying the results the format is of no concern, simply the same value must be written back to the registers.
The aforementioned special API command that allows direct register access is referred to as ‘POKE’ for writing registers and ‘PEEK’ for reading them. These two commands have their unique command code in the API which complemented with the register addresses perform the read and write operations. The command code for ‘PEEK’ is 0xF0 and for ‘POKE’ it is 0xF1. The two byte addresses of the registers of concern are the following: iq_calamp – 0x00 0xD6; iq_calph – 0x00 0xD7. So reading both of the values take the following API operation:
(0xF0 0x00 0xD6)
(0xF0 0x00 0xD7)
The chip will return one byte containing the respective calibration result much the same way as it would return a property value in the API. Writing back the calibration results take the following two ‘POKE’ operations (the calibration values below are for demonstration purposes only).
'POKE' 'iq_calamp' 16
(0xF1 0x00 0xD6 0x16)
'POKE' 'iq_calph' 0F
(0xF1 0x00 0xD7 0x0F)
There is one more subtlety that is worth mentioning regarding this scheme. The registers of concern only retain their values in SLEEP state if the IQ calibration procedure itself has written the values into them. That is to say if they are written with the scheme described above their values will be lost upon a SLEEP state transition. The implication is that the calibration registers will have to be refreshed after each SLEEP state transition unless a calibration has been performed since the last RESET event. (The reason for this behavior is that the registers of concern are only copies of their “original” counterparts that are located in a memory region whose content is kept upon SLEEP state transitions. The calibration procedure does write the “original” registers, whereas the method above only writes the “copies” of these registers.)
For more information on the IQ calibration itself refer to AN790.
Do you have WiFi devices in portfolio? Are there some 3rd party WiFi devices recommended by you for low power systems based on EFM32 microcontrollers?
No, we work with partners to provide WiFi connectivity.
Solution examples are: Qualcomm and Atheros solutions. Digi and RTX offer module solutions.
What are your plans for IPv6/6LoWPAN for IoT connectivity
These will be available with the launch of our Energy Friendly Radio (EFR) product family.
These products will support BTLE, 6LowPAN and IPv6 along with several other protocols.
Do you have evaluation boards with your sub-GHz SoCs ?
Yes we do. Our wireless development kits can be found here: http://www.silabs.com/products/wireless/Pages/DevelopmentTools.aspx
Is there any 3rd party company that manufactures RF modules based on EZRadioPRO chips?
There are a few manufactures RF modules based on the EZRadioPRO chips:
More information about our partners that develop modules can be found at the following link: http://www.silabs.com/products/wireless/wirelessmcu/Pages/Wireless-Modules.aspx
Can the Silicon Labs wireless solutions be used in an industrial/production environment where there is more metal?
It depends on the actual environment.
Silicon Labs provides high output power, high sensitivity RF devices from sub-GHz to 2.4GHz.
Where can I find more examples for my wireless MCU?
Many of the Silicon Labs wireless MCU products are closely related to non-wireless MCU's. In these cases, the application notes and examples for the non-wireless MCU is directly applicable to the wireless MCU.
Here is a list of which standard MCU content can be used to supplement each of the wireless MCU families:
|Wireless MCU||Standard MCU|