Farhan, Joel, all,
Sorry for the long post - but if you have an interest in this topic, please do read. IF the issue is in the Si5351A firmware configuration (not a hardware matter of more smoothing capacitors etc.) then this is worth reading.
First Farhan: you wrote: "The clicks are actually caused by the the time the PLL takes to resettle to a new frequency. It might make sense to disable the output before making the frequency change, wait for a few milliseconds and then enable it again." - this CANNOT be the case, the reason is that in your code you are using a constant PLL value of 900MHz:
si5351.set_freq((bfo_freq + f) * 100ULL, SI5351_PLL_FIXED, SI5351_CLK2);
SI5351_PLL_FIXED is set to 900MHz in the Etherkit library header file (I am looking at his version 1.1.1 as directed). So Farhan, since the PLL in the Si5351A is set permanently to 900MHz, there is no such thing as the PLL taking time to resettle to a new frequency. The PLL doesn't change - all you are changing is the fractional multisynth divider configuration.?
Joel you wrote "If the clicks while tuning issue is software related, why are some of us not having them and others are and we are all running the same sketch?" and that is a good point. But, there is the possibility that the "clicks" being bothersome or not, are somewhat subjective. Some people might have lower background noise than others. So in some cases with high background noise, that could be hiding the clicks. It may just be a hardware problem, I agree. But we shouldn't discount the possibility that it could be a software problem also. So look at both the hardware and the software.?
About hardware: At the moment the frequency is updated, remember that the display is also being updated. There is therefore a burst of activity on the signal lines from the processor to the LCD module. It is quite possible that this digital activity is being picked up by the sensitive receiver and is what causes the click. The solution to this could be more supply decoupling and perhaps, some shielding around the Raduino. I'd start with looking at supply filtering. More capacitors in parallel across the supply! Maybe some old toroidal inductor out of an old power supply, in series with the supply to the Raduino!?
About software: This was my original question - and the reason for this is that it is very well possible to create an audible click in software also. The QRP Labs VFO kit had this issue, the click was generated by the way I was configuring the Si5351A. It was actually a bug. I fixed it in the current firmware version s1.02c. There is a register in the Si5351A which is used to "reset" the PLL in the Si5351A. When the PLL needs to be reset, and when it does not, is of course not documented (SiLabs documentation is rather poor). But what is sure, is that you do not need to inflict a PLL reset on the situation for small tuning changes, and if you do, you will generate a discontinuity in the output which will show up as a CLICK in the receiver audio. Therefore I wanted to check that the Raduino code does NOT do a PLL reset every time the frequency is changed. Now I see that it fixes the PLL, so there is no PLL reset, and this cannot be the issue.?
By the way, switching off an Si5351A output for a small interval while the PLL settles generates an even worse click :-O ? Not that it is relevant in this case, because here you are fixing the PLL anyway.
So now I read the Etherkit Si5351A library again and am reminded how much I disliked it the first time I looked at it ;-) ?It is derived originally from the Linux Si5351A driver. In my opinion it is over-complex and it is inefficient. The use of 64-bit arithmetic seriously bloats up the code size, even worse than using floating point. I did not reply on earlier threads where people were suggesting bigger processors etc., because the 2K RAM and 32K Program space in the ATmega328 is not enough. I did not agree though. You can accomplish a huge amount in 32K program and 2K RAM. Look for example at my Ultimate3S TX kit:??- here I use the same ATmega328. This TX has a rich array of features. It is standalone (no PC connection). It encodes on-chip a lot of digital modes WSPR, JT9, JT65, ISCAT, PI4, Opera. As well as more traditional modes CW, QRSS modes, Hellshreiber. The next firmware version includes JT4 and RTTY as well. GPS calibration, info display, PTT delay, it controls the raised cosine key generation when using the 5W PA ?- all that has no problem with the 2K RAM. I do have to code very efficiently to make it fit in 32K program space. 64-bit arithmetic wouldn't work! So I'm not a fan of that library - and it is over-complex which leads to blind use of it without an understanding of what is actually going on. ?
Anyway back on-topic...
Using a fixed 900MHz PLL frequency means that you are using fractional division to obtain the desired output frequency. The Si5351A Datasheet recommends even INTEGER divisors in order to obtain best jitter performance. If you fix the PLL you are not using an integer divider, you are using a fractional divider. It will have more jitter. Or in other words, more phase noise. Whether or not this produces a noticeable degradation of BITX40 performance I don't know. This is the reason why in my VFO code I use even integer division. I fix the Multisynth divider at a suitable even integer, and vary the PLL. It is the opposite way around to what is being done in the Raduino. In the Raduino you are fixing the PLL and varying the division (fractionally). In my VFO I fix the division (to even integer) and vary the PLL.?
The Etherkit library is also doing some algorithm to choose the fraction numerator and denominator. This is repeated for each new frequency which is set. It could come up with radically different numerator and denominator, when the frequency is changed. I think that there is a possibility that changing this parameters creates a significant discontinuity in the Si5351A output, which is perhaps enough to cause the click.?
My suggestion, is to try it the other way around as I do. Vary the Si5351A PLL and fix the Multisynth division ratio. Use an even integer as this will result in best performance (lowest jitter), both intuitively and according to the datasheet. You might think that the PLL takes time to settle and that this will cause a problem. In reality I think that this is not the case. For the relatively small frequency changes that we are talking about, the PLL will recognise the difference between the current Voltage Controlled Oscillator (VCO) output and the desired new frequency as an error, which it will correct as part of its usual control loop. I think intuitively, that the VCO probably "slides" the frequency to the new value. Much like tuning an analogue VFO, though in a very fast sudden step. But I think it is a fast slide to the new frequency, NOT a discontinuity - since you are leaving the divisor alone. To my mind, this reasoning is logical and it is the best way to ensure no sudden changes which could cause a loud "click".?
People have reported that there is now no click when using the QRP Labs VFO to drive the QRP Labs Receiver module. Of course there is always some barely noticeable effect because fundamentally you are applying a sudden frequency shift, and that does produce a set of audio harmonics, as any sudden change does - by fourier transform (like the leading edge of a squarewave). You can't beat the physics. But there is no loud audible click due to an actual discontinuity.?
All this is about the software. As others have mentioned - if it is a hardware issue caused by the digital activity radiating, probably by the supply lines, and being picked up my the reciever - then more filtering etc is called for. I just mention all this software stuff in case it is useful, and someone who is modifying Raduino firmware might want to try it out.?
73 Hans G0UPL
http://qrp-labs.com
