[Tlf-devel] Fwd: Bandmap.

[Pierre Fogal]

Hello Ervin, Tomasz,

The problem I find is that after having cruised up and down a band several times, I basically "forget" the location of worked stations on the band.  So, I will hear a station I can work, and then wait for the station to ID.  With some operators, this can take awhile ;-)  So, if somehow I can see that in the past N minutes (N can be defined as it is now) I worked AB1CD on 14.240 as I approach 14.240 then I'll know not to wait too long as I likely worked him already.

My thought initially on the Python add-on, was a simple gui or ncurses display that gave the current frequency and mapped worked calls before and after it.  I figured Python, because that's mostly what I use these days (unless working on the hardware level with a need for speed) and Python makes it sooo much easier to deal with parsing of strings.  I had once quickly  tried to run tlf using rigctld and the generic rig def (2?) but wasn't able to get that working and haven't gone back to it.  I'm thinking this would be the cleanest way to add secondary codes accessing the rig information.

The ideas pointed to by Fred would also do most if not all of this, I think. 

Also on the Python front, I have written a number of scripts (using Ipython) to do post-contest scoring for some unsupported contests that are important to me, like the RAC Canada Day and Winter Contests, NAQP, IARU, and now IOTA.  

As for N1MM logger ... I haven't actually used it since 2004.  I could use it here at home, but I can't justify it while on NA-008 as I would have to dedicate a pc to it. So, it's tlf for the win!

73,

Pierre VE3KTB

On Tue, Aug 11, 2015 at 2:05 PM, Ervin Hegedüs <address@hidden> wrote:

Hi Pierre,

On Tue, Aug 11, 2015 at 10:06:10AM -0400, Pierre Fogal wrote:
> If you are looking to gauge interest, then a band-map that displays worked
> calls around your frequency as does N1MM logger would be a great feature, a
> boon to S&P operation.

sometimes I use N1MM (only from my club). Basicly, I don't like
this feature in both direction. If we will touch this part of
code of Tlf, may be it could be good to disjoin the directions:
- op could configure, if he types a callsign (and do something
  which triggers the add function, eg. tune the VFO up/down
  minimum 1kHz), then callsign will be added
- op could configure, if Tlf uses rigctl, and it gets the freq
  which exists in bandmap, then the callsign (which is on that
  freq) will be added back to callsign field

More features, if we will touch the code:
- bandmap columns scrolling: now there are 3 columns for bandmap,
  but on most contest, these are very few for the number of
  competitors. It could be good, than Tlf follows the freq of
  TRX, and detects that the freq leaves the freq of last station
  in first column, then shifts columns to left
- mark the nearest stations on bandmap with different background
  (or something else), or if there isn't any station between N
  kHz, then mark the previous and next nearest (with other sign)

Other ideas are welcome.


> I was thinking of trying to write something like
> that as an add-on Python program.

How do you think about it? What do you think about the "add-on"
program?

(Otherwise, I'm a big Python fan :))

> I saw a stat that suggested that less than 20% of operators in a contest
> ever call CQ.  I call, but not as much as I do S&P given the "little
> pistol" nature of my station(s).   So, I would guess that any assistance on
> the S&P side would help many users. :-)

yes, bandmap is a big help. I've used that on WAE, and Tlf showed
the number of QTC's, what a station gave me - that was a _very_
big help. Idea came from DJ1YFK (thanks Fabian :)).


73, Ervin


--
I � UTF-8