I think Guy is on some rather fundamental point and I agree with all of what
he says, but I believe he has understated the degree of the issue.
The TRLog core function is outstanding. Some of this is personal
preference, but in my book its operational aspects lead the logger industry.
Auto fill on S&P from band map, notion of modes of S&P vs run, SS exchange
entry, myriad settings and PFkey capabilities, the list can go on for a
looooong while.
But core function, in my view, is becoming less important than a few other
things.
PLATFORM. Over the years I have become rather used to the application
richness and overall toolset of Windows or even Linux for that matter. TRLog
is the last DOS program I (try to) run anymore. TRLog sometimes can be made
to run successfully in a DOS session under old windows (95 or 98 but not
XP), but I think we all would say that most seem to have problems and prefer
to play it safe and run TRLog in a native DOS environment. That means I (or
the poor SOB who has the task of making it all work) have to reacquaint
myself with config.sys, autoexec.bat, path statements, and other DOS arcane
aspects, every time it's time to get QRV for the next M/M effort. Also,
the native DOS environment pretty much rules out some pretty nifty assist
applications (greyline, etc). The platform just doesn't have any legs.
ARCHITECTURE. How long will we continue to have COM and LPT ports? Most
new laptops are without them now. Even the venerable floppy is now sold as
an option by Dell. Reliability, logical error detection and correction,
etc., on COM/LPT are pretty much up to the application to worry about. Each
does it to some extent. None do it well. We need a TRLog that is running at
a higher level in the operating system hierarchy so it can benefit from a
ton of code written elsewhere. Use ethernet (TCP/IP) instead of COM ports
for networking in a multi. Use USB ports (or other, more current) instead
of COM/LPT where ethernet is not appropriate. TRLog is on the wrong
architecture for what it's trying to accomplish.
NETWORKING MULTI DESIGN. The weaknesses of the underlying platform and the
overall architecture of the computers demanded by TRLog expose some of
TRLog's major design deficiencies. Losing a serial port in a M/M pretty
much implies you've just lost the multi network. Lose the network long
enough (small minutes in a full-bore M/M) and TRLog proudly announces "data
may have been lost." Loss of data implies that each station position is
now on its own - the logs don't match. You might get the network up
shortly, but there will be Qs that are only recorded at the position which
made them. Thus, if, for example, you chose to run 20 meters on position A
in the daytime and D at night, you can easily develop the case where A and B
have differing ideas of dupes and differing ideas therefore of mults and
associated band maps. Not good if that position change means 20 just went
into multiplier (vs run) status. What's the op to think when others keep
telling him DUPE?
TRLog provides no way to put Humpty Dumpty back together again. There is no
means by which all positions can re-synchronize logs when the network comes
back up. TRLog has no macro-level network recovery design whatsoever, and
that becomes glaring in the face of the aforementioned architectural
inadequacies (COM/LPT) and concommittant failure scenarios that TRLog
currently has to deal with. TRLog is between a rock and a hard place.
So, what to do? Well, I've looked at WriteLog and it has a very robust
recovery design, uses ethernet, implements telnet so I don't have to run
Wintelnetx and chew up another pair of serial ports. It runs along side
other windows applications some of which can help in a contest. It can be
configured to give me a command console in a M/M complete with graphs.
BUT... It currently can't hold a candle to TRLog's core function - the
operational aspects TRLog provides. At least IMHO. Perhaps some day it will
and the story will be over.
I'd like to see an effort to make core TRLog work well on Windows XP. Then
totally rewrite the networking aspects of TRLog to utilize modern
architecture. Then provide a recovery design for M/M based on that
platform.
This is not necessarily a "windows port" of TRLog. I'd be happy with TRLog
running its current display layout in an XP window, complete with arcane
CTRL and ALT keys, etc., and leave it at that. I have never seen the
internal structure of TRLog, so I have no idea whether there are any natural
segments that can be kept more or less intact. Again, the operational engine
is 1st rate. Could that be encapsulated and then work on the periphery?
If no one or group wants to step up to this or something similar, one by one
TRLog users will move elsewhere. We, for I would count myself in that
group, would initially put up with less operational function to get gains
elsewhere, and work to get the operational aspects made more robust.
Unfortunately, I think it the case that improving operational function is
much easier to do than reworking the basic structure of the logging platform
itself. This is no small task! But every large journey begins with but a
single step.
73,
Gary W2CS
> -----Original Message-----
> From: trlog-bounces@contesting.com
> [mailto:trlog-bounces@contesting.com]On Behalf Of Guy Olinger, K2AV
> Sent: Thursday, February 20, 2003 7:41 PM
> To: trlog@contesting.com
> Subject: [Trlog] Watching an old friend slowly die
>
>
> ... an experience I would not wish on a hated enemy.
>
> But this is what is happening with TRLog.
>
> I'm used to TRLog. I like TRLog. I'm a fan of TRLog. I don't want to
> switch. But...
>
> ---
>
> If the inane inexplicable sometimes, sometimes not problems running
> TRLog under Windows in a dos box aren't solved...
>
> If we don't get a windows-based translation of com x to
> joes.computer:1158 or some such device to substitute for increasingly
> scarce and unreliable physical com ports in serial daisy chain
> configurations, so that we can use any modern TCPIP connection for our
> network connections...
>
> If we don't solve timing/exclusive access problems using a dos
> box/command prompt...
>
> ---
>
> Our TRLog multi-multi setup becomes more problematic every time out.
> The serial port daisy chain is now ALWAYS the LAST thing we get
> running, and the FIRST thing to fail and require a computer change in
> the middle of the contest. We have had serial port daisy chain issues
> to overcome in ALL of the last five outings. We have had as many
> Windows/daisy chain/serial port contest affecting failures as all
> other types of failures combined, including amp, antenna, and radio
> blowups.
>
> If we switch loggers in the multi-multi setup, I will have to change
> to the same logger at home so I will show up at the multi operation
> trained and versed in the new logger, ready to go.
>
> It won't matter how many cute features or configurabilities TRLog has
> (and some of them are my absolute favorites), I will have to abandon
> it because Windows, IP networks, exclusive control, etc, etc, are not
> being dealt with.
>
> I'm not arguing who should do what or why. But the doc is spending his
> time on hair color and skin tone and manicures while the patient is
> dying of congestive heart failure.
>
> I'm losing an old friend. And I don't want to.
>
> Does anybody care?
>
> Should I just give up and move on?
>
> 73, Guy
> K2AV
>
> _______________________________________________
> Trlog mailing list
> Trlog@contesting.com
> http://lists.contesting.com/mailman/listinfo/trlog
>
|