rt-mbms-modem with HackRF One SDR ?

[m-bures]

We are testing HackRF One SDR to use it with Receive Process (rt-mbms-modem). Having previous experience with BladerRF we modified configuration in

/etc/5gmag-rt.conf

from bladeRF to HackRFone.

The new SDR is well detected:

obeca@NUC014:/$ hackrf_info hackrf_info version: unknown libhackrf version: unknown (0.5) Found HackRF Index: 0 Serial number: 0000000000000000f77c60dc2867a6c3 Board ID Number: 2 (HackRF One) Firmware Version: 2021.03.1 (API:1.04) Part ID Number: 0xa000cb3c 0x00584f66

** When we try to process a 5G Broadcast signal through HackRF we see that a signal is detected but it doesn’t get synchronized. With BladeRF xA4 it works. There are occasional glitches in the decoded video but no errors indicated by modem / rp applications.

Using HackRF we cannot even achieve a synchronization with identical 5G signals (5 or 8 MHz).

Enclosed is our conf file and output from rt-mbms-modem.

Does anybody have experience or HackRF working with rt-mbms-modem for 5G Broadcast application ?

Thank you, Michal

---

Hack_RF_One.txt 5gmag-rt_conf.txt

[dsilhavy]

We will bring this topic up in the next developer call maybe someone has experienced something similar

[kuehnhammer]

Michal, can you please provide a log with increased level, by adding the -l flag: ./modem -l0

[kuehnhammer]

@ben-EDT -- as you added the instructions for HackRF, can you maybe share what you did to get it working? Thank you!

[m-bures]

We uploaded more detailed outputs from modem for the HackRF One SDR using modem -l 0

From the log, it can be seen that there is often reported “ringbuffer overflow“ so we tried to increase default value in the config file from 200 ms to 1 000 ms, but it didn’t make HackRF to work with Obeca receiver.

We also observed that reported Carrier Frequency Offset (CFO) is much higher compared to CFO reported when using BladeRF. The frequency stability of the internal oscillator in HackRF is much worse compared to BladeRF internal oscillator.

In the specification there is 20 ppm which in our use case corresponds to frequency deviation of up to 14.92 kHz for 746 MHz, whereas BladeRF specifies 1 ppm which corresponds to 0.746 kHz. The difference can be seen.

We tried to compensate on the generator side. We have to set 746.009 MHz to get bellow 1 kHz CFO.

Is there anybody who is successfully using HackRF for the Obeca receiver ?

modem_141-bladeRF-standard.txt modem_141-bladeRF-verbose.txt modem_141-hackRF-ringbuffer-1000ms-verbose.txt modem_141-hackRF-standard.txt modem_141-hackRF-verbose.txt modem_141-hackRF-ringbuffer-1000ms-standard.txt

[alessandrolucco]

We have done several tests with HackRF. The only way we have found to be able to receive the signal correctly is by inserting a 10MHz reference into the clock input port. In this way, and by setting a "normalized gain" of 40 dB in the configuration file, the modem syncronize the stream.

[ben-EDT]

Hello @m-bures,

Apologies for the delay in responding to this issue, I had some production projects take priority and have been re-building my Reference Tools development environment with new hardware.

The fix posted by @alessandrolucco is the same solution I used. Specifically, I installed tthis component in the HackRF and adjusted normalized gain.

It should be noted that the HackRF only operates in half-duplex and as such, my intention has only ever been to use it as an SDR choice when exploring receive-only-mode use-cases.

I hope this solves this issue for you.

Regards Ben

[m-bures]

Hello,

thanks Alessandro and Ben. It seems that the internal oscillator of this SDR is unstable and that without taming the oscillator with an external signal the reception is not possible.

@alessandrolucco

What type of signal did you use as reference (waveform, levels, etc.) ?

In the manual they specify for CLKIN “The CLKIN port on HackRF One is a high impedance input that expects a 0 V to 3 V square wave at 10 MHz. Donot exceed 3.3 V or drop below 0 V on this input. Do not connect a clock signal at a frequency other than 10 MHz“

We have only 10 MHz sinewave AC coupled, i.e. with symmetrical +/-

The module used by Ben looks like a good solution to allow standalone operation.

Regards Michal

[alessandrolucco]

Hello, @m-bures sorry for the delay, to generate the "clkin" signal we used a waveform signal generator, like Keysight 33120A. We set a 10 MHz sine wave with amplitude 1.5 Vpp and offset 0.75 V (as it is an high impedance input).

[dsilhavy]

@ben-EDT To provide update to the documentation, we can then close this issue

[dsilhavy]

@ben-EDT updated the documentation, see https://github.com/5G-MAG/Documentation-and-Architecture/wiki/MBMS-Modem#using-hackrf-one-with-soapy

Closing this.

[m-bures]

We installed TCXO NooElec into HackRF One. Now the Obeca can sync to the signal with this SDR.

What we observed compared to BladeRF xA4 is:

A/ it tis necessary to apply signal with 20 – 30 dB higher level (with the same 40 dB normalized_gain settings in conf file) to see same level of spectrum in Obeca GUI.

B/ the indicated signal is noisier, typically we were not able to see higher CINR than ca 19 dB with this SDR (for 16 QAM MCS 16). The points in constellation diagram are noisier. 64 QAM modulation with MCS 27 is not decodable at all (BLER > 0) probably because of the noisy character and points in constellation diagram too close, 16 – QAM was OK (BLER = 0) - see attached pictures.

C/ using TSoverIP, 3 services with HEVC encoding, with 16-QAM we see glitches in the video (in Obeca no errors reported with default verbosity), in VLC when RTP/UDP is used, we see rtp demux – packets lost but “netstat -I” doesn’t show any dropped packets (neither in Obeca nor in VLC computer attached to Obeca).

---

For HackRF we increased normalized_gain to 50 dB in the conf file.

Do you have similar observations with HackRF or did you somehow add or modify parameters in the conf file for buffering / buflen or any other parameters ?

@ben-EDT @alessandrolucco

What max CINR could you achieve with your HackRF ?

---

Another observation HackRF vs BladeRF:

We have two identical BladeRF xA4 with one we can achieve CINR > 30 dB (it decreases when in operation for some time to ca 25 – 27 dB) but with the second BladeRF xA4 we cannot get above CINR 20 dB with the same signal and Obeca receiver (just swapping SDRs). This is really strange.

@kuehnhammer

HackRF with oscillator vs BladeRF experience.zip

We also see occasional glitches in the video but it is far less frequent compared HackRF which is much noisier – see attached pictures.

[dsilhavy]

Thank you for the summary @m-bures , as discussed closing this