Date: Sun, 1 May 2016 11:37:11 +0100
From: Chris Wilson <chris@chriswilson.tv>
Organization: Gatesgarth Developments
Message-ID: <1184663691.20160501113711@chriswilson.tv>
To: DK7FC <rsgb_lf_group@blacksheep.org>
In-Reply-To: <5723D581.1080403@posteo.de>
References: <1546137dc25-12a6-35ed@webprd-a101.mail.aol.com> <57237FB9.2060507@posteo.de> <5723D581.1080403@posteo.de>
MIME-Version: 1.0
Subject: Re: VLF: EbNaut for QSOs, beaconing and grabbers (?)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

Hello Stefan,

Friday, April 29, 2016


Best regards,
 Chris  2E0ILY                          mailto:chris@chriswilson.tv


 I  am surprised these ideas haven't elicited more responses. I am in
 awe  of Ebnaut and SpecLab, but find them both daunting applications.
 I  would  love to see what i can receive on VLF, but unless something
 akin  to  what  you are suggesting appears I feel I would be a bit (a
 lot,  probably)  out  of my depth with both applications. I hope some
 clever  people can find the time and desire to create something a lot
 more  user friendly to set up as an operating system for VLF. If they
 do  I  would,  for  sure, be keen to give it my best shot. Thanks for
 bringing  this  subject  up,  I hope it will generate some input into
 building a simpler to set up package :)

>    
>  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
>