Please pardon me for bumping my own thread, but I hope this update might be helpful to someone who might find it in the archive one day - and it also gives me the chance to say a big THANK YOU to all those who have contributed their ideas.
The project is now at the stage where I have a prototype that works as well as I can make it work, and I'm waiting for a chance to let B have a go at it.
The project has evolved a bit since the earlier postings.
The big issue was always the question of how to interface the Morse key to the Z. At a sending speed of 20 words per minute, a dot lasts for 60 milliseconds. That's quite a short time, and the time measurement is obviously critical for correct decoding. Any form of direct hardware interface would have to record event times to much better than that accuracy. When I realized that Qt didn't inlcude the original event timing in the event data structure, I decided I needed something more precise. If the event doesn't record the time it happened, the best you can do is to record the time when it came *out* of the event queue. It seemed a bit too much to hope for the needed accuracy that way.
As previously mentioned, I tried the MFJ-461 Morse decoder. It's a neat little box that's designed to be held up to a radio receiver loudspeaker, or connected directly to the audio output jack. Kudos to the manufacturer here: it expects an audio signal, not a direct connection of a Morse key. After looking at the circuit diagram, I decided where to connect the key, and emailed them asking for any advice. Their reply was prompt and helpful and as a result they are in ny good books - but in the end, I had to conclude that the decoder was better suited to the interpretation of automated Morse than to hand-generated.
So I introduced a new element - a PIC development board that was surplus to requirements at $DAYJOB, and which they were happy to donate.
The PIC board now has the Morse key connected to it, and I wrote a program for it which debounces the key - a very necessary step, as it turned out - and sends to its serial port a series of ASCII characters that encode just the timings between key-up and key-down events. That's all the PIC does - it does the timing measurement of 'up' and 'down' events, and it knows nothing about Morse code.
The serial output from the PIC then goes via a 3-way cable to the Z, and also to my desktop machine. The Z is running a program which listens to the serial input, and decodes the timings to generate the ASCII characters corresponding to the Morse. Every time it sees a full stop, it speaks (via flite) what it's collected. My friend who is the retired ship's radio operator (that is, my guinea-pig) is able to use it and to speak long and complicated sentences.
The desktop machine receives the same input, and also speaks it in the same way. However, it adds value in that it displays an oscilloscope-like trace of the Morse input - the idea of which is that I can tune the decoder to the hand of the operator, if necessary. The desktop machine is just a debugging aid - not part of the final system.
I've learned lots from this project, and it isn't over yet. Perhaps the biggest lesson, though, is this:
1. It's not too hard to decode Morse, if you don't mind a few errors. The human brain is very good at interpreting text where some characters are in error. I've now seen quite a bit of software that does decode Morse, but "a few errors" are to be expected.
2.. But if you want to feed the result to a speech synthesizer, those few errors become intolerable and can wreck the output. The speech synthesizer isn't intelligent, and it needs very clean data. That's the hard bit.
Cheers
John
