[Elecraft] HRD cw copy

[Tom Price]

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.