Si5351A Investigations Part 8

In looking through the analytics here on the blog, I noticed a search term that has been regularly coming up near the top: Si5351 crosstalk. Realizing that I haven’t yet presented data on this, it seemed like a good time to knock this one out, since it isn’t that difficult of a measurement to make.

It appeared to be a wise idea to choose output frequencies that were non-harmonically related, so I decided on the following outputs:

  • CLK0: 22.444555 MHz
  • CLK1: 10.140123 MHz
  • CLK2: 57.456789 MHz

Each output was set to the maximum 8 mA current and each one was locked to PLLA, which was set at 900 MHz.

The measurement procedure was simple. I connected the spectrum analyzer to each output sequentially. The unused outputs were terminated in 50 Ω. For each measurement, I used a delta marker to measure the difference in amplitude between the desired signal from that output and the frequencies of the other two outputs.

Without further ado, allow me to present the spectrum analyzer plots.

Output port: CLK0 Crosstalk signal: CLK1
Output port: CLK0
Crosstalk signal: CLK1
Output port: CLK0 Crosstalk signal: CLK2
Output port: CLK0
Crosstalk signal: CLK2
Output port: CLK1 Crosstalk signal: CLK0
Output port: CLK1
Crosstalk signal: CLK0
Output port: CLK1 Crosstalk signal: CLK2
Output port: CLK1
Crosstalk signal: CLK2
Output port: CLK2 Crosstalk signal: CLK0
Output port: CLK2
Crosstalk signal: CLK0
Output port: CLK2 Crosstalk signal: CLK1
Output port: CLK2
Crosstalk signal: CLK1

I thought that perhaps these measurements would be a best-case scenario, and that leaving the unused output ports unterminated might produce even worse performance, but it turns out I was wrong. Below are the same measurements, but with an open circuit on the unused ports.

Output port: CLK0 Crosstalk signal: CLK1
Output port: CLK0
Crosstalk signal: CLK1
Output port: CLK0 Crosstalk signal: CLK2
Output port: CLK0
Crosstalk signal: CLK2
Output port: CLK2 Crosstalk signal: CLK0
Output port: CLK2
Crosstalk signal: CLK0
Output port: CLK1 Crosstalk signal: CLK2
Output port: CLK1
Crosstalk signal: CLK2
Output port: CLK2 Crosstalk signal: CLK0
Output port: CLK2
Crosstalk signal: CLK0
Output port: CLK2 Crosstalk signal: CLK1
Output port: CLK2
Crosstalk signal: CLK1

I’m not quite sure what to make of that. In practice, I haven’t seen any problems in my receivers so far that I can trace back to crosstalk from adjacent channels. Of course, this probably won’t do in a higher-performing receiver, but if you wanted to use the Si5351 in such a receiver perhaps you could find a way to put two or more on an I2C bus at the same time, then use only one output from each. My advice would be to turn off any channels you are not currently using, just to keep the other outputs clean.

I have no doubt that this data will be more ammunition for those who are convinced that the Si5351 is a terrible LO. I stand where I always have: this is an excellent IC for the price and you are hard pressed to find such capability and stability for such a low price anywhere else. If, knowing its limitations, the Si5351 meets your needs, then excellent! If not, that’s fine too. Neither I, nor anyone else I have heard, has suggested that the Si5351 is a panacea or a substitute for a better oscillator such as the Si570. It’s another tool to be put into our toolbox in the quest to stay relevant with the march of technology.

Quite a bit of work has been done in quantifying the performance of the Si5351 for amateur radio use, within the limitations of our modest home labs. Something that you don’t see done with a lot of other new components these days. Have I made mistakes or overlooked some things? Almost certainly. I’m still learning how to apply a strict measurement discipline over all of my serious building activities, so this is a learning process for me as well. If you have some constructive criticism of any of my measurements or feel that I have neglected things, I absolutely welcome an email or comment on the blog. Let’s try to hold ourselves to high standards as home experimenters without being unduly negative, as many of us continue in the journey of RF experimentation.

17 thoughts on “Si5351A Investigations Part 8”

  1. This was a very important finding, many thanks! Maybe the common output stage is causing the crosstalk: if the unused outputs are open, they do not load the output driver. Two ideas came to my mind. Could we use the outputs as high-impedance ones? Would it be possible to improve VDDO bypassing, do you see the output signal(s) there?

  2. Hi Jason,

    I found a strange behavior when tuning the Si5351 above 118.4 MHz. Up from that frequency the ouput signal is verry noisy caused by strong jitter (I think). I found that it has to do with the Multisync deviders. When the devider is an integer, no problem but when its an fraction like 7.55 then the jitter started. Also no problem when it’s 7.5 (by example).
    I’m using a 25 MHz x-tal and set the PLLA fixed to 900 MHz. I found this problem with different software drivers for the Si5351.
    Did you regognized this problem and if so is there a solution for this jitter?

    73′
    Rob PA0RWE

  3. Hi Rob,

    I had some issues with those frequencies in my initial version of the library, which I suspect you may be using. I’ve been doing a lot of work on a new branch of code, with many bug fixes and new features. I tried setting a frequency of 144.123456 MHz with the latest version of the library and it don’t see any excessive jitter on my scope (which admittedly does not have a huge bandwidth). Try updating your local library with the version posted here:
    https://github.com/etherkit/Si5351Arduino/tree/jason

    Then try your test again to see if you still have the same issue.

    Thanks,
    Jason

  4. Hi Jason,

    Thanks for the updated library. It took some time because I had to port it to the PSoC development envirement but it’s working great now! When I used it the first time, I found that the set frequency must be multiplied by 100 for getting the right output frequency… But I’m happy that it’s working now.

    Thanks for your help!

    73
    Rob PA0RWE

  5. Hi Jason,

    Well this was a onetime happiness…
    After I switch off and switched it on again, the same jitter problem was back above 118 MHz….
    Until now I did not get the device jitter free running. It seems that if one of the registers has a wrong value, it stays wrong….
    I also found that on clk1 and clk2 there is a steady signal of 112.3892 MHz, even though it was not set.
    Well a lot of strange behavior which I can’t explain. Maybe you have a suggestion?

    73’
    Rob PA0RWE

  6. Well I found that everything is working fine when I set in the Set_freq not PLL_FIXED but 0ULL….
    So the problem is in the PLL fixed frequency setting.
    But by now, it’s working again and no jitter above 188MHz.

    Thanks!
    Rob
    PA0RWE

  7. Finally I found the cause of the problem…

    In fixed mode it’s not allowed to use a divider value less than 8. And that caused the problem. In the calculation of the divider value to get an output of 120 MHz the divider value is 900/120=7,5 (is = 960 MHz, which means at a X-tal frequency of 27 MHz (which I’m using): 27 x 36 = 972 MHz. At 25 MHz it should be 120 * 8 >= 960 MHz, which means 25 * 40 = 1000 MHz for the fixed VCO frequency.

    I tested above with a 27 MHz x-tal frequency and it was working OK. A nice clean signal on 120 MHz.

    If you changed the .H file for this new PLL_FIXED value don’t forget to change the PLL_VCO_MAX frequency as well!

    73
    Rob PA0RWE

  8. Sorry there was missing a part of my story… Try it again.

    In fixed mode it’s not allowed to use a divider value less than 8. And that caused the problem. In the calculation of the divider value to get an output of 120 MHz the divider value is 900/120=7,5 (is = 960 MHz, which means at a X-tal frequency of 27 MHz (which I’m using): 27 x 36 = 972 MHz. At 25 MHz it should be 120 * 8 >= 960 MHz, which means 25 * 40 = 1000 MHz for the fixed VCO frequency.

  9. The blog still leaves some text. Jason I hope you can skip the bad peaces…

    In the calculation of the divider value to get an output of 120 MHz the divider value is 900/120=7,5 (is smaller than 8).

    The solution is to increase the fixed value of the VCO to 120 * 8 >= 960 MHz, which means at a X-tal frequency of 27 MHz (which I’m using): 27 x 36 = 972 MHz. At 25 MHz it should be 120 * 8 >= 960 MHz, which means 25 * 40 = 1000 MHz for the fixed VCO frequency.

  10. OK Rob, I understand the confusion now.

    The PLL_FIXED value probably should be changed or removed, as it is only a suggestion. You can pick any PLL value between 600 and 900 MHz. So in your case, don’t use PLL_FIXED, use a lower PLL frequency such as 600 MHz. That way the code can use a divider of 6 or 7.

    I just checked this with the latest library, by setting a PLL frequency of 600 MHz and requesting a 155 MHz clock, which worked just fine.

    I’ll add some notes about this condition in the documentation. Thank you for bringing it to my attention!

    Jason

  11. Hi Jason,

    This discussion for me was an eye opener as well about how the Si5351 is realy working…
    Thanks!

    Rob

  13. I can’t find where you describe your hardware setup used for this experiment. Currently I am finding little evidence or crosstalk issues internal to the Si5351, but I am finding that the device is susceptible to intermodulation when there is crosstalk between the clock lines external to the Si5351. The intermodulation issue increases dramatically when higher Si5351 drive levels are used – at least in my test setup. But when external coupling between the clock lines is removed, product frequencies become undetectable – at least not detectable using the crude test methods I have at my disposal.

    So I am interested to learn if there might have been subtle avenues for external crosstalk in your test setup. Even a few pF between the clock lines seems to be significant. I am hoping that decoupling resistors in the clock transmission lines (as described in the Si5351 data sheet) will improve the intermodulation performance. Were such resistors used in your test setup?

Leave a Reply