Topics

TX clicking / woodpecker #qcx #mods

Kārlis Goba
 

Investigating the sidetone injection circuit (R59) and looking at scope traces, I found a remedy for the clicking in headphones at every dot and dah. It suffices to insert an extra 100n cap in series with R59. The reason is how the sidetone signal is formed in the microcontroller - the IO pin is normally in high-Z state, and during dit/dah emits 0/5V push-pull PWM square wave which gets filtered by the audio LPF chain to get a nice sinewave. The problem is that during high-Z the input at R29 is at ~2.5V DC, but at the start of PWM the voltage goes suddenly up or down depending on your sidetone volume setting. So there's a noticeable discontinuity which gives the clicking sound. Inserting a cap in series helps greatly.

While investigating the woodpecker sound (active if you have the S-meter enabled), I was looking for ways digital noise from the 5V rail could enter audio chain, and I noticed C6 is specced at only 100n. That's the bias feed point, and it should normally be low impedance. In other QSD implementations it's usually at several to ten microfarads. I soldered a 2.2u SMD cap in parallel to it, and my sensitivity went way up, and compared to that the woodpecker became way less prominent. Before I could rarely hear band noise with antenna attached, and now it's noticeably better.

--
Karlis YL3JG

Kārlis Goba
 

Some measurements: before mod the woodpecker with antenna disconnected would generate 300 mVpp clicks at the audio output (unloaded, full volume). After that it went down to 100 mVpp. Not perfect, it's still audible, but 10 dB down.

I rewired R35 from 5V rail to mid-supply (around 6-7 volts at C24), but it didn't help much in terms of click voltage. R35 is a potential noise entry point, but the gain at that point is just around 100. I think the noise enters somewhere earlier in the audio chain, or it's a combined effort of noise from various IO pins (R53, R59, I'm looking at you), and R50. The noise is generated by LCD update communication I believe, since it is very prominent with the S-meter enabled.

--
Karlis YL3JG

ajparent1/KB1GMX
 

I see no reason why R35 change of bias point should reduce clicks.

However if there is a bad solder (short) across a cap that would.

test if there is voltge at the wiper of 36 (colume control) there
should be NO DC voltage there.  IF there is then check
C21 and C22 for correct polarity or a short.

The test for the source is lift one end of R53, if the clicks stop its
from the sidetone path. note that takes away side tone but this
is a test., temporary.   If not try disconnecting one end of R54
and see it that helps. 

R50 should not cause clicks unless you have the worng value there
or wrong value at R49(or missing!).

Simple thing like a shorted or bad cap, Fet in wrongly inserted,
or wrong resistor in the wrong place can be a problem.

I've not notice a loud click on the QCX40 I have.

Allison

Kārlis Goba
 

Thanks Allison. I'm sorry I put two issues in one post, they are totally unrelated. The clicks refer to sidetone while TX/practice, and the woodpecker is something that you hear during RX.

First, the clicks.

I had checked DC voltage at the pot and Q7 as the first suspects, but they were ok. C21/C22 are ceramic 1u caps, no shorts.

The clicking is not just at the start of TX, but at every DIT/DAH as a sharp transition into it and out of it. So it makes a very unpleasant sound in the headphones when sending. So it's like shaped CW, but all the way around, shaped for maximum nastiness and splatter.
 
Perhaps I didn't explain very well. R59 does not change bias point as such. Inserting a 100n cap in series with it creates a lowpass filter that reduces the sharp transition from 2.5V pulled by IC6/IC7 output bias and high-Z SIDETONE/PB1 IO line into PWM mode generated by that pin. That PWM might have very low duty cycle (which it does for me, as I don't want to have loud sidetone).
 
You might not notice any clicking if your sidetone volume setting (Sidetone vol 4.9) is such that it would generate close to 50% PWM. Mine is set way lower, and it generates sharp, short pulses with low duty cycle, and low duty 5V PWM is essentially a combination of low DC (less than 2.5V) + our desired 700Hz sinewave + higher harmonics not relevant here as they get filtered out later in the chain. However, the sharp step transitions at every start/end of a dit/dah have a lot of energy all across the audio spectrum and its 600-800Hz component gets through the filter chain as well. 
 
See attached drawings that illustrate what I mean. Scope confirmed this. I also did a quick simulation (Spice is priceless) to arrive at this.

Second, the woodpecker.

That happens during RX. Turning off the S-meter eliminates it, turning S-meter on - woodpecker. Clicks with 10-20Hz rate in the audio, not too loud. Connecting antenna with enough noise floor "eliminates" the problem as you just don't hear it any more. Since it has a very obvious connection to the S-meter and since I'm thinking as a programmer would, I believe it would be LCD communication to update S-meter visually 10-20 times per second. So the noise is on the IO lines of the microcontroller and somehow enters the audio chain either via coupling capacitance between IO pins at the chip, coupled traces, or 5V supply rail. Since removal of the LCD itself does not cure the problem, EMI radiation is excluded. Since 5V is used to generate midsupply bias for the whole RX chain with >10000x gain (R1/R2/C6), I believe it's the first candidate where any noise would enter and get amplified.

--
Karlis YL3JG

Kārlis Goba
 

I went through your troubleshooting advice and I agree that there are multiple components that could cause the symptoms. I went through all of them. However I think you believe sidetone is injected via AUDIO2, or R53. That seems to be an ADC connection for alignment purposes only, and sidetone is injected via R59 as PWM signal on pin PB1 (which also happens to be internal timer PWM pin). Would be nice to have Hans confirm that. 

--
Karlis YL3JG

Kārlis Goba
 

I realised I should have mentioned I was using Semi QSK. So that excludes Q7 and related circuitry.

--
Karlis YL3JG

Hans Summers
 

Hello Karlis, Allison, all

I have now SOLVED the woodpecker problem. Completely. Via a firmware change only. 

The start of the story is actually Saturday, while I was at my QRP Labs stand at Veron Day of the Radio Amateur, the annual Dutch amateur radio convention in Zwolle, Netherlands. I was having a conversation with someone. Regrettably, and this someone, please accept my very sincere apologies - I met a hundred and one very interesting people during the day, and as usual on these occasions by the end of the day it was all a blur... so I cannot remember which of the radio amateurs I met, was talking to me about this. So therefore please can you identify yourself for the MANY THANKS which need to be heaped upon you, if you are reading this!

This person had noticed that the I2C SDA bus signal is shared with the LCD RS signal. The woodpecker noise is caused by the LCD updating the S-meter at frequent regular intervals (which we all know). It had been assumed that digital noise from the flurry of communication with the LCD is what causes the "clicks", which in quick succession we call a "woodpecker" sound (with apologies to real woodpeckers, who know what they really sound like when pecking wood). 

This person provided a theory that perhaps, since the processor is unashamedly using 5V signal levels, and the Si5351A is running at 3.3V, when the signal is high, the signal might be shunted to the 3.3V Supply of the Si5351A by internal ESD protection diode circuity inside the Si5351A. This could get onto the supply line of the Si5351A and find its way to the Si5351A output and through the audio chain. The thinking then was, that if I could change the firmware so that it did not operate the Si5351A SDA pin at +5V, but instead left it "Open-Collector" style when "high", pulled to 3.3V by R3, this could solve the problem. 

To test this I used my QCX-20, with audio output connected to my shack audio amp so I could turn the volume up loud in the pair of shack speakers. A dummy load connected to the input so that it's quiet. I could very clearly hear the "Woodpecker" when the S-meter is switched on. There is also an identical click whenever anything is written to the display (for example by the CW decoder), and when the frequency is changed (which updates the display). Since these clicks tend to be irregular, they are even less noticeable than the "woodpecker". 

All of these clicks tend to get drowned out by band noise in actual use; but as 20m and 17m have lower band noise, then if you are in an RF-quiet location, they could be audible. 

Then I cut the track from the Si5351A's SDA pin to the processor and replaced it with a switch - the QCX will not start up unless it has successful communication with the Si5351A. So once the QCX had started up, I flicked the switch to disconnect SDA... and sure enough, the woodpecker stopped. Next, I experimented with the theory of the 5V from the RS signal during LCD communication overloading the SDA pin, by using a diode so that the Si5351A SDA pin could only be pulled down by the RS pin. +5V could not feed into the RS pin. Result: FAIL! Still a "woodpecker" sound. So the theory seems not correct.

However, this led me to investigate other things, in the firmware. The RS pin is used to tell the LCD whether a command or a data byte is being written to the module (1 = Data, 0 = Command). I discovered that each byte which is written to the module, sets the RS signal according to whether it is a data or command byte. But it then just leaves the signal there, until the next byte is written and if needed, changes the RS signal level. 

Then I thought - what if I set the RS signal to what it needs to be, then clock the two 4-bit nibbles of the byte into the LCD module, then set the RS signal high again immediately... all over in less than a microsecond. Any disruptions which find their way into the Si5351A and the receiver signal path, will be of such a short duration that they will be well outside the audible passband of the receiver. Result: SUCCESS! The woodpecker stopped!

I tried "parking" the RS signal high (5V), and low (0V), and in both cases the woodpecker sound is eliminated. However, for unknown reasons, if I park it low, the clicks on frequency changes and decoded CW screen updates disappear also. With high parking, there are still clicks on frequency changes and CW decoder updates. Since it in any case feels more wholesome to park on 0V (considering the Si5351A theoretically doesn't prefer 5V), and it also eliminates all other clicks, I have left the RS signal parking at 0V. 

Conclusion: a 1-line firmware changes has completely eliminated all known clicks associated with display update ("Woodpecker" when the S-meter is on, frequency changes during during, and decoded CW text). 

I don't personally use the CW decoder or the S-meter, but I feel the improvement to tuning is very significant. With the dummy load on, the QCX gain control on maximum, and the shack audio amp on maximum, there is now simply no click at all when turning the rotary encoder. Only the mechanical click of the rotary encoder's detent mechanism :-D   My QCX happened to be tuned to 14020 and there seemed to be some kind of DX pileup going on there... some of the stronger signals were audible even with just the dummy load (no antenna connection). 

Many thanks to whoever was discussing this with me on Saturday and has prompted this investigation and solution with their discovery that the path the woodpecker noise enters the receiver audio, is the Si5351A SDA bus signal! 

I shall prepare a firmware release containing this improvement. 

73 Hans G0UPL

On Mon, Nov 4, 2019 at 8:42 AM Kārlis Goba <karlis.goba@...> wrote:
I realised I should have mentioned I was using Semi QSK. So that excludes Q7 and related circuitry.

--
Karlis YL3JG

Kārlis Goba
 

Wow, brilliant! While I was aware that the woodpecker is not really a very important issue, since it gets drowned by noise and not all use S-meter or decoder, it still nagged me that there has to be a solution for the sake of good engineering. This morning I also traced the source of the woodpecker to the LCD_RS pin, but didn't go deeper to investigate. My idea was to try to insert a series resistor on the LCD_RS line. I also observed that the LCD VO supply has a very obnoxious ripple for some reason which might be related or unrelated to this.

Isn't it just wonderful that it all can be solved by firmware update.

--
Karlis YL3JG

Kārlis Goba
 

Regarding the C6 cap, I still think it should have significantly larger value than 0.1uF, since it is in essence in series with the C43-C46 caps, which are larger by capacitance. It just feels that way intuitively if you think about the AC path, but I will run simulations of equivalent circuits. I think it adds unnecessary loss at the mixer currently.

--
Karlis YL3JG

Stephen Farthing G0XAR JO92ON97
 

Hans, 

It was Guido Pe1nnz who gave you the hint.

Yours, sleepily enjoying a beer with Alan at Schipol prior to flying home, 

Steve G0XAR 

Hans Summers
 

Hi Steve

Yes! Guido PE1NNZ told me! That's right, I remember now. Well it was a very good tip! While it was not directly the solution to the problem, it did point in the correct direction and so enabled finding the solution easily. Many thanks Guido PE1NNZ!

73 Hans G0UPL

On Mon, Nov 4, 2019 at 7:54 PM Stephen Farthing G0XAR JO92ON97 <squirrox@...> wrote:
Hans, 

It was Guido Pe1nnz who gave you the hint.

Yours, sleepily enjoying a beer with Alan at Schipol prior to flying home, 

Steve G0XAR 

Hans Summers
 

Hello again Karlis
 
Wow, brilliant! While I was aware that the woodpecker is not really a very important issue, since it gets drowned by noise and not all use S-meter or decoder, it still nagged me that there has to be a solution for the sake of good engineering. This morning I also traced the source of the woodpecker to the LCD_RS pin, but didn't go deeper to investigate. My idea was to try to insert a series resistor on the LCD_RS line.

Yes I did have the idea of a resistor too and I tried it. Both on the LCD_RS line and on the SDA signal to the Si5351A. On the RS line made no difference. On the SDA line, a small value resistance is required because there is a 1K pull-up resistor R3; small values of resistance made no difference at all. 
 
Isn't it just wonderful that it all can be solved by firmware update.

Yes, wonderful indeed! This is not the first time, either. Whilst QCX is not officially a Software Defined Radio (SDR), unless the definition of SDR is applied rather loosely, a lot of the functionality is controlled and implemented by firmware in the microcontroller and often tricks can be applied that solve hardware problems! 

An earlier trick was keeping the QSD running, at 27MHz, during TX - to maintain the DC bias on the sampling capacitors C43/4/5/6. That was an early firmware change 1.00a on 28-Aug-2017, that fixed some issues with the sidetone volume tapering off to near zero (due to DC bias drift). Another example of a hardware problem that could be solved by a firmware trick!

> Regarding the C6 cap, I still think it should have significantly larger value than 0.1uF, since it is in essence in 
> series with the C43-C46 caps, which are larger by capacitance. It just feels that way intuitively if you think about 
> the AC path, but I will run simulations of equivalent circuits. I think it adds unnecessary loss at the mixer currently.

I am less convinced. Don't forget the transformer windings of T1 are also in the RF path. The center point of the two phase splitting windings, i.e. the top of C6, is considered RF ground. This is a double-balanced Quadrature Sampling Detector configuration. I believe in theory, if the balance is perfect, zero current should flow here. Therefore one gets away with use of 10K resistors for the bias-setting potential divider and a small capacitance C6. Nevertheless I am not convinced completely of my argument either... and I will do some more experiments on this topic. Let me know what you find, too. 

73 Hans G0UPL

Paul Harrison
 

I'm so happy now that I made the effort to do the FW updates in situ with the USBasp it will
make upgrading the firmware a breeze. Thanks Hans for the continued improvements.

Paul DJ0CU.

Hans Summers
 

Hi Karlis, all

I *almost* made the sidetone click improvement in firmware too!

I tried to play with the PWM signal, by arranging for its duty cycle to be 50% but for there to still be a 700Hz frequency component present with a controllable volume (variable duty of the 700Hz component). I did this by various ways of mixing in other frequencies which are outside the audio passband. I *almost* succeeded. I kind of did succeed, except that there were some artifacts on the sidetone which deteriorate the pure-sounding 700Hz tone we have now. 

I think in the end that it is probably not possible to do cleanly with the limited processing capabilities of the ATmega328. 

So we should stick to the capacitor in series with R59 for this. 

73 Hans G0UPL


On Tue, Nov 5, 2019 at 10:38 AM Paul Harrison via Groups.Io <dj0cu=yahoo.com@groups.io> wrote:
I'm so happy now that I made the effort to do the FW updates in situ with the USBasp it will
make upgrading the firmware a breeze. Thanks Hans for the continued improvements.

Paul DJ0CU.

Kārlis Goba
 

Hi Hans,

I have an idea for the SIDETONE PWM signal, but it depends on how tight your timing/memory requirements are in your QCX code. You'd probably have to squeeze a high-frequency interrupt routine into your code for that. What if at the start of a tone (so right at the moment you switch from high-Z to PWM) you'd generate a 50% PWM, but at a much higher frequency, say 35 kHz. The OC1A output pin should be configurable to do that. Then modulate the PWM duty cycle according to a sine wave (and user sidetone volume setting). Going from high-Z to 50% duty will definitely not cause any clicks. The problem is you'd need to update the OC1A duty cycle rather often, 1400 times per second at the very least (and that should be sufficient). So, you'd go to 50%, perhaps wait a bit, and then switch between 55% and 45% (for example) at the rate of 1400 times per second. For higher volume use 75% and 25%. Or you could even have a nice shaped envelope, starting with 49%/51% and going up to the required sidetone volume. No need for a sine lookup table, the harmonics and PWM artifacts will get filtered away.

--
Karlis YL3JG

Hans Summers
 

Hello Karlis

I have an idea for the SIDETONE PWM signal, but it depends on how tight your timing/memory requirements are in your QCX code.

Yes, I tried various different things along these lines that you suggest. In the end after many hours I still couldn't make it work cleanly. It may be that some other interrupt with variable latency is preventing it from executing cleanly and inserting variation which shows up as low frequency components. If artifacts are too strong or too close then the filtering isn't enough. 

Yet... despite the hours... it was one of those things where I still have a nagging residual feeling the solution is just around the next corner. And that though there are few enough hours available... it would feel like a helluva win for my personal satisfaction if I could make it work. 

1400 times per second is not what I'd call particularly "often"... during my experiments today I tried various schemes and some were a lot faster than that... but... nothing that produced a clean-sounding note. I got 50% duty-cycle, I got firmware volume control, I got clean-sounding.... but I only ever got 2 out of these 3 at once! 

Ay ay now I'm gonna have to not give up just yet... will battle it some more, perhaps some other interrupts or CPU tasks can be suspended during transmit, etc., to free up some CPU time... 

73 Hans G0UPL 

Kārlis Goba
 

I know the feeling when the solution seems just around the corner, but let me not take away your time from QSX :)

--
Karlis YL3JG

Hans Summers
 

Too late bro...

I'm going to sleep now, to dream of abused PWMs and narrow slices of CPU time. And will have one more try in the morning...

73 Hans G0UPL 


On Tue, Nov 5, 2019, 23:01 Kārlis Goba <karlis.goba@...> wrote:
I know the feeling when the solution seems just around the corner, but let me not take away your time from QSX :)

--
Karlis YL3JG

Hans Summers
 

Hello Karlis, all

I managed to solve the sidetone click by firmware alone... this article is now updated with 'scope screenshots:

I am running the 16-bit PWM (Timer1) at 60x the sidetone frequency, e.g. 42kHz for 700Hz sidetone. There is a trade-off involved. If the PWM frequency is too low then it loses its ability to clear up the "clicks". 10kHz seems to be a minimum. If the PWM frequency is too high then the resolution of each change of 1 for the "Sidetone vol" configuration menu is too large (in other words, one loses fine control over the volume). As it is, the relationship is less logarithmic than it was. But with 0-99 settings available I don't think this matters. 

Since the other timers were occupied, I am using the PWM timer itself to generate the event that changes the duty cycle e.g. from 49% to 51% and back again, to create the 700Hz tone. Therefore the interrupt handler runs 42,000 times per second; once every 30 interrupts, the PWM duty cycle is changed. 

73 Hans G0UPL

On Tue, Nov 5, 2019 at 11:19 PM Hans Summers via Groups.Io <hans.summers=gmail.com@groups.io> wrote:
Too late bro...

I'm going to sleep now, to dream of abused PWMs and narrow slices of CPU time. And will have one more try in the morning...

73 Hans G0UPL 


On Tue, Nov 5, 2019, 23:01 Kārlis Goba <karlis.goba@...> wrote:
I know the feeling when the solution seems just around the corner, but let me not take away your time from QSX :)

--
Karlis YL3JG

Joe Street
 

Very clever.  Congratulations, it seems a rather ideal solution so long as the interupt doesn't create latency for some other item.

Joe

On Wed, Nov 6, 2019 at 8:41 AM Hans Summers <hans.summers@...> wrote:
Hello Karlis, all

I managed to solve the sidetone click by firmware alone... this article is now updated with 'scope screenshots:

I am running the 16-bit PWM (Timer1) at 60x the sidetone frequency, e.g. 42kHz for 700Hz sidetone. There is a trade-off involved. If the PWM frequency is too low then it loses its ability to clear up the "clicks". 10kHz seems to be a minimum. If the PWM frequency is too high then the resolution of each change of 1 for the "Sidetone vol" configuration menu is too large (in other words, one loses fine control over the volume). As it is, the relationship is less logarithmic than it was. But with 0-99 settings available I don't think this matters. 

Since the other timers were occupied, I am using the PWM timer itself to generate the event that changes the duty cycle e.g. from 49% to 51% and back again, to create the 700Hz tone. Therefore the interrupt handler runs 42,000 times per second; once every 30 interrupts, the PWM duty cycle is changed. 

73 Hans G0UPL