Proprietary Knowledge Base

      • Max hold or Average mode in ETSI EN300 220 section 7.7 Modulation Bandwidth measurements

        zovida | 09/262/2014 | 05:46 AM


        What SA settings can I use during modulation BW measurements in ETSI?


        For the Modulation Bandwidth measurement method ETSI says the following:

        "The spectrum analyzer SHOULD be set to: peak detector function and max hold trace mode."


        With applying these above SA settings the phase noise can cause compliance issues. In the 868 MHz frequency band the 1 MHz offset (-36 dBm/100 kHz) in case of high power (+27 dBm) Si446x radio boards, meanwhile the 6 MHz offset (-54 dBm limit under 862 MHz) in case of Si4010 crystal less operation can get close to the limit.


        This is the real concern, because the exact wording of the standard says MAX HOLD *should* be used on the spectrum analyzer. This is not a requirement, but a suggestion, otherwise there would say *“shall be used”*. The standard calls for spurs as results of mixing, and suggests to use MAX HOLD to catch them during transmit bursts. BUT, it does not make sense to measure noise in MAX HOLD. Noise is measured using averaging (RMS detector and/or trace averaging). So an expert test house does this measurement in 2 steps. First in MAX HOLD, and 2nd using averaging (if no spurs are visible).


        With applying trace averaging the phase noise level (of Si446x, Si4010) will be under the limits with nice margin. 

      • Si446x RX filter bandwidth

        zopapp | 09/261/2014 | 04:38 AM


        How do I know the exact RX filter bandwidth on Si446x?


        There are two methods the Rx bandwidth (also referred to as IF bandwidth) gets selected on Si446x devices.

        1. Based on the reference XO/TCXO accuracies entered on tab “Frequency and power” on any Rx related example project in the RCA (Radio Configuration Application) WDS calculates the necessary Rx bandwidth to accommodate the Tx signal even at worst case frequency misalignments.

        2. On the “RF parameters” tab users can bypass the automatic calculation mentioned in pont#1 by ticking the check-box next to the “RX bandwidth” entry. By doing so the entry becomes active and an arbitrarily RX bandwidth selected by the user can be entered (and the “Crystal tolerance Rx/Tx” entry boxes disappear on the “Frequency and power” tab).

        On the chip, however only a limited number of filter bandwidths can be set. So no matter which method the Rx bandwidth is set by it may happen that the exact required bandwidth cannot be set and the one wider bandwidth will be selected. It may therefore be desired to know what the exact bandwidth is on the part.

        If you press the “Create batch” button located in the lower left corner of the RCA projects and select “Preview batch” from the pop up menu the chip configuration will be listed as shown below. Now, right above the RESET command you will find the exact receive bandwidth: # WB filter 1 (BW = 99.20 kHz); NB-filter 1 (BW = 99.20 kHz) #




        Why do we have two filter bandwidths listed? : # WB filter 1 (BW = 99.20 kHz) is the bandwidth of the filter bandwidth in acquisition (aka: preamble search) mode while NB-filter 1 (BW = 99.20 kHz) is the filter bandwidth in tracking mode. In this particular example the two bandwidths are equal. If filter bandwidth gearing is enabled, however (by ticking the “Enable Adaptive Ch. Fil. Bw” on the “RF parameters tab” – only visible if “Enable PLL AFC ” is ticked) the two bandwidths may be different. Typically the tracking filter is narrower bandwidth than the acquisition filter. (Hence the WB- Wide Band and NB – Narrow Band abbreviations.) You will find more on filter bandwidth gearing in chapter 3.4 in AN734.

      • Which Board header file do I use?

        kpszupin | 09/255/2014 | 03:28 PM


        Which Board header file do I use?


        Ember Desktop's AppBuilder offers a few different board header files under the "HAL configuration" tab.

        dev0680.h - Basic EM35x Breakout Board support for non-EM358x chips or revision A and B breakout boards.

        dev0680etm.h - EM35x Breakout Board support for EM358x chips with revision C breakout boards.

        dev0680spi.h - GPIO configuration used by EM35xx chips running as EZSP-SPI NCPs.

        dev0680uart.h - GPIO configuration used by EM35xx chips running as EZSP-UART NCPS with hardware flow control.

        ref0657.h - GPIO configuration used by EM35xx ICs controlling an RF front-end module (FEM), such as the Skyworks SE2432L or the RFMD RF6525.  (See for published reference designs.)

        GPIO configuration is listed in the top comments of each header file. After making your selection and generating your project, AppBuilder will create a header file for you to edit to fit your project needs. The header file will be located in your EmberZNet directory under em35x/app/builder/{ProjectName}/{ProjectName}_board.h

      • What can I do to fix "ERROR: Wrong AHB ID"?

        kpszupin | 09/255/2014 | 03:17 PM


        What can I do to fix "ERROR: Wrong AHB ID"?


        This is most likely a JTAG communication problem. Here are a few things you can try to help recover from the problem:

        * Update the target ISA3 to the latest firmware by running em3xx_isa.exe with the target adapter specified by the "--ip" argument (or you can omit this argument if the ISA3 is connected directly via USB).

        * Before performing the em3xx_load operation, short the nBOOTMODE pin (PA5 input) to Ground (which can be done by pressing the BOOTLOAD button on the EM35x Dev Kit board) and hold it that way for the duration of the load operation, then let go when the operation concludes. This can force the chip into the low-level bootstrapping mechanism, where it is sometimes more responsive to JTAG/SerialWire operations.

        * Make sure that the em3xx_convert.exe run by your post-build process (in IAR Embedded Workbench) is from the same installation of ISA3 Utilities as your em3xx_load.exe binary.

        * Check that you're not trying to operate on a pre-production ("ES" revision) model of EM35x silicon. (It would have an "ES' marking on the top of the IC package.) These earlier revisions are subject to some incompatibilities with newer version of ISA3 Utilities and EmberZNet 4+ software.

      • How to setup Custom MFG Tokens

        dprodrig | 09/251/2014 | 01:00 PM


        How do I setup Custom MFG Tokens?


        The first thing to do when setting you custom manufacturing tokens depends on whether or not you want to use a custom token header file. It does not matter if you choose to use a custom header file, or if you modify the generated token header file as it will be the only one used in the project. However, if you do decide to use your own custom header file you must define APPLICATION_MFG_TOKEN_HEADER to be your custom header file in your IAR preprocessor. When creating a custom token header file, token.h has helpful instructions. It is also important not to use inclusion guards (#ifndef/#define) in your application header files as the token reference scheme will not work with them. (If you are adding the define to App Builder, make sure to select the -D option).


        Please note that if you do decide to modify the generated file you will need to be very careful not to overwrite it once modified. The main concern of it being overwritten is when you regenerate your project. At that point it will, by default, have the tokens file selected as being overwritten. Make sure to deselect it any time if you have made edits to the file that you want to keep.


        General token definition found in token.h:
        * The most general format of a token definition is:

      • Not receiving

        atgosi | 09/245/2014 | 02:19 PM


        I am transmitting, but the chip does not receive anything. What should I do?


        First, make sure that you are indeed transmitting, and it is the right packet that is being sent. Outputting TX_STATE, TX_DATA, TX_DATA_CLK to the GPIOs will confirm that the chip goes to TX State, and also, the data being transmitted is what you would expect. If that is all correct, go to the RX side, output RX_STATE, RX_DATA, RX_DATA_CLK signals and compare them against TX_DATA_TX_DATA_CLK. The waveforms should match. 


        If they do not, check the radio configuration, there might be a mismatch; take a closer look at center frequency, deviation, modulation type, data rate, etc. Also, you might need to adjust the cap bank value to fine tune the frequency. Measuring the current consumption on the TX side may give you an idea that it is indeed in TX State and it is transmitting with high output power (of course, you can measure the output power with a spectrum analyzer directly). Likewise, measuring around 10/13mA indicates that the device is indeed in RX State.


        If TX/RX_DATA waveforms do match however, it means that the device received the data correctly, but for some reason it is not getting through the packet handler. In such a case make sure that the PREAMBLE and SYNC word detection signals arrive correctly (you can configure these to the GPIOs, as well). Also, you may want to confirm that the PACKET_RX interrupt is configured, the packet length has been entered correctly (via START_RX command / PKT_FIELD_x_LENGTH properties).


        If none of these helped, check whether there has been a CRC error, or Command Error event. Note that if there is a CRC error, you need to leave RX state, reset the RX FIFO by a FIFO_INFO command, and then you can go back to RX state.


        Lastly, you may want to check the next states for the START_RX command (i.e. RX_TIMEOUT_STATE, RXVALID_STATE, RX_INVALID_STATE). In most cases, for invalid preamble (i.e. RX_TIMEOUT_STATE) you may want to use ‘0 – No change’ in order to have the receiver staying in RX state without any interruption while searching for preamble (if it was ‘8 – RX state’, there would be a short interruption in the received data due to the RX->RX state transition whenever the invalid preamble timeout occurs). For valid packet (i.e. RXVALID_STATE), however, you may want to avoid ‘0 – No change’, and use RX State instead. The packet handler needs to be re-armed after a packet is successfully received, and in order to that the chip has to re-enter RX state; this can be performed by selecting RX State for RXVALID_STATE. A ‘No change’ would not initiate restarting the packet handler; it would stay in receive mode, and although still outputting the received data, no longer searching for preamble and sync word, and therefore not putting the data into the RX FIFO.

      • GPIO toggling

        atgosi | 09/245/2014 | 02:18 PM


        Can I toggle a radio IC GPIO pin?


        Yes, it is possible to drive a GPIO pin high/low via the GPIO_PIN_CFG command (DRIVE0/DRIVE1). The way it works is that you need to send this API command via the SPI to toggle the pin. Make sure that you enter 0 – Do nothing for those pins that you do not want to toggle when entering the input parameters for the command.

      • GPIO configuration

        atgosi | 09/245/2014 | 02:17 PM


        I have plenty of I/Os on the host MCU to control the Si446x. Do I benefit from connecting all the GPIOs of the radio IC to the host MCU? How should I configure the GPIOs?


        It depends on your application. You may want to consider configuring a GPIO to CCA (i.e. Clear Channel Assessment: it indicates whether hitting the RSSI threshold, or not), RX/TX State, RX FIFO Almost Full, TX FIFO Almost Empty, CTS, etc. Also, POR at GPIO1 may be a useful configuration for more efficient power up. At room temperature the POR typically takes ~900us-1ms, and the absolute maximum is 5ms. Polling GPIO1 can be more efficient, since you do not need to use a 5ms for every power-up. Note that wiring the SDN pin to the host MCU is highly recommended (there is no SW reset in the API); this also requires a host MCU I/O.

      • Clear Channel Assessment (CCA)

        atgosi | 09/245/2014 | 02:15 PM


        What is CCA (Clear Channel Assessment) and how to use it?


        You can output CCA (Clear Channel Assessment) to any of the GPIOs to signal whether the received signal strength indicator (RSSI) exceeds a pre-defined threshold, or not (see GPIO_PIN_CFG command, and MODEM_RSSI_THRESH property for more details). Alternatively, you can configure an NIRQ hardware interrupt for this event via the INT_CTL_EN and INT_CTL_MODEM_ENABLE properties. In general, the CCA is a useful feature when you need to make sure that a given frequency channel is clear before actually transmitting; or when your receiver needs to periodically wake up to check whether there is TX going on to receive (in this case you may also want to check the Latched RSSI feature: the chip can go back to Standby autonomously if the Latched RSSI does not hit the threshold; see MODEM_RSSI_CONTROL: CHECK_THRESH_AT_LATCH).

      • 32kHz RC oscillator calibration time

        atgosi | 09/245/2014 | 02:15 PM


        How long does the internal 32 kHz RC oscillator calibration take?


        It takes about 1ms.