Julian, G4ILO wrote: > > > > Sverre Holm-3 wrote: >> >> It is interesting to see the responses to my statement on the difficulty >> of machines copying CW better than humans. Although this is a little >> off-topic here, I hope we can have a short discussion of it anyway. >> >> First, the success of negative SNR communications methods such as >> Olivia,JT65, and PSK31, are evidence that a well-designed computer >> algorithm should perform better than a human. But it is on codes that >> have been designed for machine decoding. >> >> Second, 'better' may mean many things: faster, many QSOs in parallel, or >> - what I imply - at lower SNR and under difficult conditions with fading >> and interference. There is no doubt that a computer has much more >> capacity for speed and parallel decoding than a human. >> >> The steps that a good algorithm needs to do are something like this: >> - real-time frequency analysis and filtering >> - detect morse signal and lock on to a particular frequency >> - adaptive estimation of datarate and adaptive matched filtering for >> optimal detection >> - decoding of dashes/dots/spaces into letters >> - decoding into words >> >> The first steps are signal processing such as filtering, detection and >> adaptivity. See e.g. >> http://www.journal.au.edu/ijcim/jan99/ijcim_ar1.html for some ideas on >> the adaptive estimation. As a side remark, Coherent CW, was a way of >> avoiding the adaptation to variable rate and ease machine decoding, but >> it does not seem to be a success. >> >> I believe that it takes an extraordinary algorithm to lock onto a very >> weak signal reliably, but even more so to do the last and maybe even the >> second last step, and that this is where the similarity with speech >> recognition is largest. As an example, say that my call is a weak >> DX-call and I'm sending CQ de LA3ZA LA3ZA LA3ZA. On the receiver end you >> hear DA---, LA3-T, L-3ZA due to fading and interference. This is where a >> good operator is able to use a priori information on the syntax of a >> callsign, similarities between morse codes for various letters, and the >> three partial calls to piece this together to LA3ZA. >> >> I'm not saying this is not doable, only that it may take more than a >> month for a good programmer to do this, and maybe much more also. >> > > Weak signal modes like WSPR, JT65, MFSK etc work as well as they do and > can dig below the noise because they use different tones, rather than > tone/no tone as in CW. The timing of the signal elements is also precisely > known. > > Even with computer sent morse the program does not know the speed at which > it is being sent, so it has to work that out before it can start. The > vagaries of propagation then throw their spanner in the works, as the > decoding algorithm does not know if absence of a tone is a valid signal > element, or QSB. If you then throw in the imprecision of timing caused by > hand sent morse, then you can see the computer algorithm really has a hard > job to do. > > Computer morse decoding algorithms in use currently go no further than > assuming the tones are clearly distinguishable from the spaces and that > the timing of the elements are predictable. > > To improve the decoding performance would I think require the application > of artificial intelligence to get the computer to reasses what it first > thinks it receives in the light of what makes sense in the context of an > amateur QSO. This is pretty much what we do when we receive code by ear. > > First of all the human brain is probably more adaptive to irregular > element timing - left footed sending - than a computer algorithm. It > "learns" the guy's rhythm and uses that to decode what he is sending, > rather than the rigid symbol lengths of computer generated morse. > > Secondly the human brain uses context and knowledge to fill in the gaps > and make sense of what is received. If someone sends "QTH IS" you expect a > place name to follow. If you miss a couple of letters or what you got > doesn't look like a word you use your knowledge to work out what it would > be. > > It probably would be possible to write a computer program to do that but > it would be an incredibly challenging piece of programming that would need > an extremely keen mind and a great deal of time to accomplish. It would > probably be a PhD level project. >
I have probably less than a rudimentary understanding of the codec used to decode analog signals from a hard drive but maybe the PRML algorithm could be used here. I am sure the hard drive noise is significantly different but the signal to noise probably is not. It might be helpful to use a previously invented wheel (PRML:Partial Read Maximum Likelyhood) Also the hardware might be available or modifiable cheaply, after all every hard drive (millions) has a PRML codec involved in it's circuitry. PRML might be usable here at the first layer somehow. Tom Price WA6SUS -- View this message in context: http://n2.nabble.com/HRD-cw-copy-tp2195214p2201792.html Sent from the Elecraft mailing list archive at Nabble.com. _______________________________________________ Elecraft mailing list Post to: [email protected] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com
