Delivered-To: daveyxm@virginmedia.com Received: by 10.50.237.98 with SMTP id vb2csp199597igc; Tue, 11 Mar 2014 11:24:54 -0700 (PDT) X-Received: by 10.194.1.242 with SMTP id 18mr598249wjp.22.1394562292577; Tue, 11 Mar 2014 11:24:52 -0700 (PDT) Return-Path: Received: from post.thorcom.com (post.thorcom.com. [195.171.43.25]) by mx.google.com with ESMTP id k2si2135498wiz.21.2014.03.11.11.24.52 for ; Tue, 11 Mar 2014 11:24:52 -0700 (PDT) Received-SPF: neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) client-ip=195.171.43.25; Authentication-Results: mx.google.com; spf=neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) smtp.mail=owner-rsgb_lf_group@blacksheep.org Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1WNQtE-0005s3-Fp for rs_out_1@blacksheep.org; Tue, 11 Mar 2014 17:54:56 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1WNQtD-0005ru-Ru for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 17:54:55 +0000 Received: from mout1.freenet.de ([195.4.92.91]) by relay1.thorcom.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WNQtB-00040T-Mt for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 17:54:54 +0000 Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout1.freenet.de with esmtpa (ID dl4yhf@freenet.de) (port 25) (Exim 4.80.1 #4) id 1WNQtA-0001N1-DK for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 18:54:52 +0100 Received: from localhost ([::1]:39898 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.80.1 #4) id 1WNQtA-0006Xa-8h for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 18:54:52 +0100 Received: from mx11.freenet.de ([195.4.92.21]:50366) by mjail2.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.80.1 #4) id 1WNQq9-0003HY-Vh for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 18:51:45 +0100 Received: from blfd-4d08ef88.pool.mediaways.net ([77.8.239.136]:3212 helo=[192.168.178.21]) by mx11.freenet.de with esmtpsa (ID dl4yhf@freenet.de) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (port 465) (Exim 4.80.1 #4) id 1WNQq9-0001ni-K1 for rsgb_lf_group@blacksheep.org; Tue, 11 Mar 2014 18:51:45 +0100 Message-ID: <531F4D30.6030701@freenet.de> Date: Tue, 11 Mar 2014 18:51:44 +0100 From: wolf_dl4yhf User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: In-Reply-To: X-Originated-At: 77.8.239.136!3212 X-Spam-Score: -0.0 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Domenico, At the moment, there is only a subtle difference in the way the center frequency is measured (it uses interpolation between the center bin and its neighbours). The difference is neglectable unless the tones fall 'right between two FFT bins'. But there will be further refinements soon. When finished, I will document them in my modified sourcecodes (the current one doesn't have the interpolation algorithm enabled). Actually, as tested by DL3ZID recently, there seem to be cases where the interpolation *degrades* the decoding process, for reasons I don't fully understand yet ... maybe a bug in my algorithm, or maybe a problem with the principle itself :o) [...] Content analysis details: (-0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [195.4.92.91 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dl4yhf[at]freenet.de) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: cbf9d9751ac5f32708197d03fa6d8d74 Subject: Re: LF: WSQ2 new version uploaded Content-Type: multipart/alternative; boundary="------------050104040404040701090408" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false This is a multi-part message in MIME format. --------------050104040404040701090408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Domenico, At the moment, there is only a subtle difference in the way the center frequency is measured (it uses interpolation between the center bin and its neighbours). The difference is neglectable unless the tones fall 'right between two FFT bins'. But there will be further refinements soon. When finished, I will document them in my modified sourcecodes (the current one doesn't have the interpolation algorithm enabled). Actually, as tested by DL3ZID recently, there seem to be cases where the interpolation *degrades* the decoding process, for reasons I don't fully understand yet ... maybe a bug in my algorithm, or maybe a problem with the principle itself :o) More later, 73, Wolf . Am 10.03.2014 23:27, schrieb ing.lindo: > Good evening Wolf and all, > Wolf, can you briefly explain differencies in algorithms of ZL2AFP > and DL4YHF decoders? > Thanks in advance. > > 73 Domenico, iz7slz > > Sent by Saturn 3S.90 with okitex > > -------- Original message -------- > From: wolf_dl4yhf > Date:09/03/2014 11:49 PM (GMT+01:00) > To: rsgb_lf_group@blacksheep.org > Subject: Re: LF: WSQ2 new version uploaded > > Hi Michel, > > Ok, thanks for testing, and nice to hear the synthesizer 'drive' works > properly again. > > > You wrote: >> Re: LF: WSQ2 new version uploaded >> >> - According to me, sentence "/Select another comport to turn off >> PTT/" is wrong and confusing. >> > > Maybe the intention is to emphasize 'after selecting another COM port, > the PTT is initally off" because that's what the function calls in the > PTT dialog window, after "OK", are doing. > >> The new serial port, if any, is not saved, therefore the correct port >> number has to be set in setup.txt >> The serial port is opened at launch time if the Synthesizer checkbox >> is already checked. Sometimes it's better to >> open the port just before outputing data and release it when done, >> sometimes not ( ie bluetooth serial port) >> > So we will have the option "leave the serial port open" or "close > after switching from TX to RX" added in the configuration. > IMHO, 'setup.txt' should describe the synthesizer hardware but not the > port to which it is connected (on a particular machine). Here, for > example, windows has the bad habit to assign different COM port > numbers for the same hardware (an old 'Prolific' USB<->RS-232 > adapter), depending into which USB port / hub / etc it is plugged : > "COM4 today, COM5 tomorrow" :o) > > 73, > Wolf . > --------------050104040404040701090408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Domenico,

At the moment, there is only a subtle difference in the way the center frequency is measured (it uses interpolation between the center bin and its neighbours). The difference is neglectable unless the tones fall 'right between two FFT bins'. But there will be further refinements soon. When finished, I will document them in my modified sourcecodes (the current one doesn't have the interpolation algorithm enabled).
Actually, as tested by DL3ZID recently, there seem to be cases where the interpolation *degrades* the decoding process, for reasons I don't fully understand yet ... maybe a bug in my algorithm, or maybe a problem with the principle itself :o)

More later,
  73,   Wolf .




Am 10.03.2014 23:27, schrieb ing.lindo:
Good evening Wolf and all,
Wolf, can you briefly explain differencies in algorithms of  ZL2AFP and DL4YHF decoders?
Thanks in advance.

73 Domenico, iz7slz

Sent by Saturn 3S.90 with okitex

-------- Original message --------
From: wolf_dl4yhf
Date:09/03/2014 11:49 PM (GMT+01:00)
To: rsgb_lf_group@blacksheep.org
Subject: Re: LF: WSQ2 new version uploaded

Hi Michel,

Ok, thanks for testing, and nice to hear the synthesizer 'drive' works properly again.


You wrote:
Re: LF: WSQ2 new version uploaded

- According to me, sentence "Select another comport to turn off PTT" is wrong and confusing. 


Maybe the intention is to emphasize 'after selecting another COM port, the PTT is initally off" because that's what the function calls in the PTT dialog window, after "OK", are doing.

The new serial port, if any, is not saved, therefore the correct port number has to be set in setup.txt 
The serial port is opened at launch time if the Synthesizer checkbox  is already checked. Sometimes it's better to 
open the port just before outputing data and release it when done, sometimes not  ( ie bluetooth serial port)

So we will have the option "leave the serial port open" or "close after switching from TX to RX" added in the configuration.
IMHO, 'setup.txt' should describe the synthesizer hardware but not the port to which it is connected (on a particular machine). Here, for example, windows has the bad habit to assign different COM port numbers for the same hardware (an old 'Prolific' USB<->RS-232 adapter), depending into which USB port / hub / etc it is plugged : "COM4 today, COM5 tomorrow" :o)

73,
  Wolf .


--------------050104040404040701090408--