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