FLEX: Some messages are not decoded

[ramonsmits]

In the Netherlands we have the P2000 network. A test messages "TESTOPROEP MOB" is broadcasted every 5 minutes and I noticed in my logs that this message isn't always logged. I assumed it was a reception issue or maybe the network dropping "low priority" messsages in case of spikes or something. Further log analysis showed that that latter wasn't true as is also happened when no messages were being broadcasted. I captured the received audio and manually analyzed locations where a test message should appear and I noticed that indeed audio is present.

I checked with versions 1.1.5 till 1.3.1 and all didn't decode the message.

For testing and further analysis I started to cut the white noise from the audio file. I fed that into multimon-ng and suddenly the message IS shown.

The following is the log difference:

FLEX: State: SYNC1
FLEX: SyncInfoWord: sync_code=0x870c baud=1600 levels=2 polarity=POS zero=-0.071898 envelope=0.196519 symrate=1599.889429
FLEX: State: FIW
FLEX: FrameInfoWord: cycleno=08 frameno=108 fix3=0x04 time=35:22 offset=0.00:00:09
FLEX: State: SYNC2
FLEX: State: DATA
FLEX: Phase A Fixed 1 errors @ 0x00000800  (0x6ab28960 -> 0x6ab28160)
FLEX: Phase A Fixed 1 errors @ 0x01000000  (0x13f0a7cd -> 0x12f0a7cd)
FLEX: Phase A Fixed 1 errors @ 0x00000040  (0x00000040 -> 0x00000000)
FLEX: Phase A Fixed 1 errors @ 0x00800000  (0x7f7fffff -> 0x7fffffff)
FLEX: Phase A Fixed 1 errors @ 0x00080000  (0x00080000 -> 0x00000000)
FLEX: BlockInfoWord: (Phase A) BIW:00000807 AW:01-02 (1 pages)
FLEX: CAPCODE:0000000000120160
FLEX: Parse Alpha Numeric
FLEX|0.00:00:09|1600/2/K/A|08.108|001180000|ALN|TESTOPROEP MOB
FLEX: State: SYNC1
FLEX: SyncInfoWord: sync_code=0x870c baud=1600 levels=2 polarity=POS zero=-0.048714 envelope=0.196068 symrate=1599.760081
FLEX: State: FIW
FLEX: FrameInfoWord: cycleno=08 frameno=111 fix3=0x04 time=35:28 offset=0.00:00:15

Based on the fact that in the original I don't see SYNC1 or SYNC2 I think that is where my quest should start as I think these are the "headers" in the messages. The fact that there are 5 errors also likely indicated that the SNR isn't great.

Does anyone have any idea how to further diagnose this why the original recording isn't fully decoded but the version that has white noise removed is?

Ideally I want to debug this. Maybe even chop up the received raw audio data somehow.

[filibuster007]

If you are using rtl_fm, what rtl_fm parameters do you use?

[ramonsmits]

Just the standard: rtl_fm -s 22050 -f 169.650M for a while I had the gain fixed.

Coincidentally I've bought a new RTLSDR stick that also comes with another antenna. Ever since I haven't missed a single TESTOPROEP MOB.

[ramonsmits]

The files, trying to decode 3.flac does not show the test message but decoding 3-short.flac does show it while it only has data cut from the middle. Audio is identical.

• 3.flac
• 3-short.flac

[chris021]

Hey @ramonsmits I think I have something similar going on. can you share the commands you are using to record and playback etc so I can confirm i'm seeing similar. My issue appears to happen most commonly when there is a number of messages in the same cycle, so may be a different issue.

[ramonsmits]

Hey @ramonsmits I think I have something similar going on. can you share the commands you are using to record and playback etc so I can confirm i'm seeing similar. My issue appears to happen most commonly when there is a number of messages in the same cycle, so may be a different issue.

See the README for examples

[EliasOenal]

@ramonsmits unless you're using the native raw format, dithering from SoX will also introduce a little additional noise. You may try converting your input files with SoX several times, while omitting the -R parameter. Without -R it will use a random seed, which sometimes may allow it to pick up a weak signal.

Trimming the input files will affect the dithering PRNG of SoX and result in different noise even in -R repeatable (fixed seed) mode.