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