I'm a telco engineer (known to be vague) - but here's my responses...
1. The existence of a WL server. I presume this is a requirement when
running M/M?
It depends.
A: Under a peer to peer arrangement-the one most documented-a server
doesn't exist. Instead it is basically used as the "master copy" of the
starting log so that all the fields are the same, etc. You will recall
in the docs that you setup your parameters on this master copy, then
OPEN a copy of that master log on each "involved" station - and then
save locally to each involved station.
B: With the development of the "internet logbook" feature/functions a
server does truly exist - and it's intended to be compiled on a *nix
machine with IP connectivity. In this case, many of the pass-through
features (bandmaps, etc) are sent from a client, to the server, who then
updates the remaining client peers.
See? It does depend. For the rest of this - we'll assume you are using
a peer to peer deployment - without the "internet logbook" functions.
2. Recovery after restart. I am intrigued and pleased by the WL design
that appears to (re)populate the local log when a position is
(re)started. I believe the implication of this is that every position
sees all QSOs/Mults even if one or more positions had to be restarted
during the contest. True?
Absolutely. When you reconnect to the network - the first thing
completed is a resync/merge so that the log on the newly joined client
reflects the complete log of the other networked stations.
3. Recovery of the WL server. Can someone please fill me in on how/if
the server can be restarted and recovered?
You truly don't need the "server" in a centralized database sense once
the contest is started. UNLESS it is the machine that the rest of the
peers connect to during network setup. Each client is manipulating
their local copy of the log - and synchronizing their peers. That's
really going to depend on how you manage the network - and your level of
paranoia. I cannot perceive a benefit one way or another - they are
peer to peer using windows networking anyway.
However (this is the one exception to #1 above)- if you ARE using the
"internet logbook" functions - the writelog server is installed as a
deamon (application) on the unix machine. You can kill and restart just
the writelog server application - and perhaps Wayne can fill-in the
results - but I think the clients would then have to reconnect. However
- you shouldn't have a problem with a Windoze hang - those don't happen
in unix :=) I suspect that's precisely why the internet logbook
features USE unix in the first place as their platform. The difference
now is that your clients can be WIDELY dispersed - no longer tied to
ethernet - just an Internet connection. Cool huh??
4. When a local WL dies and gets restarted, does it come up with the
band map it had when it died, a clean band map, or a band map that has
been updated with the events that occurred on the other positions during
its restart?
This is an issue to me too. If a peer to peer client dies - the bandmap
will restart clear - and only those updates that occur AFTER
reconnecting will be added to your bandmap. Saving the station
information in an access array could solve this - but would require a
major rewrite no doubt.
5. At any given local position can local rate and aggregate rate be
displayed? Or is it just one or the other?
I've not seen this occur for individual member stations - since the logs
are in sync - the rate reflects the overall log. Showing rate per
station might be an easy option to implement - but I'm not the one to
speak on that.
6. Can anyone relate operating a M/M or M/2 using WL to doing the same
thing with another logger such as TRLog or CT?
I would suggest a WL M/M M/2 can do MORE than the above. In the recent
SS, we used a third PC connected to display bandmaps (a lot of them) and
we could WATCH propagation happen. Having that station ALSO receiving
packet spots via UDPSend made that an even more useful tool. It also
gave visitors to the effort something to look at rather than bothering
the operators. It would give a contest effort manager - a place to get
real time data without interrupting the ops. I see MUCH value to that.
7. Is the Ethernet any more/less susceptible to RFI than alternative
such as a serial port daisy chain?
Provided your station is properly wired and the ethernet cabling is
properly terminated - you should be fine. I ran nearly 1KW on 40/80 and
roughly 500-800 on 10,15,20 with ethernet and had no problems - this is
something to confirm BEFORE a contest. :=) Serial port daisy chains are
kludgy. Ethernet can be wired or wireless - how much easier is that?!?
8. I see port choices of only COM1-4. My system has COM5 and COM6
configured. Can WL access these COM ports somehow?
Check the help files better... But INI settings can help you make your
higher numbered com ports appear in writelog by telling the ini file
that your CPU com5 is com1, cpu com6 is com2, etc. Read the docs on
this - it's in there, and clearly explained.
|