Re: [Tlf-devel] Fwd: Bandmap.

[Pierre Fogal]

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 <address@hidden> 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