Chris I re-read your comments below...I think you are on the right track here. I have some ideas how to re-purpose the code that already exists:
On Wed, Aug 20, 2014 at 10:59 AM, Chris Albertson <[email protected] > wrote: > > I'm thinking now that recognizing CW is a lot like speech recognition. > But the up front encoding needs to be some kind of phase locked > loop on the "dit period" > > I have a standalone C++ version of the Bayesian Morse decoder that I integrated into FLDIGI software package recently. The software actually does provide several types of front encoding that might be useful with NuPIC. The standalone code is available in Github https://github.com/ag1le/morse-wip but it requires some clean-up work, as my focus has been on FLDIGI integration in the last few months. We have basically two "phase locked" options to extract data for NuPIC 1) Symbols The output from trellis.cxx where it calls transl.cxx might be one possible integration point to NuPIC. Trellis.cxx basically emits Morse symbols that are timing wise locked to actual Morse speed. There are 16 different symbol combinations, namely /* 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 */ /* .^ .~ .w .p -^ -~ -w -p ^. ^- ~. ~- w. w- p. p- */ where symbols are . = "dit" signal - = "dah" signal (3*dit in length) ^ = dit long silence (element space) ~ = 3*dit long silence (character space) w = 7*dit long silence (word space) p = pause I am using these symbols 1...16 in transl.cxx to translate incoming symbol sequence to characters. We could insert NuPIC between trellis.cxx and transl.cxx to "learn" typical symbol sequences and make predictions before feeding output to transl.cxx. The benefit could be to reduce noise (i.e. misdecoded symbols ) and to predict correct character even though part of the sequence would have incorrect symbol(s). This would be a simple integer encoder (values 1...16) to NuPIC that outputs predicted value (1...16) based on learned patterns. We could potentially also use the anomaly detection as an indicator to user to show how confident the decoder is. 2) MAP estimate of the key state In bmorse.cxx please check the line retstat = mp->proces_(zout, rn, &xhat, &px, &elmhat, &spdhat, &imax, &pmax, buf); variable xhat returns the MAP estimate of the keystate from incoming signal. This xhat is basically binary number with 1 representing presence of signal and 0 representing no signal, and is speed locked (spdhat provides current speed estimate in WPM). This would be lower level bit stream data that could be fed into NuPIC. NuPIC would learn typical bit patterns and provide anomaly detection (useful feature itself) or prediction. The challenge would be how to then use this predicted keystate information to do actual decoding. I have another piece of code in FLDIGI cw.cxx that has the legacy FLDIGI CW decoder, for which I implemented fuzzy decoder based on BMU algorithm that I took from "Self Organized Maps" neural network package. This could be used to decode predicted bit pattern back to characters. I also thought NuPIc would be great for this, just pass in the audio > stream.... But I don't think it's up to the job. > > Audio processing is tricky subject especially when dealing with noise and interference. I have spent quite a lot of time on trying to figure out best CER vs. SNR strategies. As Signal-to-Noise Ratio (SNR) goes down you Character Error Rate (CER) goes up. FLDIGI has pretty good audio front end - I have copied the basic filtering and AGC methods to the standalone C++ code as well. See http://ag1le.blogspot.com/2014/07/new-morse-decoder-part-6.html - this has description of the latest, multichannel Morse decoder alpha build that is pretty stable. You can download the code (source + Windows binaries) from http://www.w1hkj.com/ag1le/ This has a fully functional decoder using Bayesian algorithm, if you want to give it a spin and see yourself how it works. Any thoughts or comments on above? =============================================
