Some live use findings

[radi8]

I have been using the CWKeyer for a while now with the Winkeyer version under varying conditions ranging from rag-chew to contest to heavy traffic CW message handling nets. I feel that I am finally in a position to make comments which could affect the future direction of the keyer. Some of my general comments are already incorporated into the keyer code as it is now and some could be added/changed. The two biggest issues for me were:

1. Taking the keyer into the field with a simple radio (TS-50) for SOTA is not successful due to not being able to recall fixed messages as there are no command and memory buttons. The keyer should be recommended for fixed station use where the facilities of Winkeyer etc. can be utilized.

2. The tiny initial delay in sidetone is an issue and does cause me to make keying errors particularly in conjunction with the tiny noise burst from the RX.

Dot 1 Unit
Dash 3 Units
Element Space 1 Unit
Letter Space 3 Units
Word Space 7 Units

When the key is operated, the key press should be detected with the fastest algorithm possible. I have never experienced a glitch on the key line which has caused a spurious character to be sent and thus it would be reasonable to assume that any detected keying signal is a genuine key action and process it immediately. A debounce routine should be initiated to avoid extraneous high speed key signals with switch noise and all key signals ignored until debounce has finished. In the unlikely event that it was a glitch for say a “Key Down” then after the debounce a key up condition would exist and the radio would have transmitted a very short blip of tone equal to the length of the debounce time. It is improbable that operators will be keying faster than the debounce time so elements will not be merged. The current key press detection seems pretty good to me.

Sidetone needs to be produced immediately from the keypress and have no relationship to ptt. With the current setup, outside of the hang time there is a slight delay in sidetone but once ptt is raised sidetone is excellent and snappy with the keypress until there is a long pause and the cycle begins again. I’m not such a good operator and this situation causes me to make a few more errors than I normally do.

The keyer should mute the audio from the radio the moment key is down. Ideally audio should stop with key down but some SDR’s use an audio procedure that plays an internal buffer and if that has just been filled at ptt time the RX audio plays out the buffer which results in a few milliseconds of the stream. Qt’s Audio is an example of this. In a traffic net, stations very carefully zero beat so your sidetone is on the same frequency and a burst of tone just as you are keying is very off putting. Large static crashes can also mask your initial CW element and again cause errors. The effect of this can be tested by using Quisk in alsa mode where the RX audio mutes almost immediately (but not quite) and in pulse mode where there is quite a lag. I expect the switch off for the audio stream will require a shaped trailing edge.

PTT should be immediately sent to the radio so that those radios that utilize ptt can start the changeover process before the CW keying signal arrives. For those radios that respond to the keying signal only, ptt will not matter as they will internally handle the changeover delay before initiating RF.

CW keying should have a programmable delay from key/paddle operation to enable ptt controlled radios to complete their switching before the keying signal arrives although many will have these delays built in hence the need to have this delay time adjustable. For key/paddle controlled radios the time would be set to zero.

I have put a pair of 8 ohm speakers onto the CW Keyer and although I need to turn the Master Volume well up the audio is really good and playing music from my computer is miles better than the built in sound card. Usually I am on headphones which are too loud on the volume setting for the speakers so either I need to correct this in the keyer or build an external attenuator for the headphones.

I have not even tried the microphone so have no comment to make here but I will get to it in a while.

Well there are some thoughts which may not necessarily be right but are worth considering and debating.

73, Graeme ZL2APV

[dl1ycf]

Well,

in my latest keyer software, I do support push-buttons so you can replay standard messages which can be "loaded into the eeprom" with a standard WinKey tool. However, the power consumption of this device makes it not the ideal compagnon for SOTA activations, here the original K1EL device is much better as it can "live" from its standard batteries for almost a year or so.

As to the slight delay, it only occurs if you use the "PTT" output, and only upon a RX/TX transition. You can set it to zero in the "standalone" settings if you want, so no reason to complain.

Muting RX audio "while the key is down" is not implemented, as it probably produces clicks. But there is an option to mute RX audio while PTT is active.

"PTT should be sent immeditely to the radio" : this is acutally done. However, if you do NOT select a PTT "lead-in" delay, then PTT and key-down arrive simultaneously at the radio. I think what you are thinking of is to delay ALL key-up and key-down events by 100 milliseconds or so, while not delaying the side tone. This should be possible using timers.

In the current implementation, a lead-in time is respected so all your hardware has enough time to go from RX to TX, but at the expense of the first element after RX/TX being delayed (as you point out).

As to the sound quality: the Teensy is a surprisingly good "sound card". Some users have reported very bad audio quality when connected to a RaspPi, but this turned out to be caused by a very noisy +5V on the USB line: cutting the trace that connects V(USB) with +5V on the Teensy board, and supplying "clean" +5V to the Teensy/Shield, solved the problem.

My "take home" message is that I should consider delaying all "Key down" and "Key up" events by the PTT lead-in time, but to
have the side tone in-sync.

[radi8]

Muting the audio while PTT is active works beautifully. Yes I am aware that you sacrifice break-in operation but with a web-sdr you are never going to get that anyway. The problem does not exist with Quisk Alsa mode or piHPSDR but for radios using pulse audio etc. the burst of Rx noise over the first element of the CW character was very disconcerting and for web sdr's can last for a whole word. I feel a little foolish that I had not picked up that you had already implemented this but it is overridden by how much better it is when using long latency radios.

I had a delay of 1 (10 mSec) and changed it to 0 but the difference was hardly noticeable. I have left it at 0 as I use PIN diode switching and can beat the RF out of HL2 anyway but this will change as I am building a small 300 Watt linear and may have a relay on the changeover there and may go back to the 10 mSec delay when it is eventually done.

Your take home message of delaying all "Key down" and "Key up" events by the PTT lead-in time, but to have the side tone in-sync would pretty much make this the perfect keyer for me. I can see that the coding for this is not trivial and is a big ask. I would also ask if it is possible to make the Rx mute on PTT a front panel option (or through something like Flwkey) as when operating with fast response radios I would want the option to have break-in operation but for web sdr I need the Rx to mute.

BTW the sound card on the Teensy is so good that I have discarded the soundcard on my main PC and use the Teensy for everything. When operating on speaker it can (just) drive a pair of small Panasonic speakers to a comfortable listening volume in a computer desktop situation although I usually use earbuds and might look at adding Bluetooth for operating convenience.

As I am in my 80's I have to look to the future and consider the possibility that I may have to live in some kind of retirement village where antennas are not allowed. My overriding project is to get the client server on piHPSDR running so I can operate the client from my home and the server at my family's property. This may help explain why having the Rx mute on PTT was important to me and how grateful I am for your having implemented that.

73, Graeme ZL2APV

[dl1ycf]

I think I should make some explanations: a) in piHPSDR, in the RADIO menu, you can check "Mute RX on TX" which means that RX audio is muted while doing TX. However, having RX audio while doing TX is only possible under two conditions: i) DUPLEX checked and ii) you are NOT doing CW. The reason is, that piHPSDR is instrumented to produce a CW side tone, and so during CW you cannot have RX audio. This is so because the RX audio is produced by the RX thread and the CW side tone by the TX thread. So if the mode is CW, audio is produced ONLY by the TX thread. So if using pihpsdr you should never have any RX audio while doing TX in CW. For your intended setup the delays are probably such that "mute on PTT" is the way to go. This also applies if you use piHPSDR to control a transmitter at home but use a webSDR for RX (some people in noisy environments do so). I once was in contact with a ham from the netherlands which has built a keyer with a pot for adjusting the delay. He mutes the RX in the rhythm of the Key-up/down but with a delay adjustable with the post. So he can mute his own signs in the webSDR audio stream. This is quite advanced. b) As to the other things. I think two points are very clear: - the side tone has to follow the internal state of the keyer, otherwise the operator gets crazy - if you hit the paddle, it must be possible that the first key-down comes with a delay after the "PTT on" signal. My solution to this is that if you hit a paddle in RX mode, the side tone AND the first key-down come with a small delay (typically about 100 msec) but this only affects the first key-down after a RX/TX transition. I got completely used to this, but I hear reports from people that want the key-down/up signals delayed. Technically, no problem. One probably cannot use timers since with a delay of about 100 msec and decent CW speed, you get a handful or more key-up/down events "queued" before the first one is "shipped out". The Teensy4 has a pool of 7 timers but other MCU have less. However, I think one can just rely on the main loop() being executed at least once in 1-2 milli-seconds, so one just puts the key-up/down events in a ring buffer and and the start of each loop() one looks up what is due and exectutes the event. There is another reason why I am not so much in favour of this: I also use the keyer together with legacy rigs which produce their own side tone. And then I still need the PTT lead-in time but the side tone now comes from the key line and must be in-sync with the keyer state (that is: not delayed). So on the bottom line I am in favour of the present situation, which is also what the original WinKey device does. I am not in the 80's but probably also old-fashioned: I find personal e-mail discussions much more fruitful than the github "discussion" forum. And I do not get any notifications is something is happening there so I have a look there only occasionally. Yours, Christoph.