Receiving serial data

[Muhammad Anas]

Dear GNU Radio Community,

Is there any method for receiving data serially from another GUI
application other than GRC using xmlrpc/zmq blocks. I want to control GRC
parameters from another application serially in runtime.

Regards
Muhammed Anas

Reducing rare underflows to zero occurrences

[Chad Spooner]

All:

I'm developing a comm system involving three SDRs: transmit, channel 
effects, and receiver.


The channel SDR is controlled by a flowgraph that has various options 
for the channel: AWGN (h(\tau) = \delta(\tau)), LTI, and a couple 
time-variant frequency-selective channel models.


I need to run the full three-SDR system over long periods of time to get 
stable average values for system-performance parameters.


My problem is that the channel flowgraph reports underflows on the order 
of every hundred seconds or so (sometimes much less). I've tracked down 
these rare underflows in the channel to transient problems in the 
receiver flowgraph.


So I put together a minimum flowgraph that shows the problem, which is 
attached. When I run it, I get output like this:


   [INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
   [INFO] [X300] X300 initialization sequence...
   [INFO] [X300] Maximum frame size: 8000 bytes.
   [INFO] [X300] Radio 1x clock: 200 MHz
   usrp_source :info: set_min_output_buffer on block 1 to 2097152
   usrp_sink :info: set_min_output_buffer on block 2 to 2097152
   mmse_resampler_cc :info: set_min_output_buffer on block 4 to 2097152
   fir_filter_blk :info: set_min_output_buffer on
   block 5 to 2097152
   multiply_cc :info: set_min_output_buffer on block 9 to 2097152
   sig_source :info: set_min_output_buffer on block 8 to 2097152
   add_cc :info: set_min_output_buffer on block 6 to 2097152
   fastnoise_source :info: set_min_output_buffer on block 7 to 2097152
   *Uusrp_sink :error: In the last 579300 ms, 1 underflows occurred.
   Uusrp_sink :error: In the last 256008 ms, 1 underflows occurred.
   usrp_sink :error: In the last 84992 ms, 1 underflows occurred.
   UUusrp_sink :error: In the last 128008 ms, 1 underflows occurred.*

The PSD of the filtered input signal appears correctly on a spectrum 
analyzer.


System Information:

   24-core Intel i9 system
   Ubuntu 22.04.5 LTS, kernel 5.19.0-46-generic #47~22.04.1-Ubuntu
   gnuradio 3.10.1.1
   UHD 4.1.0.5-3

I've taken some pains to optimize the OS settings for gnuradio/UHD along 
the lines suggested by the online tips at


   https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

I've also tinkered with the minoutbuf parameter in the various blocks.

Any advice?

Thanks,

Chad
cyclostationary.blog
cmspoo...@nwra.com





--
Chad M. Spooner, PhD
NorthWest Research Associates
149 Bonifacio Place, Suite 200
Monterey, CA 93940
cmspoo...@nwra.com
831 521 6743
NWRA Scientist/Engineer, VP, BoD
cyclostationary.blog



channel_minimum.grc
Description: application/gnuradio-grc


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Receiving serial data

[Onno Benschop]

This is functionality that I'm going to need in the not too distant future.
I haven't yet got to that point, so I'm guessing, but I suspect that you
can use a file source / sink and point it at a serial port:

   - /dev/ttyS0 (serial port)
   - /dev/ttyUSB0 (serial over USB)
   - /dev/ttyACM0 (serial over USB)

Alternatively, you can use your own Python block and interact with a serial
port however you want to.

Onno

On Thu, 16 Jan 2025 at 22:18, Muhammad Anas  wrote:

> Dear GNU Radio Community,
>
> Is there any method for receiving data serially from another GUI
> application other than GRC using xmlrpc/zmq blocks. I want to control GRC
> parameters from another application serially in runtime.
>
> Regards
> Muhammed Anas
>

Re: DVBS2 TX

[Ron Economos]

The output of the Physical Layer Framer block is already interpolated by 
2X with zero stuffing.



https://github.com/gnuradio/gnuradio/blob/main/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L835


Ron


On 1/16/25 13:22, othman hijazi wrote:


Hello everybody ,

Iam trying to build a TX DVBS2 ,QPSK,in GNUradio , and iam getting 
after the decimating cosine filter  on the constellation sink a 4 dots 
plus a dot in zero x,y .


What is expecting a clean constellation with the 4 dots only , but 
keep getting an additional one in zero x,y is there an explanation 
for this ? what i need to do to get a clean 4 dots only four


 Dots on the constellation sink? If anybody can guide me plz.

I tried to add a dc block,delay before or after interpolation rrc 
filter . but no change .


I did attached a screenshot for the constellation sink and blocks .

Thanks in advance .
Best regards,
othman

Sent from Outlook 

Re: Reducing rare underflows to zero occurrences

[Daniel Estévez]

Hi Chad,

Something that you can do to monitor the problem is to look in 
/proc/net/udp. This will show you the fill level of kernel UDP receive 
buffers. If you've set the buffer size to 32 MiB as recommended by the 
performance tuning tips, usually these sporadic drops are the result of 
the flowgraph consuming data at a rate slightly lower than the nominal 
sample rate for multiple seconds, rather than a brief but larger 
performance reduction. If this is the case, you can see how the buffer 
fill level slowly increases over the course of several seconds until the 
buffer fills up and packets are dropped. Looking at this won't solve 
your problem, but at least it will give you a way to monitor if you do 
some changes to try to improve the performance.


Best,
Daniel.

On 16/01/2025 19:38, Chad Spooner wrote:

All:

I'm developing a comm system involving three SDRs: transmit, channel 
effects, and receiver.


The channel SDR is controlled by a flowgraph that has various options 
for the channel: AWGN (h(\tau) = \delta(\tau)), LTI, and a couple time- 
variant frequency-selective channel models.


I need to run the full three-SDR system over long periods of time to get 
stable average values for system-performance parameters.


My problem is that the channel flowgraph reports underflows on the order 
of every hundred seconds or so (sometimes much less). I've tracked down 
these rare underflows in the channel to transient problems in the 
receiver flowgraph.


So I put together a minimum flowgraph that shows the problem, which is 
attached. When I run it, I get output like this:


[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
usrp_source :info: set_min_output_buffer on block 1 to 2097152
usrp_sink :info: set_min_output_buffer on block 2 to 2097152
mmse_resampler_cc :info: set_min_output_buffer on block 4 to 2097152
fir_filter_blk :info: set_min_output_buffer on
block 5 to 2097152
multiply_cc :info: set_min_output_buffer on block 9 to 2097152
sig_source :info: set_min_output_buffer on block 8 to 2097152
add_cc :info: set_min_output_buffer on block 6 to 2097152
fastnoise_source :info: set_min_output_buffer on block 7 to 2097152
*Uusrp_sink :error: In the last 579300 ms, 1 underflows occurred.
Uusrp_sink :error: In the last 256008 ms, 1 underflows occurred.
usrp_sink :error: In the last 84992 ms, 1 underflows occurred.
UUusrp_sink :error: In the last 128008 ms, 1 underflows occurred.*

The PSD of the filtered input signal appears correctly on a spectrum 
analyzer.


System Information:

24-core Intel i9 system
Ubuntu 22.04.5 LTS, kernel 5.19.0-46-generic #47~22.04.1-Ubuntu
gnuradio 3.10.1.1
UHD 4.1.0.5-3

I've taken some pains to optimize the OS settings for gnuradio/UHD along 
the lines suggested by the online tips at


https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

I've also tinkered with the minoutbuf parameter in the various blocks.

Any advice?

Thanks,

Chad
cyclostationary.blog
cmspoo...@nwra.com





--
Chad M. Spooner, PhD
NorthWest Research Associates
149 Bonifacio Place, Suite 200
Monterey, CA 93940
cmspoo...@nwra.com
831 521 6743
NWRA Scientist/Engineer, VP, BoD
cyclostationary.blog





OpenPGP_signature.asc
Description: OpenPGP digital signature