frame drops seen in file I/O mode (no SDR involved) in dvbs2 tx and rx simulation

[sumanthraikar]

I tried the following command "dvbs2-tx --source file --in-file example.ts | dvbs2-rx --sink file --out-file rx_ex.ts" to get a decoded version of example.ts file. This resulted in a rx_ex.ts file that clearly has frame drops in the beginning. Is this expected or can I get a better one that closely matches example.ts?

[igorauad]

Hi @sumanthraikar ,

Yes, the initial frame drops are expected in the current version. The current implementation is more targeted at real-time decoding, in which the initially dropped frames are typically irrelevant. You can think it is equivalent to turning on an ideal receiver slightly later. On the other hand, when trying to process a recorded IQ file or a TS loopback test as you tried, the initially lost frames are noticeable. Unfortunately, I haven't had a chance to work on a solution or a way to alleviate this issue yet.

Please see a more detailed technical discussion about why the frames are likely dropped in the beginning at: https://github.com/igorauad/gr-dvbs2rx/issues/20#issuecomment-1514772150.

Regards

[sumanthraikar]

I tried the dvbs2-tx-rx example with both the transmitter and receiver processing using pluto devices at end, but for some reason it is frozen. Here is my my GNU flowgraph Following terminal output Executing: /usr/bin/python3 -u /home/sumanthraikar/Desktop/GNU RADIO/gr-dvbs2rx/default.py

Warning: failed to XInitThreads() Traceback (most recent call last): File "/home/sumanthraikar/Desktop/GNU RADIO/gr-dvbs2rx/default.py", line 761, in main() File "/home/sumanthraikar/Desktop/GNU RADIO/gr-dvbs2rx/default.py", line 739, in main tb = top_block_cls(agc_gain=options.agc_gain, agc_rate=options.agc_rate, agc_ref=options.agc_ref, debug=options.debug, frame_size=options.frame_size, freq_offset=options.freq_offset, gold_code=options.gold_code, in_file=options.in_file, modcod=options.modcod, pl_freq_est_period=options.pl_freq_est_period, rolloff=options.rolloff, rrc_delay=options.rrc_delay, rrc_nfilts=options.rrc_nfilts, snr=options.snr, sps=options.sps, sym_rate=options.sym_rate, sym_sync_damping=options.sym_sync_damping, sym_sync_loop_bw=options.sym_sync_loop_bw) File "/home/sumanthraikar/Desktop/GNU RADIO/gr-dvbs2rx/default.py", line 342, in init self.iio_pluto_source_0.set_samplerate(samp_rate) TypeError: set_samplerate(): incompatible function arguments. The following argument types are supported:

1. (self: gnuradio.iio.iio_python.fmcomms2_source_fc32, samplerate: int) -> None

Invoked with: <gnuradio.iio.iio_python.fmcomms2_source_fc32 object at 0x7f74f94818f0>, 2000000.0

[sumanthraikar]

when i tried "tsp -I craft --pid 100 | dvbs2-tx --sink plutosdr --freq 1316.9e6 --sym-rate 1e6" , I got an error at seting sampling rate of pluto, the whole error message is as follows pluto_utils::get_pluto_uri :info: More than one Pluto found: pluto_utils::get_pluto_uri :info: 0: 0456:b673 (Analog Devices Inc. PlutoSDR (ADALM-PLUTO)), serial=1044730a19970005ffff29001xxxxx [usb:3.3.5] pluto_utils::get_pluto_uri :info: 1: 0456:b673 (Analog Devices Inc. PlutoSDR (ADALM-PLUTO)), serial=104400b83991001006002a00c7axxxx [usb:3.4.5] pluto_utils::get_pluto_uri :info: We will use the first one. UTraceback (most recent call last): File "/usr/local/bin/dvbs2-tx", line 1065, in main() File "/usr/local/bin/dvbs2-tx", line 1035, in main tb = dvbs2_tx(options) File "/usr/local/bin/dvbs2-tx", line 186, in init sink_block = self.connect_sink() File "/usr/local/bin/dvbs2-tx", line 586, in connect_sink sink = self.setup_plutosdr_sink() File "/usr/local/bin/dvbs2-tx", line 509, in setup_plutosdr_sink iio_pluto_sink.set_samplerate(self.samp_rate) TypeError: set_samplerate(): incompatible function arguments. The following argument types are supported:

1. (self: gnuradio.iio.iio_python.fmcomms2_sink_fc32, samplerate: int) -> None

[josephjosuuu]

It says that the sample rate should be int; try with:

--sym-rate int(1e6)

[igorauad]

Hi @sumanthraikar , thanks again for reporting the issue.

I apologize, but the current support for the PlutoSDR is mostly untested. I don't have a PlutoSDR that I could use for testing. Anyway, the issue makes sense. I can see that the sample rate parameter passed to the PlutoSDR source/sink blocks should be an integer, and I was previously passing a float.

I've pushed a fix in 5951c78. Please try it by switching to branch pluto_samp_rate.

[sumanthraikar]

Thank you so much for taking the time to solve the issue

[igorauad]

No worries! So I will go ahead and close this issue. Please feel free to reopen it or open another one if you need more help.