Proprietary Knowledge Base

    Publish
     
      • Versions of IAR EWARM and GCC Compiler Software for RAIL SDK

        andrasbiro | 06/162/2016 | 07:40 AM

        Question

        What compilers are supported with RAIL?

        Answer

        Silabs Wireless software is compiled using the IAR Integrated development environment and GCC optimizing C/C++ compiler for ARM Cortex-M.

         

        In general, RAIL has no special requirements from the compiler, but we developed and tested it with the following. Also, it should always work with the GCC version shipped with Simplicity Studio.

         

          

        Stack version Compiler version Compiler version
        RAIL SDK v1.0.0 EWARM 7.30.1 GCC 4.9.3
      • Versions of IAR EWARM Compiler Software for Wireless M-Bus stacks

        andrasbiro | 06/162/2016 | 07:34 AM

        Question

        What compilers are supported with the Wireless M-Bus Stacks?

        Answer

        Silabs Wireless software is compiled using the IAR Integrated development environment and optimizing C/C++ compiler for ARM Cortex-M.

         

        As of today we support the following IAR-EWARM with our stack versions.

         

        Stack version Compiler version
        Wireless M-Bus stack v1.0.4 EWARM 7.40.1
      • Si4x6x Variable packet length consideration

        mabuthi | 06/159/2016 | 07:26 AM

        Question

        How to change the length of the packet during reception?

        Answer

        1. It is necessary to define the Payload as consisting of (at least) two fixed-length fields.
        2. The byte(s) that contain the encoded or enumerated packet length information should be in Field-1.    
        3. The purpose of breaking up the Payload into two or more fixed-length fields is to allow our internal MCU the time process the requested change in field length.  The chip cannot change the length of a field that is already being processed; it can only change the length of a field that is yet to be processed.  Thus while the chip is receiving bytes for Field-1, it can change the length of (for example) Field-2, as that field has not yet started.
        4. The fixed length of Field-1 should be defined as several bytes, to allow the internal MCU the processing time required to re-configure the length of Field-2.  For example, if the typical Payload length is 20-bytes, Field-1 might be defined as 5-bytes in length, and Field-2 as 15-bytes in length.  As the bytes of Field-1 are being received, presumably the encoded packet length information is the first byte.  The host MCU must retrieve this first byte from the chip, determine what new packet length is desired, and issue a PACKET_INFO command back to the chip.  Upon receipt of the PACKET_INFO command, the chip will re-configure the length of Field-2.  The remaining bytes in Field-1 must be of sufficient length to allow this complete timing process to take place.  Part of this is under control of the RFIC, while part is under control of the timing of the host MCU.  Therefore it is difficult to provide one value (in bytes or microseconds) of how much time delay to allow.  Obviously as the data rate is increased, the available time decreases. 
        5. The PACKET_INFO command must contain several pieces of information.  First is the number of the destination field whose fixed length should be changed to a new fixed-length value.  In the above example, this would be Field-2.  The previous fixed-length value would have been 15-bytes (again, taken from the example above).  Let us assume that you desire to change the length of Field-2 to 20 bytes (25 total bytes in the Payload, 5-bytes in Field-1 and now 20-bytes in Field-2).  Two additional parameter need to be passed in the PACKET_INFO command.  One of them is the new field-length value of Field-2, which needs to be written in the LEN [15:0] parameter.  The other parameter is the difference between the new value and the old value (i.e., 5 bytes, in this example), which needs to be written in the LEN_DIFF [15:0] parameter.  LEN_DIFF is a signed value, and so it is possible to decrease the field length by this method as well.
          Please note that the PACKET_INFO command does not modify the Field-2 length value, it always remains from the first time it is initialized.
      • Si4x6x direct RX mode consideration

        mabuthi | 06/158/2016 | 10:35 AM

        In direct mode the DATA_OUT pin output the real time demodulated data. Even if there is no packet signal over the air, the chip will still receive the noise in the background, demodulate and output the random bits.

         

        To avoid this, the squelch function need to be enabled, that will disable the output below an RSSI threshold. Squelch can be turned on by setting the two bit SQUELCH field of the MODEM_OOK_CNT1 property to 1. Squelching of the RX_DATA output is configured conditional (amongst other measures) on the current RSSI reading. If current RSSI remains below the RSSI threshold defined in API property MODEM_RSSI_THRESH there will be no toggling on RX_DATA whereas if it is above this level there will be toggling on RX data. Nevertheless the RSSI threshold need to be fine-tuned after enabling the squelch. Please note that this will make the sensitivity of the receiver a bit worse.

      • Si446x direct mode consideration

        mabuthi | 06/158/2016 | 10:26 AM

        In Direct mode, if temperature is changing greater than 15C, VCO re-calibration is needed, because in case RX state is continuous, the VCO calibration is not performed. The chip must be commanded to do a state change (START_RX or a CHANGE_STATE command) to invoke a VCO calibration.

        VCO consists of analog components which have temperature tolerance. Therefore, if temperature changes, then VCO free running frequency will change too. At this time, the PLL tries to adjust the VCO frequency, but if the frequency offset becomes greater than the PLL’s linear tracking range, performance (most notably phase noise) will start degrading and at extreme cases the PLL may come unlocked. A periodic VCO frequency re-calibration over temperature prevents this scenario from happening. 

      • Wireless Gecko (EFR32) Rx direct mode

        zopapp | 06/158/2016 | 09:08 AM

        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:

         

        • It is changing at the demodulator’s clock rate, which is typically 5-10x higher than the DR itself.
        • It only works in 2FSK mode by simply outputting the sign of the frequency with regards to the nominal frequency, i.e., if the frequency is higher than the nominal it will output logical ones, if it is lower that the nominal frequency it will output zeroes.
        • There is no frequency error compensation on it.
        • It is not synchronized to any clock.

        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.

         

        PRS_offering.png