Message-ID: <558EA358.80701@posteo.de>
Date: Sat, 27 Jun 2015 15:21:28 +0200
From: DK7FC <selberdenken@posteo.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: <8D27C7D3E7D6748-14A8-F71B3@webmail-vm149.sysops.aol.com> <558D8FEC.2090102@posteo.de> <7D39EA36066C485998744D9E994DAC52@White> <558DC2A1.2040608@posteo.de> <BD38778B266F46A4A54BF6832E171D3D@White> <F3FEB0DD301D485985A15A1AB9975AAF@White>
In-Reply-To: <F3FEB0DD301D485985A15A1AB9975AAF@White>
Subject: Re: LF: Heidelberg remote MF receiver
Content-Type: multipart/alternative;
 boundary="------------080702090203030606050005"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

This is a multi-part message in MIME format.
--------------080702090203030606050005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello Markus,

Am 27.06.2015 14:12, schrieb Markus Vester:
> - WSPR: Last night, 21 of my low-power WSPR transmissions were decoded 
> simultaneously by DK7FC/p and DK7FC. On average, the /p receiver had 
> a 5.67 dB SNR advantage. For my direction, the receive loop and the T 
> antenna seem to have performed similarly.
> Today between 11.08 and 11:24 I sent some more SNR sequences with 
> higher power (0.1 W EMRP), expecting a higher SNR difference in the 
> lower daytime background noise. However half of the transmissions were 
> not decoded on either grabber, and those that were picked up by both 
> showed only a small advantage. This is probably due to the strong QRN 
> from flashes from a nearby thunderstorm, which for some reason 
> are heavily affecting WSPR decodes. It might help to use effective 
> noise blanking in the SpecLab instance which is feeding WSPR. Anyway 
> if the statics happen to ease off I will attempt another daytime 
> comparison later today.

I have now arranged VAC3 and a second WSPR-2 instance, appearing as 
DK7FC/PNB (portable, noise blanker). The QRN is extreme now!!! It would 
be very interesting to compare both WSPR instances now.

Now, better explained:
-The Raspi sends the vorbis data stream via WLAN to the web.
- SpecLab is reading the stream directly, generates the upper 
spectrogram of the grabber page and feeds the stream in stereo mode to 
VAC1.
- Another SpecLab instance reads the stream from VAC1 (reading from the 
Raspi stream would mean another client for the Raspi, leading to twice 
the CPU load, which is impossible) makes the frequency conversion (474.2 
kHz "dial") and SSB/USB filter and feeds the output to VAC2
- The first WSPR-2 instance (DK7FC/p) reads the input of VAC2
- All other normal spectrograms (QRSS-30...) are reading from VAC1
- Now that's new: Another SpecLab instance reading from VAC1 again, 
preparing for WSPR, f-conversion, filter PLUS NB!, feeding to VAC3
- A second WSPR-2 instance reading from VAC3, appearing as DK7FC/PNB

Help, now the thunderstorm is coming closer!!!!! The grabber is just white!

73, Stefan

--------------080702090203030606050005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Markus, <br>
<br>
Am 27.06.2015 14:12, schrieb Markus Vester:
<blockquote cite="mid:F3FEB0DD301D485985A15A1AB9975AAF@White"
 type="cite">
  <title></title>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <meta name="GENERATOR" content="MSHTML 8.00.6001.23588">
  <div><font face="Arial" size="2">-&nbsp;WSPR: Last night,&nbsp;21 of my
low-power WSPR transmissions were decoded simultaneously by DK7FC/p and
DK7FC. On average,&nbsp;the /p receiver had a&nbsp;5.67 dB SNR advantage. For my
direction, the&nbsp;receive loop and the T antenna seem to&nbsp;have performed
similarly. </font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">T</font><font face="Arial" size="2">oday
between 11.08 and 11:24&nbsp;I sent&nbsp;some&nbsp;more SNR sequences&nbsp;with higher
power (0.1 W EMRP), expecting a higher SNR difference in the lower
daytime background noise. However&nbsp;half of the transmissions were not
decoded on either grabber, and those that were picked up by both showed
only a small advantage. This is probably due to the strong QRN from
flashes from a nearby thunderstorm, which for some reason are&nbsp;heavily
affecting WSPR decodes. It might help to&nbsp;use effective noise blanking
in the SpecLab instance which is feeding WSPR. Anyway i</font><font
 face="Arial" size="2">f the statics&nbsp;happen to ease off I will&nbsp;attempt
another daytime comparison later today.</font><br>
  </div>
</blockquote>
<br>
I have now arranged VAC3 and a second WSPR-2 instance, appearing as
DK7FC/PNB (portable, noise blanker). The QRN is extreme now!!! It would
be very interesting to compare both WSPR instances now.<br>
<br>
Now, better explained: <br>
-The Raspi sends the vorbis data stream via WLAN to the web. <br>
- SpecLab is reading the stream directly, generates the upper
spectrogram of the grabber page and feeds the stream in stereo mode to
VAC1. <br>
- Another SpecLab instance reads the stream from VAC1 (reading from the
Raspi stream would mean another client for the Raspi, leading to twice
the CPU load, which is impossible) makes the frequency conversion
(474.2 kHz "dial") and SSB/USB filter and feeds the output to VAC2<br>
- The first WSPR-2 instance (DK7FC/p) reads the input of VAC2<br>
- All other normal spectrograms (QRSS-30...) are reading from VAC1<br>
- Now that's new: Another SpecLab instance reading from VAC1 again,
preparing for WSPR, f-conversion, filter PLUS NB!, feeding to VAC3<br>
- A second WSPR-2 instance reading from VAC3, appearing as DK7FC/PNB<br>
<br>
Help, now the thunderstorm is coming closer!!!!! The grabber is just
white!<br>
<br>
73, Stefan<br>
</body>
</html>

--------------080702090203030606050005--