[Elecraft] OT: Want USB Output Keyer Info.

[David Woolley (E.L)]

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>