Since I almost always operate from a multi-op station, the NEXTBANDMAP
and LASTCQFREQ functions get a workout in CW contests. I've tried using
them in phone contests, but they don't seem to do anything. I even
tried to set one of CQ SSB MEMORY F? to the appropriate values. Are
these broken for phone? It seems like TR is expecting all phone
messages to be filenames.
These seem to be equally useful for phone, so it would be really nice if
there were some way to make them work there also.
I also wanted to add my input on how NEXTBANDMAP should work since I've
seen some discussion of it on the reflector. We almost always have
developed a fairly large bandmap when we move to a new band, so we want
to work the new multipliers first and then go on to the other stations.
My recommendation would be to set up a new configuration parameter that
could either be set up to work as the current feature does or in a
different way that gives new multipliers higher priority.
For example,
BANDMAP STN = ANY (current behavior)
BANDMAP STN = NEWMULT (prefer new mults)
The way I'd like to see the NEWMULT option work is that every time a new
multiplier appears in the bandmap, the NEXTBANDMAP feature will go to
the next new mult's frequency. This would continue until there are no
new mults in the bandmap on the current band, when it would start going
to the next unworked station that's not a new mult.
The downside to this is that when you get a packet spot for a station
that's already QRT, or you can't hear, or who has too big a pileup, then
you'll want to toggle back to current behavior (the QRT guy could be
deleted from the bandmap). Otherwise it will keep QSYing to the station
you can't or don't want to work right then.
-Mike, N7MH
--
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
|