Message-ID: <5723D581.1080403@posteo.de>
Date: Fri, 29 Apr 2016 23:43:29 +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: <1546137dc25-12a6-35ed@webprd-a101.mail.aol.com> <57237FB9.2060507@posteo.de>
In-Reply-To: <57237FB9.2060507@posteo.de>
Subject: VLF: EbNaut for QSOs, beaconing and grabbers (?)
Content-Type: multipart/alternative;
 boundary="------------000708040500090305030800"
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.
--------------000708040500090305030800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi VLF,

Now, i'm not sure what the marority is thinking about VLF these days. 
Many OMs are in the background. I hope it is rather interesting then 
annoying, that VLF stuff :-)

When comparing EbNaut with other modes, we can see that it seems to be 
the most effective mode, at least on LF and VLF.
On the other hand, it is complex to handle, maybe to complex for some. 
FFT data must be exported by SpecLab, start times must be known exactly, 
as well as the frequency and 'even' the message length and the symbol 
length. The frequency stability must be extremely good.
But from a different point of view this makes the mode as flexible and 
effective as it can be. So it is no critisation at all, i just have 
ideas how to extend the usage so it becomes practicable for more 
stations, maybe also on LF/MF.

Now, for a comparison to other digital modes which allow to have a QSO 
(e.g. JT9) or running a beacon and a 'grabber' window (WSPR or OP32) 
there are pre-defined settings, like the start time (each even minute 
for WSPR) or the frequency range or the content.

*What i would like to have* (and maybe others too) is a special 
EbNaut+SpecLab+Script(s) system that runs periodically and writes and 
displayes the decode result in a txt file that can be displayed on a 
grabber site, just like the OPDS32.txt on my LF DX grabber.
That system should be easy to install for most of the operators here. It 
should run automatically in the background and should consume less then 
20% CPU power during decoding. A decode time of 10 minutes is no problem 
when it runs in the background anyway.

We could discuss and define different modes for VLF:
One mode could be *'beacon'*. Definition (for example): starting each 
hour on 1 or 2 channels (selectable, 1 or 2 or 1+2) (= defined 
frequency); 30s symbols (or 10s or 60s, selectable, must be stated on 
the grabber page); 6 characters (for a longer callsign like IZ7SLZ)
With such a pre-definition, there's no need for an announcement, which 
is the main difference between EbNaut and other modes. The result, which 
can be even checked for plausibility (filtering nonsense-callsigns) 
could be displayed like the OPDS32.txt results, showing date, time, 
message, SNR and further relevant data. A script (written by Markus) 
could automatically start the decoder, read the FFT data, search for 
results, display them in EBN.txt and delete the FFT data file then. The 
FFT input size could be limited to a small value so the decode time 
becomes short and the file size becomes small. With 30s and 6ch this 
takes 280 minutes, so a beacon transmitter station could run 5 hour 
sequences. It's then a bit like a grabber indicating the transmitting 
station which QRSS mode must be choosen.

Another one could be *'QSO'*, with 30 or 60s symbols and 15 characters, 
using a single channel, i.e. a discrete frequency. A bit like JT9 but 
with stricter limitations.

What do you think, Markus and Paul. Could it be helpful to rise the 
activity in EbNaut, maybe also on LF? Would someone of you provide the 
scripts or maybe a special decoder edition for that task?

73, Stefan

--------------000708040500090305030800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi VLF, <br>
<br>
Now, i'm not sure what the marority is thinking about VLF these days.
Many OMs are in the background. I hope it is rather interesting then
annoying, that VLF stuff :-)<br>
<br>
When comparing EbNaut with other modes, we can see that it seems to be
the most effective mode, at least on LF and VLF. <br>
On the other hand, it is complex to handle, maybe to complex for some.
FFT data must be exported by SpecLab, start times must be known
exactly, as well as the frequency and 'even' the message length and the
symbol length. The frequency stability must be extremely good.<br>
But from a different point of view this makes the mode as flexible and
effective as it can be. So it is no critisation at all, i just have
ideas how to extend the usage so it becomes practicable for more
stations, maybe also on LF/MF.<br>
<br>
Now, for a comparison to other digital modes which allow to have a QSO
(e.g. JT9) or running a beacon and a 'grabber' window (WSPR or OP32)
there are pre-defined settings, like the start time (each even minute
for WSPR) or the frequency range or the content.<br>
<br>
<b>What i would like to have</b> (and maybe others too) is a special
EbNaut+SpecLab+Script(s) system that runs periodically and writes and
displayes the decode result in a txt file that can be displayed on a
grabber site, just like the OPDS32.txt on my LF DX grabber.<br>
That system should be easy to install for most of the operators here.
It should run automatically in the background and should consume less
then 20% CPU power during decoding. A decode time of 10 minutes is no
problem when it runs in the background anyway.<br>
<br>
We could discuss and define different modes for VLF:<br>
One mode could be <b>'beacon'</b>. Definition (for example): starting
each hour on 1 or 2 channels (selectable, 1 or 2 or 1+2) (= defined
frequency); 30s symbols (or 10s or 60s, selectable, must be stated on
the grabber page); 6 characters (for a longer callsign like IZ7SLZ)<br>
With such a pre-definition, there's no need for an announcement, which
is the main difference between EbNaut and other modes. The result,
which can be even checked for plausibility (filtering
nonsense-callsigns) could be displayed like the OPDS32.txt results,
showing date, time, message, SNR and further relevant data. A script
(written by Markus) could automatically start the decoder, read the FFT
data, search for results, display them in EBN.txt and delete the FFT
data file then. The FFT input size could be limited to a small value so
the decode time becomes short and the file size becomes small. With 30s
and 6ch this takes 280 minutes, so a beacon transmitter station could
run 5 hour sequences. It's then a bit like a grabber indicating the
transmitting station which QRSS mode must be choosen. <br>
<br>
Another one could be <b>'QSO'</b>, with 30 or 60s symbols and 15
characters, using a single channel, i.e. a discrete frequency. A bit
like JT9 but with stricter limitations.<br>
<br>
What do you think, Markus and Paul. Could it be helpful to rise the
activity in EbNaut, maybe also on LF? Would someone of you provide the
scripts or maybe a special decoder edition for that task?<br>
<br>
73, Stefan<br>
</body>
</html>

--------------000708040500090305030800--