On Wed, Aug 20, 2014 at 2:20 PM, Skeptical Engineer <[email protected]> wrote: > I think that NuPIC is a perfect solution for CW interpretation. It would > require some front-end work to be done. I’m the one who chatted the > questions in to Office Hours about audio coding last week, and I’m looking to > start coding some audio front-end stuff, building on the code that already > exists for that. I was looking more at audio music and spoken language > decoding, but CW could be a good intermediate step. I need to learn more > about the types and scope of variation in the code transmissions.
What do you need to know? First off this can be very easy if the Morse Code is machine generated and there is little noise. You don't need machine learning for the easy case. it can be hard coded in C. It is just a lookup table. Next up on the scale is real-world off the air decoding of strong signals. This has been done too. Using technique as in above but with much more signal processing up front. Still no "intelligence" involved. What is needed is human level recognition. The current state of the art is just short of human level performance. One thing that MUST be done to make the effort of practical use is to sort out WHO is sending WHAT. Listen and you hear tones being transmitted with each sender using a slightly different tone. But in is very important to know that no station is actually sending AUDIO. The tone is an artifact of the RECIEVER and is not present on the airwaves. What you hear is the "beat frequency" between the sending and receiving radios. If the tone sounds like it is 600Hz then the two radios are tuned 600Hz apart. The transmitter is sending only an unmodulated carrier. Why bring this up? Because a working CW decoder would likely be listening to a wider bandwidth than audio and it is "listening" to a power spectra not an audio MP3 file. You also will need to understand some of the conversation. At least enough to pick out the call signs. But we can do this with a simple "regular expression" A simple left recursive grammar s almost over kill for "understanding" these conversations. So it should be easy for CLA, that fast can be done The final step would be to couple this with "operations". For example the computer can not hear a signal, so it turns so knobs (so to speak) on the radio to adjust a filter or whatever. These signals are coming in over the air and are not recorded to we can "do stuff" like point out antenna at the transmitter, filter out noise. Why say this: Because I think THIS is where something like NuPic can really shine, when it plays an ACTIVE ROLE. You need this for human level performance. Some very good real-world example MP3 recordings are on the link below. http://www.dxuniversity.com/audio/ These require human level performance to make sense of. Notice that humans needs to be able to keep overlapping conversations logical separate. With speech we can do this because everyone has a unique sounding voice. It is kind of this way with CW too. Summary. The easy case is very easy. A beginning first year university computer science student could decode Morse Code under ideal conditions. In the real-world "pile up" case CW is as hard as trying to understand a dozen overlapping conversations at a cocktail party where everyone is talking at once. It is well past the current state of the art in speech recognition. But I think CW is a good area for research just because of this range of difficulty. The trap is developing a technique that ONLY works on the easy cases and can't scale up. > > NuPIC is the brains that recognizes patterns, we just need to figure out the > right sensory arrangement to see the most useful patterns. > > rich > > On Aug 20, 2014, at 11:21, Matthew Taylor <[email protected]> wrote: > >> Chris, >> >> Please keep in mind that this is very early stage technology. We are >> working on the foundations of HTM with NuPIC, and we open-sourced the >> codebase to get community involvement as soon as it was feasible. >> True, NuPIC is not a turnkey solution for any problem at this point, >> but our goals are to share this tech with anyone who wants to work on >> it, and encourage motivated developers to craft solutions to >> interesting problems. >> >> In the future, I imagine a library of community-provide encoders that >> can be easily plugged into NuPIC. (For other musings about the future >> of NuPIC, see [1].) But in the meantime, we have a lot of work to get >> done. If you want to be a part of it, you could join our sprint >> planning meetings [2] and open office hours [3]. >> >> [1] https://www.youtube.com/watch?v=QPkA6nJifOw >> [2] >> https://www.youtube.com/watch?v=oB71cqyRi9s&list=PL3yXMgtrZmDrtAuw9jJCNbaJmW3nSD3hC >> [3] >> https://www.youtube.com/watch?v=MWBFw4WoZxA&list=PL3yXMgtrZmDqsqo6hytKjhrkfFNEYDqfn >> --------- >> Matt Taylor >> OS Community Flag-Bearer >> Numenta >> >> >> On Wed, Aug 20, 2014 at 7:59 AM, Chris Albertson >> <[email protected]> wrote: >>> I posted this same exact question here some weeks ago. I've not >>> read your links yet but I will. >>> >>> My conclusion about NuPic is about the same as your #1, #2 and #3. >>> That is you need a large "do it yourself" solution on top of NuPic, >>> so I wonder what's gained, If you need to write you own encoder, >>> layering and feedback and then extract the results (inverse encoder?) >>> what is gained by using NuPic over some other NN library? Those >>> "higher order sequences" would be handled in NuPIc by a hierarchy of >>> CLAs that you would have to implement. >>> >>> 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 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. >>> >>> On Tue, Aug 19, 2014 at 9:39 PM, Mauri Niininen >>> <[email protected]> wrote: >>>> I am looking for some expert advice from NuPIC gurus here. >>>> >>>> I have been working on the problem of decoding Morse code from noisy, real >>>> life signals as received using HF radios. I have implemented several types >>>> of signal processing and machine learning algorithms trying to improve >>>> accuracy and reduce decoding character error rate (CER) caused by various >>>> reasons, such as >>>> - poor signal-to-noise ratio >>>> - signal fading due to RF propagation >>>> - poor rhythm & timing of hand keyed CW >>>> - rapid speed changes >>>> - signal interference from adjacent frequencies >>>> >>>> If you are interested in this subject there is more detailed descriptions >>>> on >>>> problems and solutions I have tested so far in here: >>>> http://ag1le.blogspot.com/2013/09/new-morse-decoder-part-1.html >>>> http://ag1le.blogspot.com/2014/06/new-morse-decoder-part-4.html >>>> http://ag1le.blogspot.com/2014/07/new-morse-decoder-part-6.html >>>> http://ag1le.blogspot.com/2013/01/towards-bayesian-morse-decoder.html >>>> http://ag1le.blogspot.com/2013/02/probabilistic-neural-network-classifier.html >>>> http://ag1le.blogspot.com/2012/05/morse-code-decoding-with-self.html >>>> >>>> >>>> My questions are related to NuPIC and how could I start testing whether CLA >>>> algorithm would perform better than the currently used Bayesian algorithm? >>>> >>>> The challenges I see after studying the NuPIC documentation & example >>>> code: >>>> >>>> 1) How to create encoder for building sparse representation from audio >>>> signals? (some ideas here: >>>> http://ag1le.blogspot.com/2014/05/sparse-representations-of-noisy-morse.html >>>> ) >>>> >>>> 2) If you teach NuPIC CLA to recognize Morse character set as sequence of >>>> "mark" / "space" bit patterns, how can you decode apparently random bit >>>> patterns from spatial pooler back to ASCII character set to be displayed >>>> to >>>> user? Does any of the existing classifiers allow users to create their own >>>> "codebook" (see >>>> http://ag1le.blogspot.com/2012/05/fldigi-adding-matched-filter-feature-to.html >>>> example using Kohonen Self Organizing Maps to build a codebook) >>>> >>>> 3) Does NuPIC CLA also recognize some common language patterns ("higher >>>> order sequences") that are typically used in normal ham radio contacts ? >>>> Or >>>> is there a need to chain multiple CLAs in some sort of hierarchy? >>>> >>>> regards, >>>> Mauri AG1LE >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> nupic mailing list >>>> [email protected] >>>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>>> >>> >>> >>> >>> -- >>> >>> Chris Albertson >>> Redondo Beach, California >>> >>> _______________________________________________ >>> nupic mailing list >>> [email protected] >>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> _______________________________________________ >> nupic mailing list >> [email protected] >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org -- Chris Albertson Redondo Beach, California _______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
