Envelope-to: dave@picks.force9.co.uk
Delivery-date: Sat, 23 Apr 2005 15:46:19 +0100
Message-ID: <426A5F73.305@freenet.de>
Date: Sat, 23 Apr 2005 16:45:07 +0200
From: Wolf DL4YHF <dl4yhf@freenet.de>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: RSGB LF Group <rsgb_lf_group@blacksheep.org>
Subject: LF: Re: WOLF q values
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

(Sorry for having to send this through the reflector, but my reply to 
John W1TAG was considered "spam" two times)

Hi John,

A very good and important observation, thanks - indeed when the decoder 
restarts, it should restart just like the console application, and so 
should the "q" value. I will try to understand what causes this, most 
likely just as you expected : A variable which doesnt get cleared when 
starting over. The WOLF core was not originally designed to be called 
more than once, it uses some global variables which are only initialized 
once automatically.

Next plans are a "compare"-function for the received text, which can 
make an alarm bell ring (or something like that) to get the operator out 
of bed, a spectrum graph instead of the waterfall, a miniature frequency 
scale with numeric labels, and a few goodies like an automated RX / TX 
control which can "answer" a call when a pre-defined string has been 
received.

Best regards,
  Wolf  DL4YHF .

--------------------------------------------------
John Andrews schrieb:

Wolf,

One minor observation on the new version -- when the program recycles after
line 3168, it seems to keep building on the previous "q" (snr) values. Is
that intentional, or just a case of not clearing a variable?  The "jm" and
"pm" values change as if you were starting over, so I had expected that the
"q" value would reset as well.

John A.