Proprietary Knowledge Base

    Publish
     
      • The ins and outs of non-standard preamble detection on Si446x

        zopapp | 05/148/2014 | 10:43 AM

         

        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:  

         

        • Allows the receiver to settle its control loops including the AFC (Automatic Frequency Control), BCR (Bit Clock Recovery) and AGC (Automatic Gain Control). Until all of these loops have not settled it is not guaranteed that the demodulated bit stream will be correct. A standard preamble pattern helps these control loops (less the AGC) settle faster and more accurately as it provides the most bit transitions.
        • Once the control loops have settled the demodulated bit stream will be correct and the receiver can detect a certain pattern in it. Once this pattern is detected the receiver can tell that there is a valid signal to be received in the channel and can optimize its configuration for receiving the rest of the signal. (Such optimization could be narrowing the receive bandwidth and/or slowing down or even freezing the above mentioned control loops. The event when this configuration change happens is referred to as “gear switching”. See more details on it in AN734.) In other words the role of the preamble detection here is to qualify the incoming signal.

         

        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.

         

        • If non-standard preamble detection is done alongside with sync word detection the likelihood of detecting both of these signals on noise will be much less than the likelihood of detecting only a sync word on noise.  (As an alternative method the last portion of the non-standard preamble could possibly be made part of the sync word.)
        • Sync word detection can benefit from a gear switching event at preamble detection. I.e. if a narrower BW filter is selected at preamble detection sensitivity will get better on the sync word. (This however is not recommended on revB1, see the last section of this article.)
        • The radio can assert a VALID_PREAMBLE signal on one of its GPIOs upon detection that may come handy in the host MCU.

        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 3.2.6.0. 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 3.2.6.0. 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

         

        • When non-standard preamble mode is selected the preamble detection threshold at the Rx side is determined by the length of the non-standard preamble pattern. The length of the pattern is set in filed PATTERN_LENGTH [4:0] in property PREAMBLE_CONFIG_NSTD. It follows than that the maximum length of the preamble detection threshold is 32 bits.
        • The preamble pattern itself is set in properties PREAMBLE_PATTERN_31_24 through PREAMBLE_PATTERN_7_0.
        • Field RX_THRESH [6:0] in property PREAMBLE_CONFIG_STD_1 has no effect on setting the preamble detection threshold level in non-standard preamble mode. It only plays a role in standard preamble detection. However, it is good practice to match this value to the preamble detection threshold defined by the non-standard preamble pattern.

         

        • If the value of PREAMBLE_TX_LENGTH is longer than the preamble pattern itself than the pattern will keep repeating until the transmitted number of preamble bits have reached the value in PREAMBLE_TX_LENGTH.

         

        • In non-standard preamble mode the sync word detection time out skip (SKIP_SYNC_TIMEOUT in property PREAMBLE_CONFIG_STD_1) feature is not available.
          In non-standard preamble mode sync word time out is defined as the sum of PREAMBLE_TX_LENGTH and sync word length. Yes, a seemingly TX only property has an effect on the RX configuration here. For example if the preamble length at the Tx side is set to 40 bits and sync word length is 16 bits, the total time window (starting at preamble detection) for finding the sync word is 56 bits. If sync word detection does not happen within this time period the receiver will go back to preamble search state. It also follows than that if the transmitted preamble is longer than the search window sync word detection may get missed.

         

        • The maximum length of the sync word search window is 255 bytes (max PREAMBLE_TX_LENGTH) + 4bytes (max length of sync word). If we assume a detection threshold of 32 bits (and a 0 Rx settling time) preamble detection will happen 4 bytes into the packet. From this point on if the end of the sync word is further away than 259 bytes it will never get detected. This behavior puts a maximum limit of 255 bytes onto the preamble length to be received by the chip. If a longer preamble is transmitted to the receiver the implication will be a low PER floor. ( i.e. occasional packet losses even at high input power levels) Packets will get lost if sync word arrives just before or after the receiver goes back to preamble search state.

         

        • If sync word detection fails for any reason (either it is lost to the aforementioned mechanism or simply has bit errors in it at sensitivity level) the packet handler will reset itself for looking for another preamble, however the modem will not get reset for preamble search state. This is a bug on rev B1 that will be fixed on revC. This bug has the following implication: if gear switching event is configured to preamble detection the modem may slow down or freeze some of its control algorithms upon this. Typically the AFC error estimator is frozen in such a case. This is what we refer to as slow gear or tracking state. If sync word is not detected the modem will stay in slow gear mode and if the next packet arrives at a frequency offset with regards to the previous packet it may get missed (as the AFC will stay frozen at the previous packet’s frequency). For this reason whenever non-standard preamble detection is configured on revB1 we recommend placing the gear switching event to sync word detection as opposed to preamble detection. This will prevent the modem from getting stuck in low gear mode. Note that this bug annuls the second benefit (listed at the beginning of this article) of utilizing non-standard preamble detection. For configuring the gear switching event manually refer to property “MODEM_AFC_MISC” in the API documentation.
      • Si446x IQ calibration

        zopapp | 05/132/2014 | 07:49 AM

        Question

        How do I retrieve and re-apply the results of IQ calibration on Si446x?

        Answer

        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:

         

        'PEEK' 'iq_calamp'

        (0xF0 0x00 0xD6)

        'PEEK' 'iq_calph'

        (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.

      • 3rd Party WiFi devices for EFM32 microcontrollers

        kydando | 05/121/2014 | 05:06 PM

        Question

        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?

        Answer

        No, we work with partners to provide WiFi connectivity. 

         

        Solution examples are: Qualcomm and Atheros solutions. Digi and RTX offer module solutions.

      • BTLE, IPv6 and 6LoWPAN for IoT connectivity

        kydando | 05/121/2014 | 05:03 PM

        Question

        What are your plans for IPv6/6LoWPAN for IoT connectivity

        Answer

        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.

      • Development kits for sub-GHz transceiver products

        kydando | 05/121/2014 | 05:01 PM

        Question

        Do you have evaluation boards with your sub-GHz SoCs ?

        Answer

        Yes we do. Our wireless development kits can be found here: http://www.silabs.com/products/wireless/Pages/DevelopmentTools.aspx

      • 3rd Party RF modules based on EZRadioPRO chips

        kydando | 05/121/2014 | 04:57 PM

        Question

        Is there any 3rd party company that manufactures RF modules based on EZRadioPRO chips?

        Answer

        There are a few manufactures RF modules based on the EZRadioPRO chips:

        • IMST iM871A wireless M-Bus modules
        • Hope Microelectronics RF Modules
        • Telit Wireless Solutions' wireless M-Bus modules


        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

      • Wireless solutions in industrial environments

        kydando | 05/121/2014 | 04:49 PM

        Question

        Can the Silicon Labs wireless solutions be used in an industrial/production environment where there is more metal?

        Answer

        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?

        jonorem | 05/121/2014 | 12:13 PM

        Question

        Where can I find more examples for my wireless MCU?

        Answer

        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
        Si100x C8051F930
        Si101x C8051F911
        Si102x/3x C8051F960
        Si106x C8051F930
        Si108x C8051F911