[TRLog] TRLOG radio control does not really work that well

[n6tr@teleport.com]

> Radio control with TRLOG is a sort of dilemma. It really is POOR if you set
> the baud rate to 4800, it just can't keep up. It can take up to 10 seconds
> to detect a change in frequency. If I set it to 2400 and 50 for the Kenwood
> Response Timeout it usually detects the change in 1 or 2 seconds. The
> problem with that is that Logic 5 now has to be set to that same incredibly
> slow rate and so if I want fast with one and slow with the other I have to
> keep switching them. Why can't TRLGO do better? I am running on a 300 MHZ P2
> with 192 Megs of memory. It obviously not my system. In any case, the same
> thing happens on a 500 Mhz P3.

There are a few facts that are distorted in the above paragraph.

TR polls the radios once per second.  It sends an ASCII message to
the radio asking for the frequency information and then receives the
data back from the radio.  As long as this process takes less than 
one second - the frequency display is updated once per second.

It typically takes 3 to 6 bytes of data sent to the radio to ask for
the frequency information.  In some cases - you also have to ask for
the mode information in a separate transaction.  The data comes back 
with a message that might be 12 or 16 bytes.  If you add all of this
up - a worst case exchange might contain about 50 bytes of total data.

50 bytes of data transmitted at 1200 baud will take about 50 milliseconds.
50 bytes of data transmitted at 4800 baud will take about 12 milliseconds.
50 bytes of data transmitted at 56K baud will take about 2 milliseconds.

All of these are less than one second - and all of them will appear
exacly the same to the person looking at the information on the screen.

MANY radios will not send frequency information back when asked for
it when the dial is being turned.  This is typically the reason that
the frequency display has long delays - as TR has no choice but to
show the last frequency returned from the radio until it gets an 
update.  If you are really seeing 10 second delays for TR to present
a new frequency (and the radio is just sitting in one place during
that 10 seconds) - then there is some other problem that I do not
understand at work.  This is not normal operation with Kenwood radios.

> I suppose it is the way the code works, polling the port, rather than a real
> Async protocol. Is that true, is this what I am stuck with?

A different mode is to have the radio send data to the program whenever
the frequency changes.  This might improve the response in the sub 
one second time periods - but I don't believe it would have any 
impact beyond a second.

> If so, I guess I will just live with it, AND pray that some day a Windows
> version of the program is created, for which I would be HAPPY to pay an
> upgrade fee.

Windows and this issue have nothing in common.

Tree

--
FAQ on WWW:               http://www.contesting.com/FAQ/trlog
Submissions:              trlog@contesting.com
Administrative requests:  trlog-REQUEST@contesting.com
Problems:                 owner-trlog@contesting.com
Feature Wishlist:	  http://web.jzap.com/n6tr/trwish.html