Thanks very much to Domenico IZ7SLZ for informing the group about our LF EbNaut-PSK activities! I am glad that this has raised some interest, and I'm sure that trying Paul's software is well worth the effort for anyone wishing to communicate with really weak signals, very near to the ultimate Shannon-Hartley limit.

 

In this mail, I will try to provide some information regarding the receive procedure. As mentioned before, we have used SpecLab as a receiving frontend to generate an IQ wav file, which can be read by EbNaut-RX. Wolf has provided a dedicated riggered audio recording function, which is able to save decimated and precisely timestamped IQ data, starting at specified GPS-controlled times.

 

As I am already continuously running a SpecLab instance for the opds decoder, I decided to go down a slightly different route, by reusing the exported ascii spectrum-data files for EbNaut as well. One advantage of this procedure is that the LO used in the downconversion for the spectrogram already includes samplerate tracking, which avoids the need for CPU-intensive samplerate interpolation. If GPS-1pps is used for reference, the absolute LO phase will even be recovered after a soundcard dropout. Timestamping is derived from NTP, which is slightly less accurate but perfectly adequate for the symbol durations down to 0.2 s that were  used in our tests.

 

So all one has to do is to select a MMDDhhmm.txt file from the spectrum\data\ directory which contains the received sequence, and convert it back to time domain using an inverse FFT. In an email to Domenico (pasted beneath), I briefly described the file conversion and the frequency-time alignment process used with EbNaut. An updated version of the utilities can be found at
http://df6nm.bplaced.net/VLF/fec_tests/df6nm_ebnaut_utilities.zip (184 kB).

The SpecLab config-file _opds32_150924.usr for opds has been slightly updated, hopefully making life a bit it easier for first-time opds and EbNaut users. The analyzed audio frequency band has been centered on 1500 Hz. You will still have to calibrate your samplerate and receiver frequency. Note that for opds and EbNaut postprocessing the number of exported FFT bins (262144) always needs to be half the FFT length (524288).

 

The inverse-FFT utility is ebnaut_ifft3.exe. Dragging and dropping a .txt data file over it's icon will let it produce an equally named .wav file which can then be read by ebnaut-rx software. Note that for correct time and frequency information in the wav header, the ifft configuration file sr.txt needs to contain your accurate soundcard samplerate, FFT decimation factor and length, and RX frequency.

 

Shortly after starting ebnaut-rx and before it enters the decoding process, it writes the symbol amplitudes and phases to a logfile called rawsyms.txt. This can be used to assist the determination of the correct frequency and time offset. Clicking on the show_rawsyms3.exe utility will output a window with three different diagrams and two lines of text information.

 

The white dots at the top are a time domain representation of the symbol phases. With a strong signal, these should ideally be gathered around two horizontal lines, 180° apart. For the example screenshot, the frequency offset had been made 1 mHz too negative, resulting in gradually increasing symbol phases.

 

The red spectrum is a Fourier transform of the symbol amplitudes. The Nyquist frequency range is identical to the symbol rate (ie +- 0.5 Hz for 1 second symbols), with a zoomed section on the right. The spectrom will show a peak if a test carrier has been sent, and the freq offset in EbNaut can then be adjusted iteratively to bring it to the center. However no red peak will be appear from a PSK data transmission.  

 

The blue spectrum is calculated from the squared complex amplitudes. As taking the square eliminates the signal polarity, this spectrum will also show a peak from a PSK modulated sequence. Unfortunately the squared spectrum fails to produce a peak for very weak signals where the SNR of the individual symbols becomes too low. If he peak is present, the frequency error (e.g. offset needs to be increased by 0.97 mHz) can be read in the text beneath.

 

Unfortunately there is no direct indication to guide you towards the correct bit timing. One way is to iteratively adjust the fractional time offset for least scatter of dots or highest blue peak. In the bottom line, an estimate of the time error magnitude (nominally 0 to 0.5) is given, which should be small if the correct symbol timing has been found. This is calculated by a normalized autocorrelation with a one-symbol shift, exploiting the property of the sequence that the likelyhood of a symbol transition should always be 50%, independent of a prior transition. Again, this method will not work if the SNR is low.
 
For testing purposes, you can try the data in
http://df6nm.bplaced.net/VLF/fec_tests/ebnaut_data_09200300.zip (750 kB).
If you carefully inspect the timestamp of the successful decode, you may note that in this case an extra one-second delay was required. Domenico confirmed that it was caused by a temporary GPS-derived clock error on the transmit PC.

Hope this helps... so go ahead and have fun!

 

Thanks to Paul and Wolf for their original ideas and invaluable software, and to Domenico for surmounting all obstacles to bring this to life on 137 kHz.

 

Best 73,
Markus