Proprietary Knowledge Base

      • PLL Settling Time

        Silicon_Labs | 12/355/2012 | 03:24 PM


        If the LDETB signal cannot be used as a PLL settling indicator, what approach should one take?



        As noted in RF Synthesizer Knowledge Base article LDETB signal as PLL settling indicator (90292), the LDETB signal should not be solely relied on as a PLL settling indicator.  This is because it also serves to indicate the PLL is about to lose lock due to temperature drift.  Therefore LDETB can be asserted before the PLL has sufficiently settled in an application, e.g. to within 0.1 ppm of the settled final frequency.

        The best approach is to allow for the maximum settling time and then check LDETB. The Si4133 datasheet (Rev. 1.61 as of this writing) for example gives the following guidance regarding settling time:

        The settling time for the PLL is directly proportional to its phase detector update period TΦ (TΦ equals 1/fΦ). A typical transient response is shown in Figure 6 on page 11. During the first 13 update periods the Si4133 executes the self-tuning algorithm. From then on the PLL controls the output frequency. Because of the unique architecture of the Si4133 PLLs, the time required to settle the output frequency to 0.1 ppm error is automatically 25 update periods. The total time after powerup or a change in programmed frequency until the synthesized frequency is settled—including time for self-tuning—is approximately 40 update periods.

        Note: The settling time analysis holds for RF1 fΦ > 500 kHz.

        Testing should be employed to confirm the worst case settling time for the worst case update rate in any particular application.

      • PSRR of Si533x

        Silicon_Labs | 12/354/2012 | 06:49 PM


        How much ripple can the Si533x tolerate on its supply rails?  Is 10mVpp of ripple acceptable?



        Below is a typical measurement showing supply ripple versus additive jitter.  In this case, with 100mVpp sinusoidal ripple, there is less than 1ps pk additive phase jitter.  Note this is peak jitter, not RMS jitter; the conversion ratio from RMS to pk-pk for a sine wave is 2.818.

        Since this data is for 100mVpp of ripple, we would expect additive jitter of less than 0.1ps pk for 10mVpp of sinusoidal ripple.

      • Si5335’s 475 KHz loop bandwidth option

        Silicon_Labs | 12/354/2012 | 06:31 PM


        What is the purpose of the 475 KHz loop bandwidth option for the Si5335?



        Some applications require local clock generation (e.g. PCI Express reference clocks) that are synchronized to a noisy clock input with noise coupled in from system switching power supply harmonics and/or signal crosstalk. The 475 KHz loop bandwidth option gives the system designer a way to attenuate input clock jitter due to these kinds of noise sources thereby reducing the jitter on the corresponding output clocks. For more information on this feature, refer to AN624.

      • High Number of CRC Errors with Si5338/56 Field Programmer

        Silicon_Labs | 12/354/2012 | 02:34 PM


        I'm getting a high number of CRC errors when burning blank Si5338's and Si5356's with the Field Programmer.



        If you're using the Field Programmer application that was installed with ClockBuilder Desktop v5.0 or v.5.1, then the solution is to install ClockBuilder Desktop version 6.0 or later (available online Jan 2013).  If using v6.0 does not fix the problem, contact technical support.

        We apologize for any inconvenience, and if you're not able to wait until v6.0 is online, you may access v6.0 beta at the link below.  Note that this is a beta version, and Silicon Labs recommends using the official release for anything other than prototyping.

      • Si5335/56 Power Supply Slew Rate Requirement

        Silicon_Labs | 12/353/2012 | 07:59 PM


        What is the minimum power supply slew rate requirement for the Si5355/56?



        The minimum slew rate required on the Si5335/56 power supplies is 0.5V/ns

      • Si533x Power Supply Slew Rate Requirement

        Silicon_Labs | 12/353/2012 | 07:56 PM


        What is the Si533x's minimum power supply slew rate requirement?



        The minimum slew rate required on the Si533x power supplies is 0.5V/ns.

      • CCA

        Silicon_Labs | 12/347/2012 | 11:45 PM


        What is the clear channel assessment (CCA) and its use?



        You can output CCA to any of the GPIOs (see GPIO_PIN_CFG) to signal whether RSSI hits a pre-defined threshold (MODEM_RSSI_THRESH), or not. It is a very useful feature of the chip when you need to make sure that the given frequency channel is clear before actually transmitting; or maybe, if your receiver has to periodically need to wake up to check whether there is TX (in this case you may also want to check the 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). It is also possible to generate an interrupt if CCA goes high.

      • CRC calculation

        Silicon_Labs | 12/347/2012 | 11:43 PM


        How does the Si446x calculate the CRC?  Is there a built-in HW CRC engine? Is it more power efficient than having my host MCU doing it?



        The CRC is calculated on bits as they go into or out of the modem. Probably it is more power efficient to have our radio IC calculate the CRC as it is done real time.

      • Using GPIOs

        Silicon_Labs | 12/347/2012 | 11:41 PM


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



        It depends on your application. You may need to consider configuring a GPIO to CCA (i.e. clear channel assessment which indicates hitting the RSSI threshold), RX/TX State, RX FIFO Almost Full, TX FIFO Almost Empty, etc. Also, POR at GPIO1 may be useful for more efficient power up (at-room temperature the POR typically takes ~900us-1ms, but if you use a timer you need to go with the absolute maximum, 5ms. Polling GPIO1 is more efficient).

      • Tx completed

        Silicon_Labs | 12/347/2012 | 11:39 PM


        Is there a way to determine if the last packet transmitted was successful, or that the unit entered Tx mode and completed the transmission?



        Yes, nIRQ may be configured to indicate that a packet is received (see GET_INT_STATUS: PACKET_RX_PEND).