

Like Martin I did some testing with 4XZ 4331/6007 kHz when it was sending a fixed pattern and S4-5 signal strength. Also, OOK amplitude slicing is a well known problem and there are lots of algorithms that could be implemented that would likely perform better. I had some private messages with Benson and we agreed that it would be useful to display the Goertzel output in a graph just like the S-meter extension so the threshold dynamics could be studied. The most obvious failure mode of that is what happens to the band during a contest/rare-DX situation (i.e. I like the idea but it assumes the surrounding frequency choices will be quiet. So maybe performing multiple Goertzels was someone's intent but they just never got there. It's just doing some running decayed averaging before the decision slicing.

#Best cw decoder code
Oddly enough, the variable enabling the automatic threshold correction code is called "use_3_goertzels". Might a bit higher threshold with a "leaky bucket" be more realistic?) (I see that the error count will reset itself after a period of no errors.
#Best cw decoder full
Having written CW decoders before (assembly, Z80 was the first) I know how tough it is to come up with something that is even semi-good (this one is at least "semi-good") but go beyond that, so I know full well that this is and always will be a work in progress. I would suppose that once the detector has good confidence in that it has the right speed, it should be a bit less wont to change it immediately - but I do know that determining this sort of thing is tricky.

One assumption made by the CW decoder that doesn't occur in the real world (unless one is using a straight key, which is comparatively rare - and most people are remarkably stable WPM-wise, when using an SK, anyway) is that it seems to assume that the average person sending will have one hand on their paddle and the other on the speed adjust: In other words, after a run of good copy, a static crash or a bit of QSB will cause the speed to go out into the weeds and strings of characters will be lost. I suspect that this may not be too relevant on this application, but I thought that I'd mention it in the event it was useful for something else. To be sure, it helps to know with certainty the precise frequency to be detected! What I ended up doing was running three Goertzels at a time: One on the desired frequency and two others - one just above and another below, separated from the desired frequency by a value commensurate with respect to the effective BW of the Goertzel.īy taking the ratio of the on-frequency decoder to the algebraic sum of the two "off" frequency decoders I not only narrowed the effective detection bandwidth, but made detection far more reliable and much faster - particularly in the presence of noise/modulation as the need to determine an absolute detection level became irrelevant. In this case it was the detection of the subaudible tone transmitted by another station. Several years ago, I was one of the main people behind the code on the mcHF SDR transceiver and I ran across a "problem" with the Goertzel that I'd encountered when I'd used it before: Trying to make sense out of the detection value it produced. CW skimmer or MRP 40 will probably be even better for weak signals.

These numbers are with daytime band noise present at 14 Mhz. I used a virtual audio cable and compared the results with Multipsk in CW QRP mode, this program copies to about -115 dBm. In any case as others already mentioned it is hard to beat morse code processing by our brains, especially when it comes to hand keyed signals with imperfect timing in the presence of noise and other signals. Still not a bad result although it would certainly be nice to decode even weaker signals that are still readable on the waterfall. "Training" can be forced by clicking the threshold correction button but in my tests seldom recovers the situation. Reducing the signal below that decoding starts to fail. It seems the decoder has a reasonable tone tracking range for stronger signals down to about -108 dBm. My initial suspicion that the CWN filter pass-band and the decoder center frequency did not match was incorrect and caused by a frequency error in the RF signal I used previously. Tried combinations of the above parameters and this time used a GPS disciplined cw rf test signal.
