Re: #qcx Firmware version 1.02 release #qcx

Hans Summers
 

Hi Tom:

> I find that the sidetone issue in T102a occurs when the keyer menu is set for 
> straight key, but the issue does not occur not when set for an iambic paddle.  
> That's kind of curious.

Many thanks for this observation. I investigated and determined that the problem occurs because in straight key mode, the key state is continuously checked and actioned; in paddle modes, once key-down has started there is no further change to the TX state (and sidetone) until a defined period later e.g. 0.1 seconds for a 12wpm "dit". The continuous updates in straight key mode were resetting my new sidetone generation system. 

Easily fixed, just one line of code... now straight key sidetone is perfect too! 1.02b coming shortly. 

Hi Chopper:

> T1.02a loaded and working fine with the exception that as mentioned above 
> sidetone freq becomes distorted below 750  and as you get down to 500 or 600 
> the tone disappears and is simply key clicks.  Not a major issue but a change as 
> 1.01 had working tone at 500.  If you are having issues with side tone simply 
> increase it to 750.

I investigated this too and did not completely agree with your findings. From what I saw (or rather, heard) here the sidetone is working perfectly fine as your lower its frequency. However, it gets very quiet. You are left with whatever residual clicks exist (from Tx/Rx switching etc) that are unrelated to sidetone. But they are prominent because the sidetone volume is low. 

The low sidetone volume is due to two factors:

1) At low sidetone frequency, the timer period that generates the Pulse Width Modulation (PWM) is corresponding longer. The fixed amount (depending on volume setting) that is added/subtracted for the sidetone waveform generation is therefore proportionately smaller than it is at 700Hz; which results in a lower volume. 

2) The sidetone generation method is now much cleaner and more elegant than the previous system. Rather than a very short pulse whose harmonics are being filtered out, we now have effectively a proper 50% duty cycle squarewave at the chosen sidetone frequency. I think the CW filter does a much better job at filtering this, with the result that the attenuation is higher; remember at 500Hz the skirts of the CW filter mean already 15-20dB attenuation. 

By the way for fun I set the sidetone frequency to 350Hz, and I could just about barely hear the 2nd harmonic at 700Hz coming through the filter; this is satisfying because it is a very low level as one would expect for a nice clean squarewave (50% duty cycle). 

I could solve 1) by automatically adjusting the PWM frequency (which is 42kHz for 700Hz) so that the multiplier is higher at low sidetone frequencies, and 42kHz would be maintained; I'm a bit reluctant to fiddle with that in case it breaks something else ;-)   I could also have solved it by automatically increasing the size of the sidetone frequency PWM steps but, since the timer holds integers and the values are already fairly small, that would get complicated since I wouldn't be able to put fractional values in. 

Therefore just to keep everything very simple and not risk breaking anything (after all, most people just leave sidetone frequency at the default 700Hz), the simple solution I came up with is just increase the number of digits of the sidetone volume to 3 (the default volume is still 99, now displayed 099). This gives the operator more flexibility to increase the sidetone volume if lower sidetone frequencies are preferred and the volume is found to be too quiet. 

The maximum volume value that makes any sense is 0.5 * 20,000,000 / (60 * sideToneFreq) otherwise the width of the PWM for the sidetone frequency generation would exceed the timer period. So for example:
  • 700Hz sidetone: max volume 238
  • 600Hz sidetone: max volume 277
  • 500Hz sidetone: max volume 333
  • 400Hz sidetone: max volume 416
But don't worry, if you set a volume level higher than the "maximum" then the system automatically limits it according to the formula. 

Hi Guido:

> This older display seems to requires at least 60us delay after the
> first nibble write, and also require RS to be HIGH for an extended
> period of time. The newer display is not sensitive to this at all..

:-O   All the QRP Labs kits forever have never had those timings... there is no 60us delay after the first nibble write (before the next nibble write). Neither is RS high for an extended period of time. The only change I made to fix the problem with some of the displays is that I extended the pulse width of the LCD_E signal by 2 CPU cycles (100 nanoseconds). So to toggle the LCD_E signal the port pin is set high, then wait 2 CPU cycles, then set it low again. This puts the LCD_E signal back to the former behaviour, which is also the same as used on all other QRP Labs kits (Ultimate3S, VFO, Clock). 

Version 1.02b will be coming shortly... I just want to check the other feedback received in other threads and emails... 

73 Hans G0UPL

Join QRPLabs@groups.io to automatically receive all group messages.