MIME-Version: 1.0
In-Reply-To: <5723D581.1080403@posteo.de>
References: <1546137dc25-12a6-35ed@webprd-a101.mail.aol.com>
	<57237FB9.2060507@posteo.de>
	<5723D581.1080403@posteo.de>
Date: Wed, 4 May 2016 12:04:20 +0200
Message-ID: <CAC+C6w5Xf8LdSfFHUjWaAsqerwPJc-PGrfwLku3jy6dcBbdohg@mail.gmail.com>
From: Domenico IZ7SLZ <iz7slz.domenico@gmail.com>
To: "rsgb_lf_group@blacksheep.org" <rsgb_lf_group@blacksheep.org>
Subject: Re: VLF: EbNaut for QSOs, beaconing and grabbers (?)
Content-Type: multipart/alternative; boundary=001a114737586eff22053201590a
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

--001a114737586eff22053201590a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Stefan, and "EbNauters"

I like =F0=9F=91=8D your idea of this "beacon mode" that can be helpful to =
rise the
activity in EbNaut.

By the way, the critical point of this idea is that the system will be
mono-channel. Both sides (Rx grabber and Tx station) must have the
frequency very, very  close to the nominal in order to get decodes by an
unattended EbNaut-Rx session. As you known, "playing" with offsets can make
big differences with EbNaut.
Also multi access to the channel will be a problem,  but for sure not at
the beginning, with few operators.

My suggestion, for an initial activity,  is to have a grabber, like OPDS,
with a SL front-end that automatically exports  the recording wave-files.
The idea is to share these recording wave files with the community using
DropBox or other means.  So every operator, after its transmission,  can
attempt to decode itself by running EbNaut locally: he knowns already the
parameters used and he can try to fix the offsets, without waiting for the
grabber's operator job.  Note that this arrangement supersedes the
mono-channel and multi-access problems.

If a transmission is also announced, then also other operators can download
the files from these "grabbers" and make training on decoding procedures.
Local running of EbNaut-rx.exe with files already created, does not
requires frequency or timing accurancy at all. This really can increase
interest on that mode.

I think that this grabber  is not so complicated to do. It will be possible
to use SL recording function steered by the SL scheduler.
Maybe should be better to have some modifications in Spectrum Lab in order
to  include, in the header of the recordered wave file, also the callsign
of the Rx station. Modifications in EbNaut-Rx will be necessary to show the
callsign in the decoding page or log.

Thanks again Stefan for your activities on VLF.

73 all, Domenico iz7slz


On 29 April 2016 at 23:43, DK7FC <selberdenken@posteo.de> wrote:

> Hi VLF,
>
> Now, i'm not sure what the marority is thinking about VLF these days. Man=
y
> 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 th=
e
> most effective mode, at least on LF and VLF.
> On the other hand, it is complex to handle, maybe to complex for some. FF=
T
> 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, mayb=
e
> 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) ther=
e
> 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 2=
0%
> 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) (=3D defined frequenc=
y);
> 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 a=
nd
> 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 si=
ze
> 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 wit=
h
> 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
>

--001a114737586eff22053201590a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hello Stefan, and &quot;EbNauters=
&quot;<br><br></div>I like =F0=9F=91=8D your idea of this &quot;beacon mode=
&quot; that can be helpful to rise the
activity in EbNaut.<br>=C2=A0<br></div>By the way, the critical point of th=
is idea is that the system will be mono-channel. Both sides (Rx grabber and=
 Tx station) must
 have the frequency very, very=C2=A0 close to the nominal in order to get d=
ecodes by an unattended EbNaut-Rx session. As you known, &quot;playing&quot=
; with offsets can make big differences with EbNaut.<br>Also multi access t=
o the channel
 will be a problem,=C2=A0 but for sure not at the beginning, with few=20
operators.<br></div><div><br></div>My suggestion, for an initial activity,=
=C2=A0 is to have a grabber, like OPDS,=C2=A0 with a SL front-end that auto=
matically exports=C2=A0 the recording wave-files. The idea is to share thes=
e recording wave files with the community using=C2=A0 DropBox or other mean=
s.=C2=A0 So every operator, after its transmission,=C2=A0 can attempt to de=
code itself by running EbNaut locally: he knowns already the parameters use=
d and he can try to fix the offsets, without waiting for the grabber&#39;s =
operator job.=C2=A0 Note that this arrangement supersedes the mono-channel =
and multi-access problems. <br><br></div>If a transmission is also announce=
d, then also other operators can download the files from these &quot;grabbe=
rs&quot; and make training on decoding procedures. Local running of EbNaut-=
rx.exe with files already created, does not requires frequency or timing ac=
curancy at all. This really can increase interest on that mode.<br><br></di=
v><div>I think that this grabber=C2=A0 is not so complicated to do. It will=
 be possible to use SL recording function steered by the SL scheduler. <br>=
Maybe should be better to have some modifications in Spectrum Lab in order =
to=C2=A0 include, in the header of the recordered wave file, also the calls=
ign of the Rx station. Modifications in EbNaut-Rx will be necessary to show=
 the callsign in the decoding page or log.<br><br></div><div>Thanks again S=
tefan for your activities on VLF. <br><br></div><div>73 all, Domenico iz7sl=
z <br></div><div><br><br></div><div><div><div><br></div></div></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 29 April 2016 a=
t 23:43, DK7FC <span dir=3D"ltr">&lt;<a href=3D"mailto:selberdenken@posteo.=
de" target=3D"_blank">selberdenken@posteo.de</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><u></u>


 =20

<div bgcolor=3D"#ffffff" text=3D"#000000">
Hi VLF, <br>
<br>
Now, i&#39;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 &#39;even&#39; 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 &#39;grabber&#39; 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>&#39;beacon&#39;</b>. Definition (for example): starti=
ng
each hour on 1 or 2 channels (selectable, 1 or 2 or 1+2) (=3D 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&#39;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&#39;s then a bit like a grabber indicating the
transmitting station which QRSS mode must be choosen. <br>
<br>
Another one could be <b>&#39;QSO&#39;</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>
</div>

</blockquote></div><br></div>

--001a114737586eff22053201590a--