I sort of fixed the problem.

First I found my offset (-150Hz). That means for a signal of 7.125MHz I had to adjust at 7.12515MHz for zero beat.

Then load the sketch into Arduino IDE and look for the BFO frequency (2 instances) and substract 150 Hz from the value, so my sketch now reads:

#define INIT_BFO_FREQ (1199785L)

unsigned long baseTune = ?7100000L;

unsigned long bfo_freq = 11997850L;

Compile and upload and everything works fine, no calibration required.

I have used KA7OEI's sketch to get the extra digit of resolution and avoid the flickering of the last digit.

--
Ion

VA3NOI

Hi all,

I have redrawn VU2ESE AGC hand sketch schematic.

73

Gian

I7SWX

The PA-09 crimps mentioned above are PRICELESS for these connectors. I tried a cheap pair of cheaper crimps and they were garbage. I highly suggest the pa-09. I picked mine up from adafruit a long with some 10k pots and ok looking knobs for cheap. Getting the crimps from adafruit were really fast because of where I live but I suspect that they'd ship anywhere in the lower 50 faster than anyone in china could get them to me at roughly the same price.

Here's my setup for crimping these connectors:

PA-09 crimps:

Dupont connectors:

2 pin housing:

3 pin housing:

开云体育

开云体育

I don't have a problem compiling or uploading any sketch (you just go in Library Manager and change the version of the library you want to use).

My problem is that, regardless of the message on the screen when releasing the A2 from GND the calibration is not taken. Once I release the A2 from GND, after doing the calibration, the frequency jumps to the frequency that is consistent with the new position of the tuning pot and when I go back to the signal I inject I have the same display offset as before (about 130 to 150 Hz).

I can live with that but puzzles me. First time I was able to calibrate correctly. Then I uploaded a different sketch. Calibration has been lost. Normal. Why it cannot calibrate one time, at least.

Is the calibration stored in some one time write only memory/register?

Thank you,
--
Ion

VA3NOI

Nope catered for in the loop.? Ignore me !

Rob

Ion,

The sketch is now wrong. Doh!

I just checked the library details again.? They have changed the way calibration is done, it now has a one time set?? " si5351.set_correction(value) ; "? Looking at the sketch now.

Your problem about going back is that the new library v2 persists in your Arduino/libraries and needs the SI5351 Library folder deleting from there and then add the old library again in the old sketch.

Rob G4NQX

During the first setup I have calibrated the frequency readout.

The behavior was as described. Connect A2 to GND - message on screen "Calibrate".

Keep holding A2 to GND rotate the tuning pot for zero beat (using a signal generator).

Release A2 from GND - message on screen "Calibrated"

All working fine after that.

Then I uploaded the sketch that compiles with the new SI5351 libraries.

Calibration has been lost, so I went again through the procedure.

Did not work. Reverted bavk to old, original, sketch and, again, no luck. Cannot calibrate anymore.

When connecting A2 to GND the message is same as if you turn on the power with A2 connected to GND.

You get a tone and you can calibrate for zero beat on that. It is saving something, or at least that is the message, but you do not get the "Calibrated" message anymore and the displayed frequency has the same offset as before.

I can live with this (only 100 Hz), but I would like to understand what happened.

Thank you,
--
Ion

VA3NOI

Following possibilities are to be considered.

We can divert? the back-lit circuit of LCD to unregulated voltage with higher series resistor.

The datasheet for7805 indicates around 3V . Now we have 7 or 8V and the load current? might be around 1 amp.We can mount? it on a heat sink.
Thus we can also have a input 12 or 13.8V through a 5 ohm 5 watt resistor? and it helps reduce the input/ output differential of the regulator.

regards

?sarma

?vu3zmv

So, last night I did some meaurements.

Room temperature at 18 °C. LM7805 goes as high as 52°C with 13.8V at power feed.

Temperature drops to 49°C when at 12.8 V (that is the votage of a fully charged lead acid battery)

Temperatue rise of 34°C. If you will enclose the board and ambient temperature is summer hot you can expect temperature of the case to get close to 100. A heat sink will be required.
--
Ion

VA3NOI

do this,

disconnect the power and plug in the nano with a usb cable. the raduino should still light up. now try programing it.

?I already did this. Doesn't change anything.

Do you think it is possible to buy just the pcb with the nano on it? Don't need a 2nd display. If yes, what would be the difference in the price?

I found this helps when fault tracing.

Hello Don,

Does your kit look like this

It's known as the Hendricks BitX20a kit.??

This is the one I have and modified it to work on 40m.? It's a great kit but it is very very touchy about the bandpass filter caps and toroid turns and the mixer toroid windings.

Also make sure they are well scraped of varnish. Just touching around can yield results.

I think the guys who designed the kit are on this group.

I have lots of pictures, files etc should they be of any use to you.? Including a larger circuit diagram roughly divided up into the working sections.

Rob G4NQX

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

The version I placed in the files section is the current Raduino loaded version, but just minor text changes to suit the new si5351 library.?

I'm not aware of any other 'official' version. The official version also has some extra code for CW and twin VFO's but it is commented out, so not used.

Folks on here have modded the code to suit themselves, i.e. S meter, voltmeter etc. that's the experimentation part of the build :-)

Rob G4NQX