Hello Stefan,
Friday, April 29, 2016
Best regards,
Chris 2E0ILY mailto:[email protected]
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
>
|
