Re: LF: The return of EbNaut for Dummies

[Markus Vester <markusvester@aol.com>]

Hi Luis,

your last-mentioned decimator and FFT settings are fine.

I think the confusion is only about the term "width". The 438 uHz is the width of one single FFT bin, i.e. the inverse of the 38 minute time span.

What Stefan meant is the total width of all bins in the spectrogram, which should theoretically be identical to the decimated samplerate
 44100 / 1536 = 65536 * 0.000438 = 28.71 Hz
However there is a catch: SpecLab only shows and exports the middle half of the spectrum, for the purpose of hiding the outer rolloff region of the decimation filter. Thus in your case the number of exported bins is only 32768, and the total observation width is 14.35 Hz (i.e. +- 7.18 Hz around the center frequency).

Don't let yourself be confused by the Windows filesystem timestamps. An export file is written at the end of the first integration period, but file access will still be left open and locked, awaiting further data. When the next FFT is ready 10 minutes later, SpecLab will detect that the maximum filesize limit (1 kB) would be exceeded, so it closes the first file, and the new data is written to the next file. That is why the timestamp of the first file will be increased by 10 minutes.  

Best wishes,
Markus



-----Ursprüngliche Mitteilung-----
Von: VIGILANT Luis Fernández <luis@vigilant.es>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org>
Verschickt: Di, 11. Sept 2018 13:42
Betreff: RE: LF: The return of EbNaut for Dummies

Hi Stefan

 

Thank you for the detailed explanation. I prefer to understand the process rather than getting a working .usr

So, excuse me again for dumming again  J

 

All understood about the length and relation to FFT windows time (length) in SL. Width was un unknown parameter for me

And I’m afraid the problem is about the width:

 

>> Choose the FFT width and length to suit your settings. The width is maybe 10 * 1/(symbol length) or more

Lets say 1Hz minimum for a 10 sec symbol leght, right ?

 

So, in the FFT configuration window the only way to get >1Hz(1.3Hz) for “Width of one FFT-bin” is to reduce decimation to 1

and then set FFT length to 32768 to get some “FFT window time (length)”. But then, the indows time is just 743ms

which will not cover the length of the message at all

 

I’m stucked here. Can’t get >width with 30 minutes FFT lenghts. I’m using 44.100Hz sample rate L

 

The FFT input type is “Complex ith internal frequency shift”. But even using “Real FFT starting at 0Hz” doesn’t improve much

Decimation at 1536 and FFT length 65535 produces “Width of one FFT” at 438uHz and FFT windows time 38 min. So this time

good length but small width

What I’m doing wrong ?

 

73 de Luis

EA5DOM

 

De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org] En nombre de DK7FC
Enviado el: lunes, 10 de septiembre de 2018 18:57
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: The return of EbNaut for Dummies

 

Hi Luis,

Am 10.09.2018 17:47, schrieb VIGILANT Luis Fernández:

The fact of getting windows timestamped files which really start at a

different time and no aparent indication of when they end ….. doesn´t help at all

Well, the FFT settings must be so that you cover enough width (in Hz) and length (in seconds). The necessary width depends on your symbol length. The length is mentioned in the FFT settings register card (FFT window time). Choose a rectangular window for EbNaut decodes.
Convert the txt files into wav using Markus tools. Load the wav file in the EbNaut decoder and press RUN. Then you will see the start time of the file. The end is start time + length. Simple, isn't it? :-)

A new txt file is generated in the interval of the scroll time (Spectrum (1) ) register card. Usually 30 minutes is fine, or even 1 hour on VLF. Then you get a file each 30 minutes. If the FFT length is longer than 30 minutes. Your FFT length should be 30 minutes longer than the transmission length, just to avoid an incomplete set of data in a txt file.

Choose the FFT width and length to suit your settings. The width is maybe 10 * 1/(symbol length) or more.

Is there any way of “fast” EbNaut when signals are strong ?

I think there are no limits, you can run 0.1 second symbol length. But usually it is used for weak signals and stable paths.

 

I really don’t know what to test next.

Send me your .usr file and the EbNaut settings you want to try.

73, Stefan

May be to run ebnaut_tx in test mode, which just changes the phase every symbol length

And then, analyze the recorded file with a different tool to determine if this phase changes are there ? Can this be easily done ?

 

73 de Luis

EA5DOM

 

PS: Congratulations for your amazing test with the guard rails. And yes, this is much much harder than EME ! J

 

De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org] En nombre de DK7FC
Enviado el: viernes, 07 de septiembre de 2018 22:10
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: EbNaut transmission test in LF

 

Hello Luis,

Another hint: Try to use 4K19A and a shorter message, like EA5 or so. Use long symbols, like 10 seconds or longer. Then, timing is less critical and you may get a decode and can tune to the best Eb/N0 and find out what the timing offset it. It would guess it is a timing problem.

73 Stefan

Am 07.09.2018 13:36, schrieb VIGILANT Luis Fernández:

Hi Domenico

 

Sorry, I’m not transmitting this weekend. Very stormy weather here, so the wires are down

I will notice in the reflector any transmission in advance. But first want to confirm that all is working ok

So that was the goal of yesterday test

 

Yes, the XOR is AFTER the 1/10 divider, and working at the final frequency 137485 Hz

 

Your auto-decoder is a great tool. EbNaut is quite tricky for average use and needs a lot of details to care about

Of course the reward is great when you get decodes with miserable signal levels. There is never free lunch ! ;-)

 

73 de Luis

EA5DOM

 

De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org] En nombre de Domenico IZ7SLZ
Enviado el: viernes, 07 de septiembre de 2018 13:18
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: EbNaut transmission test in LF

 

Hello Luis,

 

thanks for sharing your experiment. My auto-decoder  https://www.qsl.net/iz7slz/  is already retuned for your transmissions.

 

BTW QRM is large here in the morning time (urban location). I will try to catch your signal later in the night.

 

At least the decoder is detecting the carrier but may be there is no proper phase modulation or probably other failures

What I’m doing wrong ? Can anybody decode the message from the file ?

 

 I also suspect some issues on modulator circuit. Of course the XOR gate is following the /10 divider, is it?

 

Good luck.

 

73 all,

Domenico/IZ7SLZ

 

 

 

On Fri, 7 Sep 2018 at 11:38, VIGILANT Luis Fernández <luis@vigilant.es> wrote:

Hi LF EbNauters

 

I have been building a disciplined Rx for LF, based in a GPS LO at 120KHz and a NE602 downconverter to 17KHz

Then feeding the signal to the soundcard, also disciplined with 1pps from the same GPS

 

At Tx side a GPS LO at 1374850 Hz divided by 10 provides 0.1Hz steps at LF. Then an XOR gate is used for

EbNaut modulation from the DTR of  a COM port under Windows. The PA is just a mosfet driver (mic4452 AT 12v)

Just about 100mW to antenna but good enough to get a 20dB S/N in my Rx 7Km away

 

Stability looks pretty good and also phase modulation as seen in SL spectrogram. Also monitoring phase changes

with the SL plot display window. So, yesterday I tried an EbNaut transmission with the following setup

 

Coding: 8K19A

CRC 16

Symbol period: 1s

Characters: 6          Transmission time: 9.3 minutes

Transmitting at minute 00 and 30 every hour

 

I got the FFT files from SL and converted them to WAV files. The configuration file (SR) included the corrected sample rate

of the soundcard as well as decimation , FFT length and center frequency

 

Attached is a WAV file starting at 16:22 which should contain the transmission started at 16:30 untill about 16:40

 

The rawsym graphic shows a clear peak centered in frequency, but I haven’t been able to get a decode other than “******”

At least the decoder is detecting the carrier but may be there is no proper phase modulation or probably other failures

What I’m doing wrong ? Can anybody decode the message from the file ?

BTW, I have used a list length of 47274 and also 141823, but nill L

 

73 de Luis

EA5DOM