[Elecraft] OT: Want USB Output Keyer Info.

[David Allred]

David:

>  So one approach is to implement USB HID in the device firmware.

I believe this is available as a chip or as part of other chips.

>  However, modern operating systems have to have clearly defined  
> software driver interfaces, both above and below, so there should be  
> a keyboard driver interface and a USB low level interface, so a  
> morse code decoding USB driver could be interposed between the two.

Maybe so, but I think we can skip that step. Writing driver can be a  
real pain in the butt. If the Morse can be parsed (as is done in some  
software) and passed to a generic USB keyboard chip (in place of the  
key strobe scan output), the keyboard drivers already in the computer  
OS will treat the Morse character the same as a keyboard key press.

This would take care of the driver problem and use what is already  
available. For instance, Mac OS X includes generic drivers that  
support all Open Host Controller Interface (OHCI) bus controllers. In  
general, third-party developers do not need to write drivers for the  
USB family. This is likely also the case for Windows.

Anything that looks like any flavor of USB keyboard just works.

> Another approach would be to use the hooks used to support Chinese,  
> etc., input and actually feed the key input as two extra keys on a  
> standard keyboard, or the keyer output as one.

This would probably work, but not all computer OSs have implemented  
Unicode. And even when they do have system level support, plenty of  
applications don't have Unicode support.

>  More generally, it is possible for applications on windowing  
> systems to generate keyboard event; the only possible problem is  
> that they need to grab input from the real input device whilst the  
> main application has normal input focus.

This works, but requires deep understanding at the driver level.  
Peter, W8PS, has done this to add key-click sounds to our modern quiet  
keyboards.
<http://sustworks.com/site/prod_keyclick_overview.html>
Also, unlike the OCHI drivers, different versions would have to be  
written for each OS.

> One disadvantage of a computer side driver is that the keyboard will  
> not be able to talk to the BIOS.

Not really a problem at the driver level since the OS takes care of  
the hardware interface.

If I had to build a Morse to USB device from scratch (like I've really  
got the time), I would find a way to get one of the keyer chips, such  
as WinKeyer, to pass its output to Morse reader microcontroller, such  
as the MFJ, which would then talk to a generic USB keyboard chip.

Most of the work may have already been done as a thesis project: see  
my post to George, W6TC.

Thanks for your comments.

David
N1VU

      |  J. David Allred
      |
      |  P H O T O N
      |
      |  allred at photoninc.com
      |  Photon, Inc.
      |  617-661-9046
      |  www.photoninc.com



On May 23, 2008, at 3:47 AM, David Woolley (E.L) wrote:

> David Allred wrote:
>>> It is possible that someone who wanted to play with USB  
>>> implementing microcontrollers might do the software on the keyer  
>>> side of the USB
>> True. It's been done many times.
>
> Something like this might well appear as an amateur radio project,  
> as virtually all of it can be done with a single, flashable, chip.   
> You just need suitable firmware.
>>> and interface using the USB HDI keyboard protocol
>> This is the missing piece. But, can a USB I/O implementation also  
>> include the keyboard protocol. The drivers are different, but is  
>> this feature an easy hardware or software addition? Does the USB  
>> chip already include latent hardware of software?
>
> USB hardware implements a low level protocol which is just about  
> communicating data.  There are higher level protocols for many  
> different devices and classes of device.  One of those is Human  
> Interface Devices (I wrote HDI by mistake, originally), which  
> include keyboards.  So one approach is to implement USB HID in the  
> device firmware.  However, modern operating systems have to have  
> clearly defined software driver interfaces, both above and below, so  
> there should be a keyboard driver interface and a USB low level  
> interface, so a morse code decoding USB driver could be interposed  
> between the two.
>
> Another approach would be to use the hooks used to support Chinese,  
> etc., input and actually feed the key input as two extra keys on a  
> standard keyboard, or the keyer output as one. It is possible that  
> these input method editors would not receive events in a  
> sufficiently timely manner to correctly decode them.  More  
> generally, it is possible for applications on windowing systems to  
> generate keyboard event; the only possible problem is that they need  
> to grab input from the real input device whilst the main application  
> has normal input focus.  It might, therefore, be possible for morse  
> decode software applications to be put into a keyboard emulator mode.
>
> One disadvantage of a computer side driver is that the keyboard will  
> not be able to talk to the BIOS.
>
>> Also, we aren't average (I hope). I recently changed the chip in my  
>> ancient MFJ-495 to bring it up to the current firmware version.  
>> Improved software can be a chip-change away.
>
> A chip change for a device like this would be essentially a complete  
> replacement of the device.
>
>>> you cannot represent key up, or more generally, multiple key  
>>> presses, with morse code.
>> For the present application, it's not an issue. My friend would be  
>> able to enter plain text into a document faster with a keyer than  
>> he does
>
> It's true that you could simply generate paired down and up events.
>
>
>>> That's not particularly a good idea, because you lose peer review  
>>> of the suggestions and people may waste time by telling you the  
>>> same thing over and over again.
>> I agree. But, one man's peer review is another man's waste of  
>> bandwidth.
>
> I know there is a significant lobby that all postings on the list  
> should have a strong component making explicit reference to Elecraft  
> hardware or business policies, but the charter (see sig) actually  
> says "and more general topics related ham radio".  As this topic is  
> about exploiting skills that are mainly limited to radio amateurs  
> these days (and is particularly prevalent amongst Elecraft users),  
> it seems to me that it is on topic, and some people find the most  
> interesting thing about mailing lists is what they learn from  
> threads that are near the edge of the charter (or drift off charter).
>
>
>
> -- 
> David Woolley
> "The Elecraft list is a forum for the discussion of topics related  
> to Elecraft products and more general topics related ham radio"
> List Guidelines <http://www.elecraft.com/elecraft_list_guidelines.htm>