Message-ID: <5092A514.7030303@iup.uni-heidelberg.de>
Date: Thu, 01 Nov 2012 17:36:36 +0100
From: =?ISO-8859-1?Q?Stefan_Sch=E4fer?= <Stefan.Schaefer@iup.uni-heidelberg.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <508D92BE.2040500@broadpark.no> <508ED047.1000504@broadpark.no> <CAHAQVWPFQdJQxMtkvzOvGZ-SbzGk3WTptmvMqDzBqpECjzjpgQ@mail.gmail.com> <508EEDA9.7070905@princeton.edu> <50901CB0.2040405@princeton.edu> <50917D09.2030908@princeton.edu> <509299E8.7010608@princeton.edu>
In-Reply-To: <509299E8.7010608@princeton.edu>
Subject: Re: LF: Soundcard issues
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Joe,
Am 01.11.2012 16:48, schrieb Joe Taylor:
> A few words for those reporting "too much audio" on input to WSJT-X.
>
> On my development system the same input level is required to make both 
> WSPR and WSJT-X happy.  Likewise on my shack computer.  For example, 
> see the screen shot posted at
> http://physics.princeton.edu/pulsar/K1JT/WSJTX_WSPR.png
>
> Could it be that those who report having to move audio level sliders 
> far downward are using 24-bit soundcards, and their drivers are 
> sending the low 16 bits (via portaudio) to WSJT-X?  I do not presently 
> have another explanation.  I do not find any level discrepancies 
> here.  Obviously, I cannot test hardware I do not have access to.
See this image for comparison: 
https://dl.dropbox.com/u/19882028/LF/WSPR%20vS%20WSJT-X%20audio.jpg

A difference of roughly 50 dB. Same input source for both programs, 16 
bit soundcard. Direct-x input at WSJT-X.
I guess the difference is not caused by the older WSPR version which 
works perfect here which even decodes my own TX signal which must have 
100000000000000 dB SNR ;-)


> Perhaps I should put in a digital attenuator to handle this issue?
A good idea. Maybe some kind of AGC, that checks the average signal 
levels and, if necessary, attenuates in 10 dB steps. Otherwise it is 
difficult for strong stations (or local stations) to cover a wide radius 
(i.e. number of possible QSO partners) without making local QSOs impossible.

>
> Nobody has yet sent me a file that, when opened, produces the result 
> "15P6715P67WCV".
1611 10 1 0.0 1416.36 0.00 15P6715P67WCV

1611 10 11 -0.2 1433.94 0.00 15P6715P67WCV

1611 10 32 -0.1 1450.48 0.00 15P6715P67WCV

1611 10 7 -0.1 1469.62 0.00 15P6715P67WCV

1611 10 -2 -0.1 1487.20 0.00 15P6715P67WCV

https://dl.dropbox.com/u/19882028/LF/121101_1611.wav

r2711 !!!!!!!!!!!!!!!!!!!!!


More for you:
See https://dl.dropbox.com/u/19882028/LF/non.jpg
Signal of DF6NM, which didn't decode.
Not only a non decode, but there was not even shown a text in the box 
for 16:12 UTC and there was no wav file generated!


Another example:

Again DF6NM in JT9-1
https://dl.dropbox.com/u/19882028/LF/non2.PNG
No decode but text in the box and this wav file: 
https://dl.dropbox.com/u/19882028/LF/121101_1616.wav


There is no difference between the normal and quick decoder settings, 
only non decodes from DF6NM. Timing is accurate as visible on the screen 
grabs. The decoder need now less than 30 seconds at +-50 Hz tolerance to 
run, mostly arround 10 seconds on the Win XP PC.


Maybe that helps?!


73, Stefan/DK7FC