Re: VLF: EbNaut for QSOs, beaconing and grabbers (?)

[DK7FC <selberdenken@posteo.de>]

Hi Domenico,

Hmm, ok, but that would still keep the special character that someone has to do something manually each time to get a result. And this is the main difference to other modes like OP32 or WSPR. In OP32 or WSPR, anyone can just start to TX without announcements and there will be displayed results without the manual decoding procudure.
BTW i like that 'work', i like to convert the txt files in Markus' software and i like to tell the EbNaut decoder the symbol length and start time offset :-) This will of course be done in the future for any special experiment. Ah and i also like the SpecLab help file, just want to tell that to avoid misunderstandings ;-)
Another thing that must be considerated is the psychological effect!! I am sure that one of the reasons why WSPR is so popular is the map and database, where everybody can see who is QRV, who has 'worked' whom, who has the better RX or TX station, who suffers or profits from special locations. When i left decodes at FR5ZX on MF and everyone can see it on the map, the OMs begin to think "I want that too!", it is the same when  IZ7SLZ appears in the OPDS decode list of TF3HZ or VY7MAE!
If you just generate a local decode that is not published for a longer time on a place where many people are watching, then the good results becomes forgotten, maybe not in the mind of the TX and RX station but propably in the mind of eventual future TX stations or RX stations. All in all it's the motivating factor.
I a private mail you wrote that you think it will take 5...7 years until there is more activity on VLF. That may be right. But i think if you make such a tool available, similar to OPDS32.txt on grabber pages, this time could become shorter.

What i thought basically is a script (i don't know how to do it for Windows PCs) that works similar to OPDS32. It ready exported FFT data text files and displays the results in the txt file which can be published.
In contrast to OPDS32, the start time must be exactly choosen by the TX and RX station. But on VLF, where symbol lengths of a few 10 seconds are used, 0.5 second is not so critical too. But it is no problem to get the needed accuracy in timing and frequency. The frequency is no problem at all because, if a TX station has a drifting signal, there is no chance anyway. So this is the standard, 8270.1 kHz means 8270.10000 Hz, not 8270.098561 Hz + 0.1 mHz/hour (of course all measured within the observed bandwidth).
So then we would need some pre-definitions, like WSPR or JT9 or even CW has too, to avoid the need for announcements. One definition would be the frequency (1 or 2 or 3 selectable channels, discrete frequencies). Another the time stamp, for example each hour or each 30 minutes, even if a transmission take 4 hours. And of course the number of characters. You will like to have 6 characters i guess :-) Ah and the symbol length, maybe defined to 30s and 100s or so. Must be discussed. And it should be possible to edit these numbers in a config file.
It should be possible to tell the EbNaut decoder via a script "Use that file, look on that frequency and that symbol length and that time offset for 6 characters and write the results into your log file. Then look on that (other) frequency and do the same again". If this is done every hour, it is no big problem for the PC i think.
In a last step the log file could be filtered for the decodes. If we define that it must be a callsign, like in OPDS32, we can filter out any decode that doesn't match the profile CNCC or CCNCC or CCNCCC (C=character, N=number) and so on. So, '5Q34=0' would be filtered. As you suggested, it would even be helpful to use the callsloc list from OPDS32, so the locator is already known and more information is available in the txt file on the grabber.
It would be a challenge open to everybody, ready to see a surprise for both operators, on the RX and TX side :-)

73, Stefan

Am 04.05.2016 12:04, schrieb Domenico IZ7SLZ:

Hello Stefan, and "EbNauters"

I like 👍 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. 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