[Discuss-gnuradio] Gnuradio Runtime buffers and latency

[Wheberth Damascena Dias]

Hi all, I have created an OOT block that receives PDUs as input, stores the
data in a FIFO buffer and generates a stream as output. Case no data is
available at the FIFO, stuffing data is generated.
The block (kind of) works as intended, but when it is on the system with no
data PDUS being received it does its job and generates stuffing. The
problem is that, if I understood correctly, the rate of generation is
controlled by the blocks downstream (via backpressure) meaning it fills all
buffers of the blocks downstream up to the USRP.
This makes the next PDUs that arrive to suffer a very high latency.
I am trying to find a way to limit the buffer of the blocks downstream, but
it doesn't feel like the right way to deal with this. Another idea is to
query the status of the output buffer (via pc_output_buffers_full()) and
generate stuffing data just when it is empty.
Anyone have faced similar issue? Am I in the right direction?
Any comments are appreciated.

Best Regards
-- 
*Wheberth Damascena Dias*
___ _ _ __ ___ __ _ _ _  _
http://www.linkedin.com/in/wheberth
e-mail:whebe...@gmail.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Chris Vine]

On Wed, 14 Aug 2019 08:44:31 -0400
"Michael Dickens"  wrote:
> Hi Jean Pierre & Kyeong - gr-osmosdr does not have an official port to GR3.8 
> as of yet. There are 3rd-party ports that might work, such as those from the 
> issue noted: https://osmocom.org/issues/3855 . See also:
> 
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> 
> Hope this is useful! - MLD

To get the igograud's repository to link cleanly with boost-1.70.0 and
gnuradio-3.8.0.0, I had to add this patch to gr-osmosdr's cmake build
system, as gr-osmosdr links to functions in boost::chrono.  I have not
yet verified that gr-osmosdr actually works with gnuradio-3.8, but it
does at least compile and link.

There may well be a better way to do it in cmake: I neither like cmake,
nor know it especially well.



diff --git a/lib/CMakeLists.txt b/lib/CMakeLists.txt
index 2171df2..9ba4592 100644
--- a/lib/CMakeLists.txt
+++ b/lib/CMakeLists.txt
@@ -52,6 +52,7 @@ endif()
 GR_OSMOSDR_APPEND_LIBS(
 ${Boost_LIBRARIES}
 gnuradio::gnuradio-blocks
+boost_chrono
 ${GNURADIO_ALL_LIBRARIES}
 )
 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Achilleas Anastasopoulos]

Hi Alex,

you may want to take a look at the OOT module gr-cdma (
https://github.com/anastas/gr-cdma).
This system implements a two-channel system with one of the orthogonal
channels being continuously transmitting pilots,
while the other carries data (in a synchronous/asynchronous way).
The Rx is always listening to the pilot channel and is continuously
adjusting frequency/timing.

Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Marcus Müller]

Hi Moses,

two observations:
1. If buffering 4 billion items (or bytes, or what ever "buffer size"
refers to here) helps, then only because it "smoothens" over the CPU
load by storing away seconds to minutes worth of data. If your computer
needs that long to catch up, something is too slow.
2. Instead of using a buffer block, realize that GNU Radio itself is
buffer based [1]. In the "advanced" tab of any block in GRC you can set
the Minimum Output Buffer Size to your liking, and have a 4 GB buffer
without any ado!

Again, if 4GB of buffering is necessary, your system is probably simply
too slow on average, and you'll run into problems, just a bit later.

[1] https://www.gnuradio.org/blog/2017-01-05-buffers/
On Wed, 2019-08-14 at 19:14 +0200, Moses Browne Mwakyanjala wrote:
> Hello everyone, 
> I'm experiencing packet dropping when I operate the USRP X310 (1GBe,
> 1472 bytes buffer) at high sample rates (around 20 MSamples/Second).
> This severely limits the nominal bit rate I was hoping for. Over a
> year ago, I stumbled upon a presentation [1] where the presenter was
> able to go around the problem by creating a block he called buffer.
> Basically, this block converts high rate complex IQ samples into 2-
> byte char and store them somewhere in RAM. The data is then released
> at a low-enough rate such that subsequent blocks cause no overflows.
> Sadly, the code is not public and I was thinking of writing a similar
> block myself. I'm looking for ideas on how to efficiently reproduce
> his results. All suggestions are highly welcomed. 
> 
> Regards,
> Moses.  
> 
> 
> [1] https://youtu.be/sDz9Ove0Dgc?t=581
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Nate Temple]

Hi Moses,

Depending upon what you're doing, you could use a sc16 data type instead of
fc32. You can change this in the UHD USRP Source block, and will cut your
data rate in half.

Also, make sure you've done the few things outlined in this app note:
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks


Regards,
Nate Temple

On Wed, Aug 14, 2019 at 10:22 AM Marcus D. Leech 
wrote:

> On 08/14/2019 01:14 PM, Moses Browne Mwakyanjala wrote:
>
> Hello everyone,
> I'm experiencing packet dropping when I operate the USRP X310 (1GBe, 1472
> bytes buffer) at high sample rates (around 20 MSamples/Second). This
> severely limits the nominal bit rate I was hoping for. Over a year ago, I
> stumbled upon a presentation [1] where the presenter was able to go around
> the problem by creating a block he called buffer. Basically, this block
> converts high rate complex IQ samples into 2-byte char and store them
> somewhere in RAM. The data is then released at a low-enough rate such that
> subsequent blocks cause no overflows. Sadly, the code is not public and I
> was thinking of writing a similar block myself. I'm looking for ideas on
> how to efficiently reproduce his results. All suggestions are highly
> welcomed.
>
> Regards,
> Moses.
> [image: image.png]
>
> The problem with any buffering approach is that if your host system
> cannot, on average, "keep up", your buffers will slowly fill up, since they
>   aren't being drained as fast as they are being filled.
>
> You need a faster computer, or a more-efficient processing flow.   No
> amount of buffering will help you, unless you're doing short
>   captures.  But for continuous capture/streaming, buffering cannot help
> you.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Marcus D. Leech]

On 08/14/2019 01:14 PM, Moses Browne Mwakyanjala wrote:

Hello everyone,
I'm experiencing packet dropping when I operate the USRP X310 (1GBe, 
1472 bytes buffer) at high sample rates (around 20 MSamples/Second). 
This severely limits the nominal bit rate I was hoping for. Over a 
year ago, I stumbled upon a presentation [1] where the presenter was 
able to go around the problem by creating a block he called buffer. 
Basically, this block converts high rate complex IQ samples into 
2-byte char and store them somewhere in RAM. The data is then released 
at a low-enough rate such that subsequent blocks cause no overflows. 
Sadly, the code is not public and I was thinking of writing a similar 
block myself. I'm looking for ideas on how to efficiently reproduce 
his results. All suggestions are highly welcomed.


Regards,
Moses.
image.png

The problem with any buffering approach is that if your host system 
cannot, on average, "keep up", your buffers will slowly fill up, since they

  aren't being drained as fast as they are being filled.

You need a faster computer, or a more-efficient processing flow. No 
amount of buffering will help you, unless you're doing short
  captures.  But for continuous capture/streaming, buffering cannot 
help you.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Moses Browne Mwakyanjala]

Hello everyone,
I'm experiencing packet dropping when I operate the USRP X310 (1GBe, 1472
bytes buffer) at high sample rates (around 20 MSamples/Second). This
severely limits the nominal bit rate I was hoping for. Over a year ago, I
stumbled upon a presentation [1] where the presenter was able to go around
the problem by creating a block he called buffer. Basically, this block
converts high rate complex IQ samples into 2-byte char and store them
somewhere in RAM. The data is then released at a low-enough rate such that
subsequent blocks cause no overflows. Sadly, the code is not public and I
was thinking of writing a similar block myself. I'm looking for ideas on
how to efficiently reproduce his results. All suggestions are highly
welcomed.

Regards,
Moses.
[image: image.png]

[1] https://youtu.be/sDz9Ove0Dgc?t=581
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Michael Dickens]

Hi Jean Pierre & Kyeong - gr-osmosdr does not have an official port to GR3.8 as 
of yet. There are 3rd-party ports that might work, such as those from the issue 
noted: https://osmocom.org/issues/3855 . See also:

https://github.com/igorauad/gr-osmosdr/tree/gr3.8
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8
https://github.com/igorauad/gr-osmosdr/tree/gr3.8

Hope this is useful! - MLD

On Wed, Aug 14, 2019, at 7:46 AM, Kyeong Su Shin wrote:
> Hello Jean Pierre:
> 
> You will have to install gr-osmosdr. If your repository does not provide 
> gr-osmosdr for GNU Radio 3.8.0.0, you will have to build it by yourself 
> (installing gr-osmosdr for a wrong version of GNU Radio may cause you 
> troubles).
> 
> See https://osmocom.org/projects/gr-osmosdr/wiki and 
> https://osmocom.org/issues/3855 if you experience troubles in building and 
> installing gr-osmosdr.
> 
> Regards,
> Kyeong Su Shin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Kyeong Su Shin]

Hello Jean Pierre:

You will have to install gr-osmosdr. If your repository does not provide 
gr-osmosdr for GNU Radio 3.8.0.0, you will have to build it by yourself 
(installing gr-osmosdr for a wrong version of GNU Radio may cause you troubles).

See  https://osmocom.org/projects/gr-osmosdr/wiki and 
https://osmocom.org/issues/3855 if you experience troubles in building and 
installing gr-osmosdr.

Regards,
Kyeong Su Shin





보낸 사람: Jean Pierre Mallet  대신 Discuss-gnuradio 

보낸 날짜: 2019년 8월 14일 수요일 오후 6:17
받는 사람: discuss-gnuradio@gnu.org 
제목: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml


GNURadio v 3.8.0.0 runs on Ubuntu 18.04 LTS.

We lost the sources! How to find Osmocom source and Osmocom Sink, as well as 
Rtlsdr source?

Easily.

Thank you for the answer

Jean Pierre

 Apprenez à prononcer

Provenance : Courrier pour 
Windows 10


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Computation of RFNoC Blocks in GRC

[Derek Kozel]

Hi Felix,

The USRPs use signed complex 16 bit integers internally in the FPGA.
These are converted (optionally!) to signed compled 32 bit floating
point numbers on the host pc by UHD. The format actually sent over
USB/Ethernet is called the Over The Wire format and the format that the
user code facing is the CPU format.
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html

These conversions are scaling operations, multiplication. Which is why
your multiplication on the FPGA works as you expect it to. Addition on
the FPGA must be scaled as you found, using the know ledge that a 16 bit
signed integer will be converted to/from a floating point number and
normalized to +-1.

You can set the number formats in the USRP Source and Sink blocks, I
forget if the RFNoC blocks also support that in GNU Radio Companion, but
you can certainly do it in the underlying Python and C++.

Cheers,
Derek

On 13/08/2019 14:12, Felix Greiwe wrote:
> Hello together,
>
> I recently created some RFNoC-Blocks using the RFNoC Modtool and an USRP
> x310 from ETTUS for future GRC application. My Simulation in Vivado went
> well and thus I built an FPGA-Image and flashed it to my USRP x310 device.
> In GRC however, I witnessed very strange behaviour considering addition
> operations of my blocks, so I went back to the most simple functioning
> block, the RFnOC gain block from the RFNoC getting started page:
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
> (All Source Files are linked at the bottom of that page, no need to read
> anything to understand my problem)
>
> What that block does, is to receive a signal from GNURadio, split it into
> I and Q Phase and multiply it by a constant value inside the FPGA of the
> USRP. The outgoing signal is then the product of input and constant, for
> example 0.1*5 = 0.5. Important in this case is, that the range of
> result_values are limited to [-1,1] by the fpga.
>
> To test addition instead of multiplication (which works), i edited one
> single line of the noc_block_gain.v file from
>
>  >> wire [31:0] i_mult_gain = i*gain;
>  >> wire [31:0] q_mult_gain = q*gain;
>
> to
>
>  >> wire [31:0] i_mult_gain = i+gain; // in_phase component (real)
>  >> wire [31:0] q_mult_gain = q*gain; // quadrature phase (imag)
>
> where gain is a 16 Bit register which can be adressed through GNURadio
> Companion.
>
> In GRC I created a simple flowgraph which generates a complex cosine with
> I and Q data samples, which then are prossessed by my modified gain block.
> I expected the Q-Phase to behave exactly like before, and get multiplied
> by the value in the gain register, and the I-Data to move upwoards in my
> GRC Time Sink by the value I add to it.
>
> Link to picture of Flowgraph:
> https://ibb.co/s2jSZtK
>
> While the expectations considering the multiplication got fulfilled, in
> the addition part I see no changes in my results. Only when i pump my gain
> up to great numbers (for example 1), i see a shift upwoards in my
> diagram. My final observation was, that the shift upwoards is close or
> equal to: "gain_value"/(2^15 -1).
>
> Results with "gain" of 5:
> https://ibb.co/7zJq2zx
>
> Results with "gain" of 26214 (~ (2^15 -1)*0.8):
> https://ibb.co/dtD6cJ7 (Put Q-Data to invisible here, to see I-Data better)
>
> At this point I have a few questions, I hope someone can answer:
>
>  - Why do the operations "multiplication" and "addition" differ in
> behaviour and how can I get my desired "normal" behaviour?
>
>  - At which point does GNURadio/RFNoC/theFPGA convert my signals to the
> range of [-1,1]? Is it always doing this with a fixed formula or only
> when the number exceeds the range? Any other information considering
> this?
>
> - Does it interpret my 16 Bit gain vector as a simple integer in the
> multiplication path and as something different,(maybe Q-Format) in the
> addition path? Why does it not simply add the value of my register to my
> signal?
>
> Any help is greatly appreciated, even when only parts get answered or when
> it addresses errors in my thougthprocess. I did my best to point out my
> problem, feel free to ask if you did not understand everything or my
> mediocre english is an obstacle here.
>
> Best regards and thank you reading,
>
> Felix Greiwe
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Jean Pierre Mallet]

GNURadio v 3.8.0.0 runs on Ubuntu 18.04 LTS.

We lost the sources! How to find Osmocom source and Osmocom Sink, as well as 
Rtlsdr source?

Easily.

Thank you for the answer

Jean Pierre
 Apprenez à prononcer
Provenance : Courrier pour 
Windows 10

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio