Morse Code Input

[jfr]

I'm looking into the possibility of writing an app for the Z that would take Morse Code input, and speak the resulting text.

The beneficiary would be a 92-year-old friend who has been a life-long radio ham, and who through a series of strokes has lost the power of speech.

Ideally, it'd be possible to connect a real Morse key to the Z by some means, so that he could use his own morse key.

I've found links to this sort of stuff via google, but unfortunately the links are dead. There are references to a sourceforge project called zmorsed, and I've seen a reference (without a link) to "How to connect a real Morse key via the audio connector". That reference said it was possible, but didn't go beyond that. The sourceforge links all lead to an "Access Denied" response. (Yes, I was logged in at the time.)

My plan would be to use flite for the speech synthesis, driven by the program that I'd write. I've proved out the speech synthesis part, but it's the Morse Code input that's lacking.

I'd be really grateful if anyone could help out here. For starters, does anyone have the zmorsed source?
Or any other code for interpreting morse code? Ideas for connecting the morse key?

Cheers

John

[InSearchOf]

http://morseall.org/
I found this...

Late

[Da_Blitz]

what model Z were you thinking of using? if its one with usb hostthen get a usb printer adaptor and butcher it (sorry thats "creative restructuring") into somthing smaller that clips onto the Z gives you 8 bits of IO

attaching it to the audio port would be good. not that hard to do ethier. the remote control for the Z (inline headphone jack) uses this principle with a voltage divider. for you it would depend on how the keyer works

your distro of choice will make a huge diffrence. if you can get one with the uinput or user space input device driver, that way you can insert keycommands as a keyboard instead of having to do some hackery. means it will work on X and the console as well

here are some options
http://sourceforge.net/projects/cwtext/ takes asscii and outputs morse code as asscii or sound (8bit wav) not exacttly what you are looking for however if you were building an interface around morse code then this part could help, in conjunction with a shell you wrote
http://users.skynet.be/ppc/xcw/ X11 morse code input daemon
http://www.qsl.net/pg4i/linux/cwdaemon.html listens on a udp port and spits out morse code when a packet arrives
http://morseall.org/ THIS IS WHAT YOU WANT. it has support for using a mouse (ie usb ) and using 2 or 3 buttons, one for tic the other for tac so you can achive faster rates

so those are some links that might be handy, for futre refrence i used freshmeat.net to look everything up however i did that knowing the morseall package exsisted

if you dont have a cxx00 for use in this project then i can show you how to hook up the keyer to the Z over the serial port, its harder and you will have to do some processing yourself to decode the results but nothing too hard, the hardest bit is how to wire it so it dosent blow the Z

just a side note is this so they can use the Z as a terminal as well (ie like the blind do) or is this a speach only thing. you imply loss of voice but if they are using a keyer then i am guessing they have limited control over thier fine moter skills. just thinking you could add some stuff to allow them to switch between using your app to talk and controlling the PC

anyway back on topic, if you do use a usb mouse then you have to tell X or whatever the display/input thing is to not use your mouse as an input, then commect to it directlly (/dev/input/mouse) this varies from distro to distro and IMHO your best option is most likly a stripped build of OZ with a 2.6 kernel. YMMV

[jfr]

Hey, thanks folks! That's a lot of input - I'll check it out.

To answer a couple of Da Blitz's questions:
I was planning to get the thing working on my C3000, and then if it does work, look for a 2nd hand Z on ebay. So I don't yet know what the final target machine would be.
And the reason for the morse key isn't mobility, it's that as a radio ham he's an excellent morser (if that's a word...). That's also why hooking up a real morse key would be an advantage.

Cheers, and thanks

John

[Da_Blitz]

sounds good then, in that case i would recomend the audio port, more versitile and can be plugged into many machines then

[ztep]

I think that the the audio port is the best option for you. The remote hardware is well know, so if you tell as how the Morse key you want to use works (both electrical and mechanical) we can help you to design the apropiate interface between the audio port and the morse key.

One problem that I found is that if you want to use the audio port for interface the morse key you need an external speaker because the internal is silenced.

[Da_Blitz]

are you using a 2.4 or 2.6 kernel. i belive i had the speaker working as well as the headphones after using alsamixer on the cmdline (speaker=yes)

and i thoght that trick would never come in handy , if you do do it under OZ then you have to disable the audio routing script that runs everytime a headphone device is plugged in or removed

but im up to helping you with this project. i have always wantede to get a braile terminal and hook it up to my box. you never know when that may come in handy

[jfr]

are you using a 2.4 or 2.6 kernel. i belive i had the speaker working as well as the headphones after using alsamixer on the cmdline (speaker=yes)

and i thoght that trick would never come in handy , if you do do it under OZ then you have to disable the audio routing script that runs everytime a headphone device is plugged in or removed

but im up to helping you with this project. i have always wantede to get a braile terminal and hook it up to my box. you never know when that may come in handy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=154022\"][{POST_SNAPBACK}][/a][/div]

WARNING: Long reply!

Long, because of the offers of support. What a great community this is. I hope with this post to put you fully in the picture, as it currently stands.

Gosh - thanks folks for those messages of support. I'll surely need it if this project is to be completed.

To Da Blitz: For now, I'm experimenting on my C3000, which has the original ROM and kernel. It works pretty well, and I never quite summoned up the courage to go for the upgrades...

I should perhaps say at this point that I don't know whether this project will actually be a goer, because there are ifs and buts still to be resolved.

The main 'if' is that I don't know whether the intended recipient still has the power to do morse - if speech is affected, then maybe morse (also language-related) could be. Also, I need to check his motor skills.

But before that (because I don't want to raise hopes if I then can't deliver), I now want to put together a simple prototype which I can test on another morse-proficient friend. If that works, then I'll feel confident about approaching B (the intended recipient).

So for now, it's the prototype that I'm working on.

BACKGROUND

I looked at the morseall project, and I was highly impressed. I don't think I can use that code, though. It's designed for sip-and-puff morse, where dots and dashes are separate actions (as opposed to the same action for different durations), and it assumes pretty fixed timings. Morse from a regular key is I believe more variable than that.

I've found (through the links you all supplied, and others that I googled) a lot of material on Morse for the disabled. There's a lot on supplying Morse solutions for all sorts of access needs, but a lot of that assumes that the person using the system will have to learn Morse to start with. The difference in my case is that I'm trying to design a system for someone to whom Morse is already a first language, and at the moment I'm assuming he still has manual motor skills.

I found quite a few university research papers via Google (none with code, alas), but they describe the problems of reading conventional hand-produced morse. The algorithms they propose are adaptive - they continually adjust for changes in sending speeds - and they also attempt error correction on the fly. The error correction is of the nature: This isn't a legal Morse character, so let's see which character it's closest to, and assume that.

There are papers that propose neural nets as the solution. I don't think I'm quite ready for that...

PROGRESS

The speech synthesis part is the really easy bit. I downloaded flite, and it worked out of the box. So whatever program I come up with, I will be able to run flite from the program, with the text on the command line.

So at the moment, the plan is to write an app for my C3000 that will accept the Morse just by tapping on the screen, and then speak it. If I can do that, then I'll feel confident enough to approach B and ask whether I should go further.

Which means I'm currently busy writing code based on the algorithm descriptions in the research papers, for basic Morse recognition.

The project plan therefore looks something like this, and the whole project will fail if any step fails:

1. Demonstrate speech synthesis from the command line - DONE.
2. Check out recognition algorithms - DONE.
3. Produce prototype for beta-testing. Prototype will accept Morse input by tapping the screen with the stylus, and will speak the result. User interface will be abysmal. Morse recognition algorithm will be good, and that's the difficult bit.
4. Get friend (a retired ship's wireless operator who doesn't yet know that I've appointed him for this task) to perform beta test using screen-tapping interface.
5. Approach B to see whether he thinks he could use a more polished version of the prototype. Expectations are raised at this point, which is why the plan doesn't involve contacting B earlier.
6. Choose which Zaurus to deliver the solution on, and buy it on Ebay. Yeah, thanks Sharp for pulling the plug just as it was all going so nicely. But at the moment, I'm thinking that maybe a 5500 will be able to cope, and there are several on offer at affordable prices. B is a friend though, so if the project gets this far, price won't be a problem.
6. Develop the more polished version, including a hardware interface for his preferred Morse key. (This part will need to be fleshed out if the project gets that far.)
7. Deliver system.

For now, step 3 is current. It involves no new hardware and it will work if step 4 does.

This project plan has evolved thanks to the collective input from forum members. I think the ball's in my court at the moment, and I'll let you know how it goes. Meanwhile, ideas are still very, very welcome!

Cheers

John

[Da_Blitz]

nothing i own has its originol firmeware , actually i briced my router an hour ago so i need to fix it the old fasioned way with tftp , still works as a switch however. thats why i always have 2

decoding morse code dosent seem that hard, an adaptive algorithim wouldnt be too hard to write ethier, with or without funky maths

another option you have is to get a hp 1910 or 1930, there is a very mature port for that device and its a very small machine, i saw one on ebay for $4 the other day because its 3 to 4 generations old and was low speced when it came out. think about it. the other option is any other hp pda as the linux port is very good and nearlly identical to what we use

my version of the tit or tap algo is to look at the width of the current pulse and compare it to the last, if its longer its a dash if its shorter or within a set variation for timing then its a dot. basically you only check to see if its a dot, if it isnt AND teh pulse is longer than is acceptable for the dot then its a dash otherwise ERROR

of course the parameters for how close and acurete the pulse widths have to be is a diffrent matter but i would say that you stick to the aproch that thi timing gets smaller the more dots and dashes per second (normailsed of course as they take diffrent ammounts of time) the more you tighten up the margin for errer, so that when they type slow there is less chance of a mistake and when they speed up it compinsates for that

hardware wise you are looking at a headphone jack, a 500mW speaker andat least one microswitch. along with the usual heatshrink and wire

[jfr]

Da Blitz - thanks again for the ideas. They're all being squirrelled away...

ztep - thanks to you for the offer of help connecting a Morse key. I've no idea yet what key it might be, but if the project gets that far, I'd like to come back to you! I certainly don't think I could manage it on my own, because my hardware knowledge of the Z is, well, not exactly impressive...

I do now have some progress. On the desktop machine I now have a little system - a mixture of Tcl and C++ - in which I can input Morse via the left mouse button, and get it spoken. Given that I'm a Morse veteran of just a couple of days, it seems encouraging that it can understand my input :-)

Next comes the port to the Z, with the primitive GUI design. This may take a while, but once it's done I can try the beta test.

Cheers

John

[speculatrix]

could you use a usb numeric keypad and use that as a simple control pad for your friend? he could use up/down/left/right to select letters and words which the zaurus could speak.

if you need something more custome, get a usb to parallel port converter and provide a very simple control panel that way?

[jfr]

could you use a usb numeric keypad and use that as a simple control pad for your friend? he could use up/down/left/right to select letters and words which the zaurus could speak.

if you need something more custome, get a usb to parallel port converter and provide a very simple control panel that way?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=154553\"][{POST_SNAPBACK}][/a][/div]

Now, that's an idea. I still want this to be a Morse device because of his life-long familiarity with Morse, but maybe it'd be possible to open up a numeric keypad and connect a Morse key to one of the buttons. It'd solve the interface problem.

The only drawback might be the timing information. A numeric keypad probably wouldn't scan its keys all that often, in which case the sending rate would be restricted.

The parallel port sounds good too - if there's a suitable driver for it. I'm afraid that's not one of my good areas. Anything that can be made to generate a Qt event ought to do the trick.

Added to the ideas list. Thanks!

[speculatrix]

this is a bit of a long shot, but for quite a while I've been musing about writing a simple zaurus game (qtopia based for sharp/cacko) and made a start before I started reading this thread.

I suddenly realised this morning that I could take what I started, and cut it down a bit and give you a really simple application for the Z which is simply four buttons on the screen, you could then hack in the code to do the morse or whatever... i.e. it's a get-you-started skeleton application. Hmmm. Let me attach the bare-bones program I wrote and you can see what you think.

No prizes for guessing what game I trying to write!

save this  [ Invalid Attachment ]  and rename, just drop the .zip extension, it's a linux/arm binary, run it on the Z.

[jfr]

this is a bit of a long shot, but for quite a while I've been musing about writing a simple zaurus game (qtopia based for sharp/cacko) and made a start before I started reading this thread.

I suddenly realised this morning that I could take what I started, and cut it down a bit and give you a really simple application for the Z which is simply four buttons on the screen, you could then hack in the code to do the morse or whatever... i.e. it's a get-you-started skeleton application. Hmmm. Let me attach the bare-bones program I wrote and you can see what you think.

No prizes for guessing what game I trying to write!

save this  [ Invalid Attachment ]  and rename, just drop the .zip extension, it's a linux/arm binary, run it on the Z.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=154610\"][{POST_SNAPBACK}][/a][/div]

Hey, thanks for that kindness! It's much appreciated, and the program does run, even though it complains about missing files:
/home/QtPalmtop/i18n/en/libsl.qmid
/home/QtPalmtop/lib/libqsfepj.so, libkke.so.1

I'm not so sure about using it yet, though that's mainly because I'm already using one of my other apps as a base. But I'd like to keep it in reserve, because my GUI design in Qt is no more sophisticated than just painting stuff directly to a pixmap and then updating the screen from it.


BUT: In the meantime, I seem to have hit a problem that may be severe. I was merrily coding away, assuming without thinking about it that a Qt event would have a timestamp field, telling me when the event actually occurred to some reasonable level of precision. I'm now dismayed to find that they don't. So if my app gets interrupted during Morse input, and events are forced to stay in the queue for a while, I'll have no means of getting back the original timings. And in Morse, those timings are quite small and obviously critical. Even if the app doesn't get interrupted, updating the screen to print what's being received looks as though it could cause trouble.

I guess I'm just going to have to carry on and see how it goes in practice, but any words of wisdom or comfort would be appreciated. Like, is there something obvious that I've failed to see, here?

[Capn_Fish]

I was browsing Hackaday, and found this:

http://home.att.net/~jacksonharbor/palm.htm

It seems to be somewhat related, so I thought I'd post it.