Multichannel CW decoderDevelopment of the Bayesian CW decoder is moving forward. Many thanks to Dave W1HKJ there is now an alpha build available also for Windows platform. The v3.21.83cw-a4 tarball sources and Windows version are available in http://www.w1hkj.com/ag1le/
This version has still multiple problems that need to fixed. In Fig 1. below I have screenshot where I have the multichannel signal browser and Fldigi configuration screen for Modems / CW visible. I am running Windows FLDIGI version v3.21.83cw-a4 connected to PowerSDR v2.6.4 and my Flex3000 radio.
The following description explains the options and expected behavior in this alpha software version. Things are not yet well optimized so you are likely to see a lot of misdecoded signals. I am interested getting feedback and improvement ideas to make the Bayesian decoder better.
Checkbox "Bayesian decoding" enables multichannel operation. If you have Signal Browser open you can slide the horizontal control at the bottom to adjust the signal decoding threshold. With lower threshold you can enable weaker CW stations to be decoded but often you get just noise and the decoder produces garbage as visible in Fig 1. The software detects peaks in the spectrum and starts a new decoder instance based on the detected peak signal frequency. It tracks each instance on a channel which is rounded at 100 Hz of the audio signal frequency. Number of channels and timeout value can be set in Configure/User Interface/Browser menu.
If there are two stations in nearby frequencies less than 20 Hz apart the other one is eliminated. This is done to reduce impact of frequency splatter - otherwise one strong CW station would spin up decoders on multiple channels. Also, in this version this process is done for every FFT row in the waterfall display. Because I am not doing any kind of averaging yet the detected peak signal center frequency may be incorrect and therefore decoder is tuned on the wrong frequency. With narrow filter bandwidth setting this may cause garbage in the decoder output.
|Fig 1. Multichannel CW decoder|
In this version each decoder instance uses the same filter bandwidth that is set manually in Configure/Modem/CW/General tab. This means that Bayesian decoder does not have optimal, speed dependent filtering. For faster stations the bandwidth should be larger and for slow stations it can be narrow.
This means that decoding accuracy suffers if there are multiple stations operating at different speeds. Once again this functionality can be improved as the Bayesian decoder does provide a speed estimate automatically but I haven't had time to implement the automatic "Matched filter" feature yet. The filter bandwidth is taken from the "Filter bandwith" slider value for all Bayesian decoder instances.
On receiver speed estimation Rx WPM value is updated only for selected CW signal on the waterfall. You can also observe that with Bayesian decoder enabled the speed display is updated much more frequently than with the legacy CW decoder. Bayesian decoder calculates speed estimate every 5 msec and provides a WPM value whenever there is a state change (mark -> space or space->mark) in the signal. Sometimes the speed estimator gets "stuck" in lower or upper extreme. You can adjust the "Lower limit" or "Upper Limit" on the CW / General Transmit section - this will give a hint to the speed estimator to re-evaluate speed. Obviously, if the speed estimate is incorrect you will get a lot of garbage text out from the decoder.
Tracking feature is not implemented properly yet for the Bayesian decoder. This means that if you start to transmit your speed may be different than the station that you were listening. TX WPM is visible in the configuration screen.
Once again, this is an alpha release provided in order to get some feedback and improvement ideas from FLDIGI users. You can provide feedback by submitting comments below or sending me email to ag1le at innomore dot com. It would be very helpful if you could provide audio samples (WAV files can be recorded using File / Audio / RX Capture feature of FLDIGI), screenshot of what CW parameter settings you are using and general description of the problem or issue you discovered.
If you are interested in software development I would be very grateful to get some additional help. Building a Bayesian Morse decoder has been a great learning experience in signal processing, machine learning algorithms and probability theory. There are plenty of problems to solve in this space as we build more intelligent software to use Morse code, the international language of hams.
The translation is done in the module transl.cxx - there is a table very similar to what is in Wikipedia article you are referring to. I am not sure if the FLDIGI display widgets can handle Japanese characters yet, so that would have to be checked. Otherwise there is an ongoing effort to translate FLDIGI to multiple languages, see po/LINGUAS file - currently it has these: es fr it pl de.
So your idea may be feasible but requires some work. Replacing Wabun code in transl.cxx is just a trivial copy / paste exercise. If widgets support UTF-8 characters then this is easy, otherwise building UTF-8 support needs additional help from FLDIGI development team.
Hello. I've enjoyed following this blog. I'm wondering whether some of these techniques could be applied to PSK31? Thanks.ReplyDelete
if you look at FLDIGI source code there is a Viterbi decoder implemented in the PSK mode. It provides a most-likely sequence estimator, in similar manner than the algorithm in Bayesian Morse decoder.
Thanks for your interest in my blog.
Hi! I know this article is several years old... I was curious about the screenshot you have for "Figure 1". What application is providing the waterfall display along the bottom third of the page? I see two waterfalls - the one that's built into fldigi, but I do not recognize the other one. Is it from an SDR application or a fldigi plugin? Thanks!ReplyDelete
Hi JeffH - it is PowerSDR (I had Flex-3000 rig at the time). See https://ke9ns.com/flexpage.htmlDelete