Recording using rt-mbms-modem

[m-bures]

Recording using rt-mbms-modem

Hello,

we tried to record 5G signals using

modem -w name_of_the_recording

but it was for us impossible to make a good / usable recording. The SW is struggling to synchronize to the input signal while if we use modem command without –w (reception only) the synchronization is achieved with the same RF signal – see attached files.

Does anybody know what where the problem might be ?

Generally for reception the modem (V 1.1.1) gives us much worse results compared to the older rp process (V 1.1.0).
With V 1.1.1 it is more difficult to synchronize to any input signal, to get a stable reception and finally get a glitch-free video playback.

I forgot to state that we have bladeRF xA4 SDR. Unfortunately we are still waiting for Lime mini SDR, which we ordered in July 2021.

Thank you, Michal

modem_play.txt
modem_rec.txt

[dsilhavy]

@m-bures Friendly reminder: Please also share the sample files that cause problems on your end for us to reproduce. Thank you!

[kuehnhammer]

@dsilhavy - As preparation for a call with @m-bures this morning, I downloaded and tested the 10MHz sample file (https://obeca-testdaten.s3.eu-central-1.amazonaws.com/10MHz_MCS16_1kHz25_RTP_3.5.raw)

I can confirm that it has playback issues (stalls in audio and video every one or two seconds), even though the modem reports no CRC errors, and neither Wireshark nor VLC display RTP packet loss or sequence discontinuities.

VLC shows no actual errors, but "playback way too early"-warnings.

[kuehnhammer]

Additional info from an email by @m-bures:

I would like to let you know that I tried to play recordings that I downloaded from web page
https://github-wiki-see.page/m/Austrian-Broadcasting-Services/obeca-info/wiki/sample-files

and from these files the only recording that we could played smoothly is
5MHz_MCS16_1kHz25_RTP_3.5.raw

a little worse is
5MHz_MCS16_7kHz5_RTP_3.5.raw

the following files can be decoded using 
modem  -f  file-name  -b x

10MHz_MCS16_1kHz25_RTP_3.5.raw
3MHz_MCS16_1kHz25_RTP_3.5.raw
6MHz_MCS16_1kHz25_RTP_3.5.raw
7MHz_MCS16_1kHz25_RTP_3.5.raw
8MHz_MCS16_1kHz25_RTP_3.5.raw

but on vlc the playback is jerky (interruption every 1 – 2 second in video and sound).

[kuehnhammer]

Assigning myself for the investigation into why using the -w switch for file recording causes CRC errors.

[dsilhavy]

Regarding the problems with the RTP sample files, I created a separate issue for that #22

[kuehnhammer]

I was able to reproduce the issue. It would appear that the file IO when creating a sample file on disk can be enough to cause packet loss in the USB transfer from BladeRF when the periodic flushes to disk occur, especially at BladeRF's default settings for buffer size and count.

It seems to work quite reliably when not writing to disk during the recording, but creating the sample file in memory by writing to a tmpfs mount.

I also increased the BladeRF transfer buffer size in 5gmag-rt.conf:
device_args = "driver=bladerf,buflen=16384";

Here's what I tried:

sudo mkdir /tmpfs
sudo mount -t tmpfs none  /tmpfs
sudo ./modem -w /tmpfs/2chrx.raw

This created a file without CRC errors from a 5MHz cell with 2 RX antennas -- which should be the same data rate as a 10MHz cell with only one RX antenna.

@m-bures, can you please try if this works for you?

[m-bures]

We tested the recording of RF signal with modem version 1.2. using the above mention procedure. The recording is possible, the output from the modem application is the same as if not recording which is big progress.

Unfortunately the recorded files when played using –f option are either with a jerky video or there is a message
Aborted (core dumped).

We uploaded our recordings:

Recording-8MHz-946-bladerf-1.raw
(jerky playback)

Recording-8MHz-946-bladerf-2.raw
(Aborted core dumped)

Recording-8MHz-946-bladerf-3.raw
(jerky playback)

Recording-8MHz-946-hackrf-1.raw
(Aborted core dumped)

The recordings are available here:

https://cloud-drive.radiokomunikace.cz/owncloud/index.php/s/0xl4X845ImU3Gl6
streams2021

We tested it both on NTB and the NUC.

@kuehnhammer could you please try to play our recordings to see how it behaves on your HW ?

Thank you,
Michal

[dsilhavy]

Did some quick tests

• Recording-8MHz-946-bladerf-1.raw
  • A/V desync between -0.5 and -0.7
  • Playback stuttering and stalling
  • Some minor decoding errors: e.g frame length mismatch 0 << 2632
  • Muxed TS stream with 3 programs all using HEVC including different resolutions
    • CT sport HD | 5G : HEVC 1080p, 50fps
    • CT 24 HD | 5G: HEVC 720p, 50fps
    • Prima | 5G: HEVC 720p, 50fps
• Recording-8MHz-946-bladerf-2.raw
  • modem[11534]: Phy: failed to receive MIB
  • malloc(): smallbin double linked list corrupted
• Recording-8MHz-946-bladerf-3.raw
  • Same behavior as bladerf-1
• Recording-8MHz-946-hackrf-1.raw
  • modem[11898]: Phy: failed to receive MIB
    modem[11898]: Phy: PSS/SSS detected: Mode FDD, PCI 112, CFO -0.022021048 KHz, CP Extended
    malloc(): smallbin double linked list corrupted

I suggest to:

• Do not record multiple channels at once, demux and record single channel
• Try H.264 instead of HEVC for reduced decoding requirements on the client side

[m-bures]

Yes, it is exactly what we can see when we try to play the recordings.

The thing is that if we use the modem without recording it works (occasional glitches in video – see #32) but generally it works and all services from TS can played smoothly. Same applies during recording.

The problem starts when we want to play the recording then the result is exactly as you described @dsilhavy .