High End Frequency Setting Errors v2.0.0

[va7ta]

Greetings,
I have encountered a couple of issues which I think may be bugs in the library. I have gone through the library update procedure with the library manager and it indicates I am now using version 2.0.0.

1. Frequency setting accuracy is lost with at least some high end frequency settings.

• With the limited tests I performed I did not noticed any frequency setting errors when all three output frequencies were set to below vaguely 66 MHz. However if even one of the output frequencies was set to frequencies above vaguely 100 MHz then in most cases all three frequencies appeared to become skewed. I decided the most concise way to describe this issue is by providing a specific, repeatable example which is given below.

• I don't think these issues are caused by my control program as I also send the frequency data sent to the Si5351 to the Arduino serial monitor. The data appears correct on the monitor. It is fairly certain that the data is OK as it is known in one case to work fine after reset but then fail in subsequent attempts following a higher frequency setting failure. However as I am using an ESP8266 Arduino port these issues should be confirmed by replication of the errors using an AVR controller.

• Specific Example:

• an attempt to set port 0 to 140 MHz; port 1 to 105 MHz; port 2 to 95 MHz results in output frequencies of approximately 133.33 MHz, 100 MHz & 90.47 MHz respectively.

• After attempting the 140/105/95 MHz failure setting and prior to a re-initialization from a reset a subsequent attempt to set the frequencies to 66, 45 and 29 MHz also failed with output frequencies of approximately 62.86, 42.86 and 27.62 MHz respectively. However after reset re-initialization the 66/45/29 MHz output frequency settings all appeared to work OK. This suggests once a failure occurs the erroneous behavior seems to stick and erroneously influence all subsequent frequency settings until re-initialization.

2. The library appears to ignore frequency requests over 150 MHz. The Si5351 is specified for a maximum of 200 MHz. I wonder if there is a reason for this maximum frequency limitation?

VA7TA

[la3pna]

@va7ta Are you sure you are using the last version of the library? It was pushed during this weekend, and solves the 1. problem you are having, as far as both @NT7S and my self have managed to test. If this issue is with the last version of the library, it would be interesting to know.
Observe that this library update is a breaking change, so you need to read the documentation and do a couple small changes.

As for 2: The automatic frequency algorithm tends to make a lot of spurs above approx. 100MHz, and it gets amplified above 150MHz. That said, you can use the Si5351 to 225MHz by setting the PLL to 4 times your wanted frequency. The 225.000000MHz is a hard stop in the Si5351.

73 de Thomas LA3PNA.

[NT7S]

Thanks for the bug report. I checked very similar scenarios to avoid this type of behavior, so I'm a bit surprised to see this one come up. I will try to replicate this behavior and report back. Better yet, if you could give me your exact sketch to load, that would be great.

Regarding issue 2, there is a reason for the way the library behaves, which I discuss a bit here: https://github.com/etherkit/Si5351Arduino#setting-the-output-frequency

The reason is that when you want an output frequency >150 MHz, the multisynth must be set to be an integer divide-by-4 only. Since I have all of the multisynths from 0 to 5 on the same PLL, it's kind of tough to balance how to optimize the PLL and MS params for all of the clocks. I'll look further into a scheme to make it all work "automagically" but for now you can set frequencies >150 MHz using the set_freq_manual() method with a PLL that is 4x the desired output frequency.

[NT7S]

Was able to confirm the bug. I think I have a grasp on what's going on; an unnecessary attempt to re-set the PLL (which appears to be setting to the wrong frequency). Will try some more testing and then push a branch for you to test.

[va7ta]

Thanks for the prompt responses and glad to hear it could be replicated!
Although I am quite confident I am using version 2.0.0 I am guilty of not reading the new ReadMe file. I need to learn how to adopt the manual setting mode for setting the higher frequencies. I have read the Si5351 spec sheet in the past but need to refresh and relate it to the new version 2 library. For my current plan I would need two independent agile outputs for the 86 +/- 1 MHz and 88 - 180 MHz range. I think I should be able to do that by using separate PLLs.

[NT7S]

Here is an update the removes to the code that sets the PLL in the set_freq() method. Give it a try:
https://github.com/etherkit/Si5351Arduino/tree/v2.0.1

[NT7S]

@va7ta Yes, that scheme would be easy to implement on the 3-output Si5351 using this library. Let's say CLK2 is your 88-180 MHz output. Assign that to PLLB and then use the set_freq_manual() method like so:
set_freq_manual(freq, freq * 4, SI5351_CLK2)

You can then use CLK0 or CLK1 as the independent agile output with the set_freq() method.

[va7ta]

Great stuff! Based on a cursory view of the spectrum my first impressions of your fix are good. The 140/105/95 MHz combo group now appears to set OK and when I toggle with the 66/45/29 MHz combo it appears to switch back and forth between the two group settings properly without a need to re-initialize. I need to evaluate in more detail but my first impressions are sure good!

Many thanks!!!
VA7TA

[NT7S]

@va7ta Might want to look at the v2.0.2 branch. I think I can now set the max frequency in the set_freq() method to 225 MHz. So you shouldn't have to mess with set_freq_manual() in your use case. Give it a try and let me know how it works for you:
https://github.com/etherkit/Si5351Arduino/tree/v2.0.2

[va7ta]

Hi Jason,
I found the maximum frequency is still limited to 150 MHz, higher frequency requests are rounded down to 150MHz. The library files I am compiling are from version 2.0.2 library files from "Si5351Arduino-2.0.2.zip" which are dated 201612181241.

I wonder if I have the wrong files?

[va7ta]

Further to my last I noticed the following in the cpp file. I wonder if the wrong files accidentally got posted on github?

	// Upper bounds check
	// We will only allow a maximum output frequency of 150 MHz using this
	// method. For >=150 MHz, you'll have to manually set the paramters
	//if(freq >= SI5351_MULTISYNTH_DIVBY4_FREQ * SI5351_FREQ_MULT)
	if(freq >= SI5351_MULTISYNTH_MAX_FREQ * SI5351_FREQ_MULT)
	{
		//freq = SI5351_MULTISYNTH_DIVBY4_FREQ * SI5351_FREQ_MULT - 1;
		freq = SI5351_MULTISYNTH_MAX_FREQ * SI5351_FREQ_MULT - 1;
	}

[NT7S]

No, that's the correct .cpp file. In the .h file, SI5351_MULTISYNTH_MAX_FREQ should be defined at 225 MHz. From what I can see here, I posted the version that gives me output up to 225 MHz. Double-checked the v2.0.2 branch against my local copy. Perhaps your Arduino installation is still using an older version of the library?

[va7ta]

OK, I will look into this further but I did check that the Arduino compiler was using the files from the v2.0.2 zip file. I checked by changing the file names of both the h and cpp files one at a time and confirmed that it would not compile in both cases. I just confirmed the SI5351_MULTISYNTH_MAX_FREQ constant in the H file Arduino is using is in fact defined as 225 MHz. It is puzzling, I will give it another try.

[NT7S]

OK, I'll try it on a different PC as well, that's definitely odd. I certainly can't rule out a mistake on my end yet. :)

[va7ta]

The problem was here. I am still not sure how it happened. Finally I changed the h file extensions on to h.rem for all instances of si5351.h on the system except the desired v2.0.2. Then re-compiled, uploaded and it worked. I had double checked that it was getting the correct file last night but obviously, somehow it never got uploaded to the CPU firmware. Sorry for the churn!

[NT7S]

No worries! The way Arduino handles libraries can be a bit goofy at times. Hope that works well for you.

[va7ta]

First impression is that this should work fine for my application. I need to take a closer look later but the setting of combo 66/80/225 seems to work fine. Not that I have a need for this but just so you know an attempt to set 66/120/225 seemed to be blocked. I wonder if this is a limitation of the Si5351 silicon?

A minor thing, just to keep the specified max freq number nice and round (and if the 5351 will tolerate it) you might wish to change the max freq constant to 225000001. It accepts 224,999,999 Hz OK but blocks 225,000,000.

I hope to spend some more time with it later today.

Looking great, many thanks for the update!

[NT7S]

Yes, actually according to the limitations of the silicon, you can only set one multisynth on the same PLL to a frequency >112.5 MHz (unless both are the same frequency). So the code would not allow you to set CLK2 to 225 MHz once CLK1 is set to 120 MHz.

I'll check on the off-by-one thing. I believe it put that in due to some instabilities that I encountered earlier, but it could been related to the other bug that was fixed, so I'll check it.

Thanks for the feedback!

[NT7S]

I pushed another commit to the v2.0.2 branch with the off-by-one removed, since it seems to work ok here from what I can tell (however, my scope is only 100 MHz BW, so it's probably not the best source of info in this case).

[va7ta]

I had a feeling I was probably exceeding the Si5351 design limits and now that you mention it I remember reading about that 112.5 MHz limitation. I am using a PC controlled spectrum analyzer that goes up to about 4 GHz thus it is easy for me to check. I just got back home and will take another look once the dust settles. Would you like some screen captures?

[va7ta]

I have run across one situation where the Si5351 appears to crash. The combination of 66/80/=>112.6 MHz appears to work OK but if I try to set clock 2 to within the range of roughly 110.5 to 112.5 MHz then the 5351 appears to switch into an unstable mode. The clock 2 output spectrum becomes filled with spurious junk. The clocks 0 & 1 outputs appear to remain normal.

By the way I also had a 225 MHz maximum limit set in my code which limited the setting to <225,000,000 MHz.

[va7ta]

With my system the 112 +/- 0.5 MHz range seems to be broken using v2.0.2 code. I don't remember trying frequencies within this range when testing the earlier versions. Could be a problem with my ESP8266 I2C data but I think unlikely as it seems to work OK for other frequencies.

With the new version 2 autotuning is it OK to assign the CLK outputs to different PLLs using the "set.ms.source" method? Would that permit one to have more than one output above 112.5 MHz?

[NT7S]

I've seen that kind of behavior before, and it's a tricky problem. I think maybe it's a silicon thing, but I'll go over my code and see if perhaps I'm still doing something wrong. I may just have to move that constant down a bit in frequency in my code.

Yes, you should be able to assign another output to PLLB and then have the set_freq() method handle it correctly now, although admittedly that's one thing I didn't explicitly test yet.

[NT7S]

I changed the define SI5351_MULTISYNTH_SHARE_MAX from 112.5 MHz to 110 MHz and that range of frequencies seem to be stable under this new division point. That change has been pushed so you can give it a try @va7ta.

[va7ta]

Seasons Greetings!

• I found with my Si5351 board that the 110 MHz setting is not stable. It seems it will set to 110 MHz initially but if the frequency is shifted to another setting and then set back to 110 MHz sometimes there will be no output or at other times it appears to loose lock and the spectrum fills with junk.

• I do not know if this is significant but I noticed that LOS in the status message seems to always be set to 1 which doesn't match the info in the readme. I don't believe this is related to the instability problem because it seems to always be the same.
  SYS_INIT: 0 LOL_A: 0 LOL_B: 0 LOS: 1 REVID: 1

• I tried setting Clock 0 to PLLA and Clocks 1 & 2 to PLLB using three set_ms_source commands. With clock 2 set above 110 MHz the Clock 0 setting appeared blocked to the 110 MHz maximum limitation as if it were still being driven by the same PLL as 1 & 2. I has the impression the library might not be recognizing that Clock 0 is being driven from a different PLL and is thus setting the max limit.

Hope this info helps!

[va7ta]

Hi Jason,

I imagine you may very well have already considered this but for what it is worth I wonder about the possible feasibility of shifting the division point up or down to avoid instability zones within the frequency spectrum? I imagine this would result in PLL lock up delays for each shift but I think that would be tolerable for most applications. Just a thought for whatever it might be worth.

[NT7S]

@va7ta

Regarding your 110 MHz setting, I was able to recreate problem here as well. I tried sliding the cutoff frequency down to 100 MHz and I do not see the same behavior when setting a CLK to 100 MHz, changing it to another frequency, and then back to 100 MHz. So perhaps there is a silicon limitation there, or perhaps there is a subtle bug elsewhere in the library.

I have not been able to replicate your issue with the LOS flag here, but I have seen some strangeness with those registers in the past, so I don't doubt there is an issue somewhere. Going to back-burner that problem until I can get a better grasp of it.

Regarding your comments about changing the PLL assignments, I added some code into set_freq() so that the algorithm only looks at CLK outputs sharing the same PLL assignment at the time.

Latest code has been pushed to v2.0.2 branch:
https://github.com/etherkit/Si5351Arduino/tree/v2.0.2

Thanks,
Jason

[va7ta]

Hi Jason,

     I have now played a little with your latest version and I have not found any instabilities. I also assigned CLK2 to PLLB and it now works independently. At the moment I have CLK0 @ 225 MHz, CLK1 @ 100 MHz and CLK2@200 MHz. Looking good!

      I did notice one anomaly for CLK0 and CLK1. The combination 25/100 MHz sets up OK from reset. Switching to 225/100 MHz also works OK. But when switching back to 25/100 MHz the CLK0 output fails.

It recovers with a switch to 25/110 MHz. After recovery switching back to 25/100 MHz still works.

       In general I think a huge improvement-congrats!

Hope this info helps!

[va7ta]

---will re post as line wrap playing tricks on me

I have now played a little with your latest version and I have not found any instabilities.

I also assigned CLK2 to PLLB and it now works independently.

At the moment I have CLK0 @ 225 MHz, CLK1 @ 100 MHz and CLK2@200 MHz. Looking good!

I did notice one anomaly for CLK0 and CLK1. The combination 25/100 MHz sets up OK from reset.
Switching to 225/100 MHz also works OK. But when switching back to 25/100 MHz the
CLK0 output fails. It recovers with a switch to 25/110 MHz. After recovery switching back
to 25/100 MHz still works.

In general I think a huge improvement-congrats!

Hope this info helps!

[NT7S]

Thank you, I'll work on that glitch. Hopefully I'll have this nailed down soon enough.

[NT7S]

@va7ta A regression got me. Try the latest version of the v2.0.2 code:
https://github.com/etherkit/Si5351Arduino/tree/v2.0.2

If that works, I'm going to merge.

[va7ta]

Hi Jason,

Just keeps getting better! I think I found what is probably an easy bug to fix.

I noticed that there seems to be variable(s) that are not being cleared after an out-of-range setting attempt. For example if you set Clk0/Clk1 to 60/145, then 160/145 (out of range intentionally), then 160/45 clk0 will then fail to change I believe until power reset. Hopefully you will be able to replicate this. I am guessing that this is probably an easy bug to fix.

Test sequence as follows:

step Clk0, MHz Clk1, MHz Comment
Set/Result Set/Result
1 60/60 145/145 OK
2 160/60 145/145 No Change OK
3 160/60 45/45 Clk0 failed to change
4 160/60 45/45 Clk0 failed to change - 2nd try
5 160/60 45/45 Clk0 failed to change - 3rd try
6 50/50 45/45 OK
7 150/ 50 45/45 Clk0 failed to change
reset power
8 150/50 45/45 OK

Hope this helps!
Tom, VA7TA

[NT7S]

Thanks again for all of the excellent testing you have been providing. It really helps to make for a much stronger library.

Please try the latest version of the v2.0.2 branch and let me know if that corrects the issue you've been seeing.

[va7ta]

Hi Jason,

That sequence seems to work fine now. I didn't spot any other glitches. I think this version is much improved thus certainly worthy of making public. IMHO would be a shame to hold it back.

Congrats!

[NT7S]

Excellent. I've made one final cleanup and push to the code branch, if you wouldn't mind running it through your test battery just to be sure I didn't accidentally break something before I merge the dev branch. It can be painful to try to revoke a broken revision from the Arduino library manager. Thank you!

[va7ta]

Hi Jason, OK I will give it another spin today when I get a chance. Oh by the way I sent you a private email about another matter via your gmail address. I wonder if that is the correct address to use and if you check it regularly? 73 Tom

…

On 2017-02-28 08:42, Jason Milldrum wrote: Excellent. I've made one final cleanup and push to the code branch, if you wouldn't mind running it through your test battery just to be sure I didn't accidentally break something before I merge the dev branch. It can be painful to try to revoke a broken revision from the Arduino library manager. Thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFKe4p4Ld33Z6UBLaMV3VfdMpj-HwG_Rks5rhE5cgaJpZM4LExfw>.

[NT7S]

Yes, I received the message and will be replying soon

[va7ta]

Hi Jason,

   I never found anything broken but I found a subtle glitch that I may have missed before. It happens when I try to change both Clk0 and Clk1 in a single command. It only appears to happen when initially Clk0 is set < 100 MHz and Clk1 is set > 100 MHz. If Clk0 is initially set higher than Clk2 it doesn't happen. This one was tough to get a handle on and took me 30 test cycles until I think I finally understand when it happens. I hope you can replicate this.

     I don't believe it happens as long as only one frequency is changed at at time which I guess means that if one of the frequencies is >100 MHz it must be lowered first. It may be something that could be put into the spec. Strange that it only seems to happen when Clk0<Clk1 to start with.

examples:
With initial MHz setting clk0=60, clk1=145; then clk0=160, clk1=45; then clk1 is set OK but clk 0 is not set to 160 first attempt, but sets OK on second attempt.

   With initial MHz setting clk0=160, clk1=45; then clk0=45, clk1=145; OK first attempt.

   I wish this editor didn't destroy the column formatting. I tried to upload the text file but it failed for unknown reason.

   I am not sure if this is one that is worth chasing down or not if it is a difficult fix. There are many other improvements made that are much more significant.

    Sorry for the churn but this was a difficult one to spot.

Tom

step Clk0, MHz clk1, MHz Comment
Set Result Set Result
1 60 60 145 145 OK
2 160 60 145 145 No Change OK
3 160 60 45 45 Clk0 did not change Clk1 OK
4 160 160 45 45 OK - 2nd try
5 160 160 145 45 No Change OK
6 60 60 145 145 OK
7 160 60 145 145 No Change OK
8 160 60 45 45 Clk0 did not change Clk1 OK
9 160 160 45 45 OK - 2nd try
10 145 145 60 60 OK
11 145 145 160 60 No Change OK
12 45 45 160 160 OK - 1st try both clks
13 145 145 60 60 OK
14 45 45 160 160 OK - 1st try both clks
15 60 60 145 145 OK
16 60 60 45 45 OK
17 160 160 45 45 OK
18 160 160 145 45 No Change OK
19 160 160 45 45 OK
20 160 160 145 45 No Change OK
21 160 160 45 45 OK
22 60 60 145 145 OK
23 160 60 145 145 No Change OK
24 160 60 45 45 Clk0 did not change Clk1 OK
24 160 160 45 45 OK - 2nd try
25 60 60 145 145 OK
26 160 60 45 45 Clk0 did not change Clk1 OK
27 160 160 45 45 OK - 2nd try
28 60 60 145 145 OK
29 160 60 45 45 Clk0 did not change Clk1 OK
30 160 160 45 45 Clk0 did not change Clk1 OK
31 60 60 145 145 OK

[va7ta]

I finally got file upload working - very simple - don't know why it didn't work the first time.
Should be properly formatted in EditPad.

20170228_Lib5351_Tests.txt

[NT7S]

@va7ta Many thanks for the detailed testing and report! Could I bother you to place that in a separate new issue? I'd like to work on it, but not right now as I don't think the benefit of chasing it down right now would be worth it when I have more pressing issues at hand. But I would like to get to it at some point.