[Elecraft] Hypothetical New Product

David Gilbert xdavid at cis-broadband.com
Mon Jun 6 14:22:12 EDT 2016


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, kevinr at coho.net 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:Elecraft at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to xdavid at cis-broadband.com
>



More information about the Elecraft mailing list