X11 Server, Thread Priority, and No PPS

[razed11]

I'm running from the docker image on Ubuntu 20.04 and have a few questions. My output is provided below.

I seem to have an error trying to connect to an X11 server. I don't happen to need this and I'm logged in remotely via SSH. Can this be run without X11?

Per the USRP general application notes I attempted to modify /etc/security/limits.conf to allow the changing of thread priorities. I understand that this warning can be ignored per the manual but I'd prefer not to see the warning if I can avoid it. I tried using my "username" group and the docker group but I continue to get the error. @igorauad I'm wondering if you have configured this when you run on Linux.

I keep get this error about not having a PPS signal. Is this required? I'm certainly not feeding my USRP a PPS signal. As you can see I tried setting --usrp-clock-source internal as a guess.

I specify --log-file but I don't see a log file created.

--freq 2250.0M --sym-rate 1.0M --sink file --out-file test.out.dat --frame-size normal --modcod QPSK1/4 --pilots off --rolloff 0.2 --log-file test.log.txt --source usrp --usrp-args addr=192.168.10.2 --usrp-clock-source internal
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused

(dvbs2-rx:15): Gdk-CRITICAL **: 20:51:44.646: gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
log :info: Starting DVB-S2 Rx
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[INFO] [MULTI_USRP]     1) catch time transition at pps edge
Traceback (most recent call last):
  File "/usr/local/bin/dvbs2-rx", line 1290, in <module>
    main()
  File "/usr/local/bin/dvbs2-rx", line 1247, in main
    tb = DVBS2RxTopBlock(options)
  File "/usr/local/bin/dvbs2-rx", line 129, in __init__
    source_block = self.connect_source()
  File "/usr/local/bin/dvbs2-rx", line 591, in connect_source
    usrp_source.set_time_unknown_pps(uhd.time_spec(0))
RuntimeError: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.

[igorauad]

Hi @razed11 ,

Can this be run without X11?

Both the Tx and Rx application can be executed with and without a GUI. Both support the --gui option to launch QT GUI. Otherwise, they run on the console only.

The GUI support on the Tx app is recent, so make sure to pull the latest changes. I've been reviewing the USRP tx lately (for instance, pushed another fix today).

I tried using my "username" group and the docker group but I continue to get the error. @igorauad I'm wondering if you have configured this when you run on Linux.

I don't recall configuring /etc/security/limits.conf. And I don't see any warning in the machine I'm using (Fedora 35). However, in the particular machine I'm using, I have generated a custom container based on the igorfreire/gnuradio-oot-dev image but with UHD compiled from source. I had to do that in order to use UHD 4.1, which I needed for some UHD features using a USRP N300. Either the warning is no longer displayed in UHD 4.1 or I do have the right permissions without configuring them.

I keep get this error about not having a PPS signal. Is this required?

I'll try to push a fix soon. I need to add a "No Sync" option like the one the GR's USRP Sink block has. The current implementation is assuming "Sync to Unknown PPS" by default. As a workaround, you can comment out the sync lines.

tx: https://github.com/igorauad/gr-dvbs2rx/blob/master/apps/dvbs2-tx#L439 rx: https://github.com/igorauad/gr-dvbs2rx/blob/master/apps/dvbs2-rx#L591

I specify --log-file but I don't see a log file created.

I think that is expected. There won't be any logs until the application starts correctly. Since it is crashing right at the start due to the missing PPS reference, no logs are produced.

Let me know if you figure out a way to prevent the UHD warning about thread priority. For example, you can control which user is running inside the docker container. By default, it runs as root inside the container. Maybe that makes a difference.

[razed11]

@igorauad Thanks for the replies.

I'm not using --gui and I thought the following messages were X11 related. My understanding from --help is that GUI mode is disabled by default to so I was surprised to see these:

Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused

[razed11]

OK. I have it running now by commenting those lines. I can live with that.

My transmitter is just transmitting idle packets so I need to feed it some data and see what comes through.

[igorauad]

@razed11 I had a chance to reproduce the GUI problem. The Unable to init server: Could not connect: Connection refused message was because the dvbs2-tx/rx apps were importing gr.qtgui even in non-GUI mode. I've fixed this in 037b47a1149d0f4f34ab6329dd0e2ff29b9c7d0a.

Regarding the PPS synchronization issue, I have added the missing USRP sync options in 98f2683258d1315f265f8b7ad705b4cc8b668ab2. Now, you can run with --usrp-sync none. Let me know if that really works for you.

My transmitter is just transmitting idle packets so I need to feed it some data and what comes through.

See the handy tsp craft plugin example in https://github.com/igorauad/gr-dvbs2rx/blob/master/docs/usage.md#example-2.

[razed11]

@igorauad Thank you. I rebuilt my docker image with the latest master. The X11 server issue is resolved.

Regarding --usrp-sync I get the same error but I took a more careful look at the code and USRP documentation and I think perhaps I did not communicate well. I don't have a PPS signal of any kind going into the USRP so I think my best option may be --usrp-sync pc_clock. I'm not sure how critical this is but it definitely removed the error. In any case adding the unknown PPS option may be useful for others. If you agree then we can close this issue.

That tsp tool does look handy. All of that piping of data around is really nice.

[razed11]

@igorauad I hope this isn't asking too much but can you help me make sense of the following:

I have a transmitter connected to a USRP N210 (CBX-40 daughterboard) via RF 2 (this is what the front panel says I assume this is RX2). It is configured and transmitting idle packets. I enabled debug mode and I get this:

--freq 2250.0M --debug 5 --sym-rate 1.0M --sink file --out-file test.out.dat --frame-size normal --modcod QPSK1/4 --pilots off --rolloff 0.2 --log-file test.log.txt --source usrp --usrp-antenna RX2 --usrp-args addr=192.168.10.2 --usrp-gain 9.0 --usrp-sync pc_clock
log :info: Starting DVB-S2 Rx
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
frame_sync :debug: --------------------------------------------------
frame_sync :debug: PLFRAME found
frame_sync :debug: Peak after: 488336; Timing Metric: 30.690510; Locked: 0
frame_sync :debug: Sym: 488336; SOF: -13.4 +0.2j; PLSC: -17.3 %+.1fj
plsync_cc :debug: SOF count: 1; Index: 488246
frame_sync :debug: --------------------------------------------------
frame_sync :debug: PLFRAME lock acquired
frame_sync :debug: Peak after: 32490; Timing Metric: 32.585594; Locked: 1
frame_sync :debug: Sym: 32490; SOF: -14.3 +0.2j; PLSC: -18.3 %+.1fj
plsync_cc :debug: SOF count: 2; Index: 520736
frame_sync :debug: --------------------------------------------------
frame_sync :debug: Peak after: 32490; Timing Metric: 34.360455; Locked: 1
frame_sync :debug: Sym: 32490; SOF: -15.0 +0.3j; PLSC: -19.3 %+.1fj
plsync_cc :debug: SOF count: 3; Index: 553226

Variations of the last message are repeated another 25 times or so. Then I get:

freq_sync :debug: Frequency offset estimation:
freq_sync :debug: - Coarse frequency offset: -0.495716
freq_sync :debug: - Coarse corrected: 0
plsync_cc :debug: Cumulative frequency offset: -0.495716
plsync_cc :debug: Rotator ctrl - Sent New Phase Inc: +1.557339; Offset: 1462946
frame_sync :debug: --------------------------------------------------
frame_sync :debug: Insufficient timing metric: 17.237955 (occurrence 1/3)
frame_sync :debug: Sym: 32490; SOF: +4.0 +0.6j; PLSC: +13.2 %+.1fj
plsync_cc :debug: SOF count: 31; Index: 1462946
plsync_cc :debug: Rotator ctrl - Tagged Phase Inc: +1.557339; Offset Error: -6; Delay: -6
frame_sync :debug: --------------------------------------------------
frame_sync :debug: Insufficient timing metric: 23.916344 (occurrence 2/3)
frame_sync :debug: Sym: 32490; SOF: +10.8 -0.1j; PLSC: +13.1 %+.1fj
plsync_cc :debug: SOF count: 32; Index: 1495436
frame_sync :debug: --------------------------------------------------
frame_sync :debug: Insufficient timing metric: 24.401932 (occurrence 3/3)
frame_sync :debug: PLFRAME lock lost
frame_sync :debug: Sym: 32490; SOF: +11.0 -0.2j; PLSC: +13.4 %+.1fj

Then I transmit a file and I get no further output which isn't that surprising given that it lost lock. I'm not sure what knobs I can turn here. I guessed at some USRP gain values of 0, 3, 6, 9 dB. The output power of the transmitter is 27 dBm and I have 50 dB of attenuation to the USRP which, at -23 dBm, should be reasonable as the USRP inputs should not exceed -15 dBm.

My transmitter configuration is as follows (I also tried turning on the pilot signal with the same results):

# MHz
PARAMETERS="symbol_rate:1 "
# dBm
PARAMETERS+="transmit_power:27 "
# 1/4 QPSK
PARAMETERS+="modulation_code:1 "
# 0.2
PARAMETERS+="roll_off:2 "
# Off
PARAMETERS+="pilot_signal:0 "
# Normal
PARAMETERS+="fec_frame_size:0 "
# Milliseconds
PARAMETERS+="pretransmission_delay:2000 "
# MHz
PARAMETERS+="center_frequency:2250.0 "

[igorauad]

Regarding --usrp-sync I get the same error but I took a more careful look at the code and USRP documentation and I think perhaps I did not communicate well. I don't have a PPS signal of any kind going into the USRP so I think my best option may be --usrp-sync pc_clock.

I thought --usrp-sync none would solve your problem because this option means there won't be any sync. That is, the application won't call any set_time_unknown_pps/set_time_now/set_time_next_pps function.

In any case, the device time is not critical unless you are looking to time-coordinate devices. For instance, to start transmitting at the same time from multiple USRPs. However, that is not even supported in the current implementation.

Variations of the last message are repeated another 25 times or so. Then I get:

freq_sync :debug: Frequency offset estimation: freq_sync :debug: - Coarse frequency offset: -0.495716 freq_sync :debug: - Coarse corrected: 0 plsync_cc :debug: Cumulative frequency offset: -0.495716 plsync_cc :debug: Rotator ctrl - Sent New Phase Inc: +1.557339; Offset: 1462946

Interesting. So it seems the reception breaks as soon as the coarse frequency offset is estimated. I'm not sure what it is, but the estimated frequency offset seems too large. It should generally stay within +-1/4 of the symbol rate. In your case, the correction range would be +-250 kHz (with 1 Mbaud), which translates to a +-0.25 estimate. The estimate of -0.49 means nearly half of the symbol rate, so -500 kHz, which more likely a wrong estimate.

The first question would be whether the Tx and Rx are really tuned to 2250 MHz? From what I see above, it seems they are. I'm not sure about the resolution of the CBX frontend tuner, but even if it can't generate 2250 MHz, it should not be too far (like more than +-250 kHz away). So I'd guess the problem is somewhere else.

Could you capture some screenshots of how the GUI looks like? You can run the rx with --gui --gui-all.

Also, would be able to share an IQ recording so I can have a look here and experiment with parameters? You can record one using the uhd_rx_cfile tool from GR. I think a command like the following will work (untested):

uhd_rx_cfile --args addr=192.168.10.2 -antenna RX2 --gain 9.0 --freq 2250.0M --samp-rate 2.0M

[razed11]

@igorauad Thank you. I will do the things you have asked and will get back to you.

[razed11]

@igorauad Attached is the screen capture and the IQ capture.

I'm curious why "Center Frequency" is 1.0 GHz should this be the same as the carrier frequency? When I use the slider to try to set it to 2.250 GHz it crashes when I get to 2.230 GHz. If I approach from > 2.250 GHz it crashes right at the carrier frequency. I changed the carrier to 2.200 GHz and it crashes when I get near that value.

In both cases the transmitter is transmitting but idle. I also verified that it is transmitting on the correct carrier with some test equipment. According the documentation:

"When the module is in Transmit Mode and no information is being transmitted, the module constantly broadcasts DVBS-2 zero frames in order to keep the receiving modem in lock state."

capture.bin.zip

[razed11]

Also I verified that --usrp-sync none does appear to work properly.

[razed11]

Here's the GUI with the frequency set to 2.200 GHz and the GUI set to 2.240 GHz (If I click again it crashes). I also increased the gain significantly.

[igorauad]

Also I verified that --usrp-sync none does appear to work properly.

That's great.

I'm curious why "Center Frequency" is 1.0 GHz should this be the same as the carrier frequency?

Where are you seeing that? In general, I tend to use carrier and center frequency interchangeably. When tuning on an intermediate frequency (e.g., after an LNB), I prefer to call it the center frequency (or simply intermediate freq) to avoid confusion with the actual carrier frequency. So center frequency is a more generic term, and it is what I'm using on the dvbs2-rx GUI.

The --freq option from dvbs2-rx is 1 GHz by default, but this is just an arbitrary number. I see you are correctly overriding the default value to 2250 MHz, which looks correct.

When I use the slider to try to set it to 2.250 GHz it crashes when I get to 2.230 GHz. If I approach from > 2.250 GHz it crashes right at the carrier frequency. I changed the carrier to 2.200 GHz and it crashes when I get near that value.

Could you share the crash logs? I can't reproduce the problem. On other other hand, I don't have the same USRP model.

The USRP I have for testing now is an N300, as I mentioned previously. Because of that, I am using GR compiled with UHD 4.1. With this model and version, I can change the gain and center frequency seamlessly via the GUI. I don't get any crashes.

The other setup I have for testing is with an RTL-SDR. In this case, I'm using the same container image as you are using, with UHD 3.15. However, I only have an RTL-SDR there, so I'm not using UHD at all. In any case, the GUI has the same gain and frequency options, which do work. I don't see any crashes either.

the module constantly broadcasts DVBS-2 zero frames in order to keep the receiving modem in lock state

That is the usual behavior. In CCM mode, the modulator typically sends null MPEG TS packets while idling so that the demodulators can keep the lock. In VCM mode, as far as I can tell, implementations prefer to send dummy DVB-S2 PLFRAMEs. In both cases, the demodulators can stay locked. In the latter case, you would see the dummy frame count increasing on the dvbs2-rx monitoring info. However, I think that does not apply to your setup. In your case, I'd guess you have null MPEG TS packets instead (CCM mode), unless you are not using MEPG TS encapsulation?

Here's the GUI with the frequency set to 2.200 GHz and the GUI set to 2.240 GHz (If I click again it crashes). I also increased the gain significantly.

Both screenshots indicate you are not tuning to the carrier correctly yet. They are only showing noise, and the first screenshot shows some DC offset leakage.

On the other hand, the IQ capture you sent does show the carrier. So I think the problem might be that the USRP tuning commands issued by dvbs2-rx are not working in your setup. If you can send further information/logs, we can track that down.

The IQ capture is too short, though. It doesn't have enough data to get to a good state (after frequency correction, etc). But it seems promising anyway. See the screenshot:

Here is the command I used to analyze the IQ data:

dvbs2-rx --source file --in-file data/users/razed11/capture.bin --in-real-time -f 2250.0M -s 1.0M -m qpsk1/4 --pilots off  -d 5  --sink file --out-file /dev/null --gui --gui-all

[razed11]

@igorauad Maybe I'll order the same model you have to simplify things.

When I set --freq to my center frequency and run the GUI the widget shows up as 1.0 GHz. It sounds like a minor bug there which I can try to hunt down when I get some time.

I'm not sure where the logs are? I specify a log file but don't see it in the directory where I launch the script. I can also look into this. Though I can set --debug and capture it to a file.

Thanks for looking at the data. Obviously I'm a bit new to this (though I've applied to graduate school to study it this Fall as a much older student).

The transmitter is using MPEG TS.

I need to turn my attention to another task for a bit and I had to break down my setup but I'll put it back together and get you some data. Again, I appreciate your feedback. It's fun stuff!

[igorauad]

Hi @razed11 ,

After a long delay, I'm catching up with some pending issues.

When I set --freq to my center frequency and run the GUI the widget shows up as 1.0 GHz. It sounds like a minor bug there which I can try to hunt down when I get some time.

I can't reproduce this problem with the current state. Not sure if it was a bug at some point and it was solved. Or if the issue remains. If you are able to try again, could you confirm and share the exact command you used?

In my tests, the GUI range widget controlling the center frequency starts with the frequency defined via the --freq option, as intended. It works with both the RTL-SDR and USRP on the Rx application, and with the USRP on the Tx application.

I've also just pushed a change to make sure the frequency-domain plots (waterfall and spectrum) have the x-axis updated with frequency changes (in 5c33ba2).

I'm not sure where the logs are? I specify a log file but don't see it in the directory where I launch the script. I can also look into this. Though I can set --debug and capture it to a file.

Indeed, I realized at some point that the --log-file option wasn't really implemented, so I dropped it some time ago in 9f06ba1.

In any case, the current implementation uses the GNU Radio logging tools for most low-level logs. So you can have some control on the logging levels and whether they should be saved to a file. For your reference, see the docs at https://wiki.gnuradio.org/index.php/Logging#Logging_Configuration.

I'm a bit new to this (though I've applied to graduate school to study it this Fall as a much older student).

That should be fun! :) All the best on the application and on the grad school work.

Maybe I'll order the same (USRP) model you have to simplify things.

That's not necessary. I'm actually interested in making sure gr-dvbs2rx works across multiple USRP models. So any feedback will be much appreciated.

Thanks a lot

[igorauad]

Hi @razed11 ,

Just so I can keep track of outstanding issues, I will close this issue for now. Whenever you try again, please feel free to reopen or create a new one.

Thanks again!

[razed11]

@igorauad Please accept my apologies. That project came to abrupt end for reasons outside my control. I was looking forward to getting that all working.