Hi Stefan, Markus, EbNaut
Thank you for the detailed explanations. Now I really
understand the configuration and how is related to bandwith and length
of the
recorded files. There is also a fixed time between files
recorded and it is always 10 minutes. But, files are overlapped, so
there you can
record a file to contain longer than 10 minute
transmission
So, let’s see which would be a good configuration to
perform a real QSO. Lets say in LF with some S/N and not al VLF levels
At the same time can be a good exercise to check if I
finally understood all this stuff ;-)
Tx at 4K19A/CRC16/1 sec symbol rate would take 9 min and
4 sec to transmit 17 characters messages
Assume 15 minutes periods. Lets say first (even)
transmitting at the hour and 30 min pass the hour
Second (odd) transmits at minute 15 and 45
Rx at 44100 sample rate, using a 65536 FFT length, and
1536 decimation, file will contain 38 minutes of recorded signal. Looks
more than enough
as we are using about 9 minutes transmissions. Then
bandwidth of the recorded files will be “Sample rate / decimation”
44100 / 1536 = 28.71 and then divided by two as SLab
generates the file, ending with 14.35Hz. Which is enough bandwith for a
1 sec symbol rate (10/1=10Hz)
So, assume both stations had Rx running previously and SL
already producing files every 10 minutes. Files will contain 38 minutes
of recorded signal
A file recorded by windows just after transmission end
(lets say) 22:10 would contain a record of 38minutes, so starting time
will be really 21:32
This file will contain the message transmited by the
station calling in first period (CQ). To decode it we will select a
timeshift from 21:32 to 22:00 = 28 minutes
So there will be time enough to decode the message and
then prepare the transmitter to answer in second period, 15 minutes
pass the hour, 22:15
answering the CQ of the station calling first
The station calling in first period should have to check
for files recorded at about 22:25 to try to decode an answer
And then prepare the corresponding transmission for next
even period at 22:30
Should this timing schem work for QSOs ? Assuming there
is enough S/N to work at this Tx rate of course
73 de Luis
EA5DOM
Hi Luis,
As Markus mentioned...
And see the attachment. In the example i set the sample rate to 44100
Hz. If you have a downconverter with an LO of 120 kHz, and expect a
message on 137 kHz exactly, set the internal frequency shift to a
center frequency of 17 kHz, like shown in the image.
Also remember that the number of exported FFT bins in the FFT export
register card should be set to the half of the FFT input size shown in
the FFT register card.
Keep us informed about the success :-)
I'm waiting for your first message to receive here. I'm monitoring
permanently, however only in the range 137.5 kHz +- 50 Hz and only
about 30 minutes message length. Other parameters would work too, but i
need to prepare a special SL instance then...
73, Stefan
Am 11.09.2018 13:40, schrieb VIGILANT Luis Fernández:
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
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
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-[email protected] [mailto:[email protected]]
En nombre de Domenico IZ7SLZ
Enviado el: viernes, 07 de septiembre de 2018 13:18
Para: [email protected]
Asunto: Re: LF: EbNaut transmission test in LF
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?
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
