I have been working on a new Bayesian Morse decoder for FLDIGI for a while.The goal was to have a CW decoder that adapts better to different operators rhytms, sudden speed changes, signal fluctuations and noise and still is able to decode Morse code fairly accurately.

While this software is not perfect and has some bugs I am happy to release this brand new version for alpha testing. I finished the software integration to FLDIGI v3.21.75 and spent few hours today listening bands. Below is a small example of W1AW code bulletin at 3.58105 MHz received with KX3 and a side by side comparison of legacy CW decoder vs Bayesian decoder:http://ag1le.blogspot.com/2013/12/new-morse-decoder-part-2.html

I would like to get some alpha testers who are not afraid of compiling this code from sources, playing with it, breaking it and hopefully also helping me to find the bugs. For example - the noise level estimator (noise.c) needs some serious work. If you have a algorithm that does the job better this would be one place to start improving. Also, if you know Viterbi or Kalman filter algorithms like your pockets I would like to get help fixing a bug that appears in posterior probability calculations in probp.c occasionally.

Anyways, happy holidays for all FLDIGI users and hope to work you over the radio.

I think I need to change some things in the configuration. It decodes CW, but when I check the Bayes decoding, it doesn't copy CW as well. The version I had copied CW better. I was temped to change the configuration, but I don't have much more time to play with it this week. If you could suggest how best to configure it, I'll try it again.

I see the old fldigi version has the Bayes decoding box. I didn't see that before. I don't have it checked.

EDIT: I see the Help > About in both versions shows v. 3.21.75. Oops. I shouldn't have installed the new version where I did. The config is still different in both versions; I don't know what's going on.

I could post or e-mail the config files or a screenshot. Let me know what you suggest or need.

I played with it a little more. It does not copy CW correctly at all when Bayes is checked. Unchecking it, it copies CW very well.

I tried turning the volume down as you suggested, and no change.

Perhaps if I changed the configuration?

Mike

Can you verify that before you switch on Bayesian decoder you have Configure / Modems / CW / General / "Matched Filter" checked and "FFT Filter" not checked? Also, please check "Tracking" on. After this is verified please click "Bayesian decoder" on and observe lower left corner. If you see "CW Rx NN" where speed NN is changing rapidly then the new decoder is working. As mentioned this version is still very sensitive to volume and signal/noise level. In my system I am adjusting KX3 RF volume (I have AGC turned off) so that CW signal is barely visible on the waterfall.

There is a bug that shows up by turning CW Rx speed indicator negative - if you get into this situation you need to restart the application. Typically this happens when for some reason the likelihood calculations in "probp.c" exceed 1.0 which on the next few sampling rounds quickly amplify pmax to a large number. I have not found the root cause for this bug yet, but seems to be somehow related to signal strength and SNR of the signal. The noise power estimator "noise.c" is one suspect...not sure if this part really works.

Can you verify that before you switch on Bayesian decoder you have Configure / Modems / CW / General / "Matched Filter" checked and "FFT Filter" not checked? Also, please check "Tracking" on. After this is verified please click "Bayesian decoder" on and observe lower left corner. If you see "CW Rx NN" where speed NN is changing rapidly then the new decoder is working. As mentioned this version is still very sensitive to volume and signal/noise level. ...

Thanks MikeThis is great news...your are the first person reporting successful Bayesian decode. As you play with this version I would appreciate your feedback on things like

* Signal strength of successful / non-successful decoding

* CW speed - any limits you find when decoder stops decoding

* QSB - how does signal fluctuation impact decoding accuracy

* Waveforms - using the Scope feature of FLDIGI - any findings on better/worse decoding

Any screenshots and WAV file captures to document findings would be welcome.

The software is still fragile, will break easily and is not fully integrated with FLDIGI user interface. You will most likely find the "pmax overflow" bug - symptoms include CW Rx speed indicator on bottom left corner showing a large negative number, sometimes it goes to a mode where you get only series of letter E E E E E etc. You need to restart FLDIGI application as it does not recover from this bug yet.

This is a fairly complex piece of software and it requires still quite a lot of work to make it really useful for the ham community.

In short the speed estimator part of the algorithm that should track and find correct WPM speed on received signals like this:

is misbehaving when decoder gets too large signals. The threshold when this happens is very sharp and non-linear - here is error case:

I have converted all the files from C to C++ to make it easier to re-integrate to FLDIGI. I will continue cleaning up the code and keep working to improve the speed estimator part. Once I have the next alpha release ready for another set of tests I will announce it in the fldigi mailing lists and eham.net CW forum.

I can't test this anymore. I screwed something up when I was playing with the mixer.

Maybe someone can give me some advice. I don't know where to begin to fix this.

I was trying to find the setting in the mixer that would let me adjust the signal level to running applications. In the process, I managed to "kill" the audio the signal to any running applications, including fldigi and qsstv.

The sound from my rig still comes out the computer speakers, as it always has. But that's all.

I restored the old /home/mike/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-mixer.xml but it didn't fix it, even after a reboot. (/home/ is the only backup I have.)

Any suggestions? I'm using Xubuntu 12.04.3 LTS (Precise), which is Ubuntu with the XFCE 4.8 GUI.

I don't know exactly what Bayesian means, either. I'll concern myself with that after this audio issue is solved. :-)

This is a very basic question, but in what respect is the decoder Bayesian? What information is being used and 'updated?'

Hi SteveThe decoder has several built-in models, such as

* baseband signal channel model

* keystate model

* speed transition model

* Morse symbol transition model

* letter transition model

As the decoder receives samples of filtered audio signal after enveloper detector (currently at rate of 200 Hz) it updates these models and calculates transition probabilities using Bayesian framework. Sequence of all possible keystate transitions are hypothesized and correlated with the incoming signal , and the most likely sequence is the output as the best estimate.

Copyright 2000-2017 eHam.net, LLC
eHam.net is a community web site for amateur (ham) radio operators around the world.
Contact the site with comments or questions.
WEBMASTER@EHAM.NETSite Privacy Statement