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 <airw...@gmail.com> 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 >
_______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
