Hypothetical New Product

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

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[David Gilbert]

Either you tend to make some really basic QSOs with little QRM and lots
of S/N, or you have an unrealistic perception of CW decoding and pattern
recognition.  I think you'd end up with a high percentage of busted log
entries.

Besides, how much sense does it make to invest all that engineering to
autolog CW when it does nothing for SSB?  I'm primarily a CW op myself,
but for portable operation if the rig has SSB capabilities I'm likely to
want to use it ... meaning I'd still need to rely on some other
mechanism for logging.

Dave   AB7E



On 6/5/2016 6:39 PM, [hidden email] wrote:

> 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
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]