[Elecraft] Hypothetical New Product

[kevinr at coho.net]

Since its inception Elecraft has been on a quest.  The quest for the 
most user friendly, convenient, trail radio.  They have explored a 
variety of architectures along the way with a consistently enjoyable 
user interface.

They have eliminated almost all of the external connections to a 
transceiver: the paddle is attached, the battery is inside, and the 
antenna can be as simple as a BNC connected whip.  The last external 
link needs to be severed: the logging system.

Logging systems can be as simple as a 3x5 card and a stubby, golf pencil 
to a whiz bang laptop to voice recorder to a smart phone. But each of 
them requires me to input the data in some form. Why?  Why do I need to 
send my input to a chunk of memory when the transceiver already has the 
provision for text recognition?

As I send my information in response to the contact's information why 
can't the Elecraft CW decode algorithm provide that data in a stream to 
be parsed?  Pattern recognition can be used to scan the raw text stream 
and find: a call sign, RST, S/P/C, and a serial number.  Once each of 
these is parsed they can be tossed into a chunk of spare memory for the 
on board log along with a time stamp.

I think a few lines of screen real estate, a single (tap) button, and a 
largish (?) chunk of memory would allow for within the rig logging.  
Bring the rig home, hook up a USB cable, and log the rig's data to your 
logging database.

If the rig's CPU is stressed by this an addon board could be created 
with additional processing power.  Macros can be created for a variety 
of contest formats and allow for the recognition of DX call signs as 
well as the ones for North America.

My first rev would be to allow the user to hand log by hitting the 
log/no log tap button for the appropriate mode and allow user entry (and 
edit) via the paddles.  As I mentioned previously a few lines of screen 
real estate and the necessary chunk of memory are required for this, no 
extra processor cycles simply a few more subroutines.

The second rev requires a little bit of artificial intelligence (aka 
some form of regular pattern recognition). A daughterboard would take 
the raw text stream as input and parse out the logging data as it is 
trained.  As long as the Elecraft CW decode subroutine can provide 
decent text the 'recognizer' AI can start logging contacts.

I don't think the second rev is impossible or even all that difficult.  
Maybe by 2018??

    73,
       Kevin.  KD5ONS