Earvin, I'm saying the code would read the log and show me the stations near the frequency. In that case, I would set N to be something like 3600 and I would see in a band-map all the stations worked near that frequency (perhaps +/- 10 KHz) in the past hour or less.
I figured Tlf should work with rigctl and model 2, but my one attempt didn't work and it seems my contest prep time is always limited by other things and so I never tried again. And I did download pydxcluster some time ago, but I usually do contests unassisted and I forget to try it out when doing other operating as cqrlog as a cluster built in. Pierre On Wed, Aug 12, 2015 at 4:56 PM, Ervin Hegedüs <airw...@gmail.com> wrote: > Hi Perre, > > On Wed, Aug 12, 2015 at 09:38:15AM -0400, Pierre Fogal wrote: > > 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. > > may be I don't understand something, but Tlf knows to handle > this. First, most RIG has 2 VFO (and many memory's). If I hear a > selected station, I just press A=B key on RIG, and moving away, > if I don't hear the callsign. If I hear, then I press CTRL+A, > which add the callsign to bandwith, and it stays till N secods > (N is 900 in default in Tlf). > > So, it works - but as I wrote, may be I don't understand > something. > > > 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. > > that's clear - but how do you connect it with Tlf? Do you want to > read the log periodically? > > > 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. > > That's true, > > > 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. > > I'm sorry, but I don't understand this above - how relates this > to Python, and Tlf bandmap? > > Anyway, in last year, I've made two contest in paralell: JI-DX CW > and Gagarin Memorial (Russian contest). I've run two Tlf instances, but one > RIG. I've configured Tlf RIG as like this: > > RIGMODEL=2 > RIGPORT=127.0.0.1 > > in both instance, and run rigctld. That worked as very well. > Cluster config must be defferent on the two instance, any other > features worked (eg. netkeyer...) > > > 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. > > Take a look at this: > > https://sourceforge.net/projects/pydxcluster/ > > may be that will be helps to you. And please share your > experience with us :). > > > 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! > > good to hear :) > > > 73, Ervin > > -- > I � UTF-8 >
_______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
