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