Navtex weird behavior (4.1.18)

[kord1e]

I spotted a strong Navtex signal on 518 kHz and tried to decode it. Decoding didn't work when the reticle was placed on the main signal. However, it worked when it was placed away from the main signal as shown in the picture below.

Fldigi version is 4.1.18.

[rikvanriel]

If this issue is repeatable, could you please make a recording of the audio that fldigi has trouble decoding?

I can use that recording to reproduce the issue here, and fix the navtex decoder

[kord1e]

There's a sample in sigidwiki: https://www.sigidwiki.com/wiki/NAVTEX

I was able to reproduce this issue with that sample.

[rikvanriel]

The signal you linked is running at a baud rate somewhat higher than what the current fldigi code can adjust to. This is happening for various reasons:

1. By using an accumulator, instead of purely looking at signal peaks coming out of the low pass filters, we are looking at the noisiest part of the signal (zero crossings) instead of at the peaks.
2. In order to compensate for that inherent noise, the loop ended up having too little loop bandwidth, making it unable to adjust to signals with a baud rate outside of the (limited) window that code could handle.

I believe I have fixed that issue by changing the bit tracker in a way that simplifies it a little:

1. Instead of using an accumulator, look at the values coming out of the low pass filters and the discriminator.
2. Use the early late detector to find a peak in that value.
3. Use the values coming out of the discriminator to scale the time adjustment.

I will try this code with a few different signals before submitting a pull request.

The balance between stability (to ride out low signal periods) and the ability to adjust when the signal comes back is quite delicate.

[rikvanriel]

I think I have code that is working fairly well now.

One remaining issue is inherent jitter from having separate low pass filters for mark and space, which can get out of sync from each other. I don't think I can easily correct for that by looking at null crossings or peaks.

That jitter, combined with a wider loop bandwidth results in a slight increase in wrongly decoded characters in a weak signal recording I have sitting around here, despite the timing recovery appearing to lock on to the signal peak.

I would probably have to identify the symbol timing that results in the lowest number of bit errors to correct for the filters getting out of sync from each other in noisy situations. That is feedback across what is currently several layers, and would probably require a significant rewrite.

Lets do this simplification that broadens the loop bandwidth of the timing recovery loop first.

[rikvanriel]

This change should fix your issue:

#34

[kord1e]

Thanks! Navtex seems to work better in 4.2.04 now.

I noticed one issue - if there is a hiccup in the incoming audio, decoding may produce garbage for a brief moment, then continue. This may be normal, I don't know, but I'm reporting it anyway.

This happened when I received a Turkish navtex transmission and there was a crackle in the audio:

35 44.57 K- 034 40.00 D
35 55.00 K- 034 40.00 D
DDOHLKGOXDGOUSDOEEGOYLKGOXDGOUBFK
35 41.50 K- 034 51.17 D

[rikvanriel]

I have some code that can deal with that, but it is very NAVTEX specific at the moment.

I would like to rewrite it to abstract the FSK demodulation into its own class, with timing recovery done inside that class, and split that code all out from the NAVTEX demodulator before merging it upstream.

That would make it easy to reuse that code (without copy & pasting) to demodulate other FSK modes.