gr-gfdm

[Mike Sousa]

 i'm trying to execute gr-gfdm in gnuradio companion v3.10. There are a lot of 
Flowgraph errors out of the box. For example: Block : import_cyclic_prefix, 
Aspect : Param ‘Import’, Message : Import “from gfdm.pygfdm import 
cyclic_prefix” failed.  Any idea how to get the rest of the gr-gfdm package

Re: How to convert dB to dBm and dBFS in GNURadio with USRP X310 and UBX-160

[Marcus D. Leech]

On 05/07/2023 01:18, Dor Ratz wrote:

Hey Marcus

In my case I want to calibrate usrp with gnuradio as spectrum analyzer 
for the received signals.


By measuring the correction factor between power(dBFS) in GRC to 
power(dBm) in a laboratory spectrum analyzer of the received signal.


I used signal generator and in addition I've used my unique 
transmitting DUT.


 Do you think a noise source can be useful for my purpose?

Thanks a lot

Dor
I guess if your spectrum analyser is calibrated, then a calibrated noise 
source is redundant.




בתאריך יום ב׳, 3 ביולי 2023, 8:20 אחה״צ, מאת Marcus D. Leech 
‏:


On 03/07/2023 12:24, Dor Ratz wrote:

How are you Marcus?

First, thanks a lot.

I've done measurements for a specific Gain, frequency, temperature.
I've transmitted from a signal generator CW signal -> power
splitter 1:2 to( spectrum analyzer and the USRP X310).
I first transmitted a CW, and then I transmitted another my
system unique signal.

Can you please elaborate why you have suggested to use noise
source? I'm familiar with using it for Noise Figure measurements
of DUT by using Y Factor method, but I want to calibrate the
power of signal between Power[dBFS] in GRC to Power[dBm]
presented in spectrum analyzer.

Because a noise source is often better-calibrated than a
narrowband signal generator, and it kind of depends on what level
  of spectral detail you want calibrated.   If you want
calibration steps every few kHz, then a siggen may be a better fit.



I used RMS for [linear voltage] and after that 20*log(linear
voltage) to get Power[dBFS].
I understand that in the GNURadio flow graph everything
is float-point values in the range {-1.0,+1.0} and so I
calculated power[dBFS] according to 20*log10(1)=0[dBFS]

I think the calibration was OK and I've found the correction
factor between Power[dBFS] in GNURadio to the Power[dBm] received
in RX ANT connector as was displayed in the spectrum analyzer at
the same time by using power splitter.

As for saving complex\short to File Sink I'll update.

Thanks
Dor

image.png

‫בתאריך יום ד׳, 28 ביוני 2023 ב-23:43 מאת ‪Marcus D. Leech‬‏
<‪patchvonbr...@gmail.com‬‏>:‬

On 28/06/2023 16:35, Dor Ratz wrote:

Hey Marcus,

Thanks.

Let me see if I get it right.

Please see the attached gnuradio setup below .

1. Does the USRP pass with Wire Format=Automatic the int16
samples to the host computer? The ADC of X310 is 14 bits
represented by 16 bits samples, so the maximal possible
value in time domain for a strong enough signal is 2^(14-1)=
(+-8192 ) ?

NO!  I've already said, the samples from the ADC are *scaled*
before they hit the wire, into the wire format, which in this
case
  is sc16.    Further, the samples that "hit the wire" are
*after* any manipulations by the DDC.  The values on the wire
  can go from +/- 32767, although they rarely actually do.


2. So if I open the file sink (which was saved as short =
int16) with python as int16 and look in python in the time
domain:

  * In the time domain the maximal possible value is still
(+-8192 ) ?


Once the samples hit the GR flow-graph they are typically in
{-1.0,+1.0}, and then you can specify scaling coefficients when
  you save them as complex int16.


  * In FFT, can I  calculate Power[dBFS] according to
20*log10(8192)=0[dBFS]?


I strongly suspect that you're trying to do power estimation
based on an empirical model, rather than by actual measurement
  with actual calibration equipment present.    I have
already said this is a bad approach, as have many others on
this list.




3. If I want to open samples in QT GUI Sink as in the setup
below, then can I do it as below with IShort to Complex
block with scale factor = 8192, and then in the time domain
in QT GUI Sink I will see :

  * In time domain - a float value with maximal possible
value of (-+1) ? because it was normalized by 8192.
  *  In FFT , can I  calculate Power[dBFS] according to
20*log10(1)=0[dBFS]?


Thanks you,

Dor


image.pnghugh

image.png


image.png


image.png


‫בתאריך יום ב׳, 26 ביוני 2023 ב-21:46 מאת ‪Marcus D. Leech‬‏
<‪patchvonbr...@gmail.com‬‏>:‬

On 26/06/2023 14:43, Dor Ratz wrote:

Thanks Marcus.

If so, then I can calibrate USRP -> GNURadio by writing
down the :

- Power of the signal in FFT in [dB] -> convert to
[dBm] by comparing power when connected to a spectrum
analyzer and changing Gain, frequency and so on and
comparing

Re: How to convert dB to dBm and dBFS in GNURadio with USRP X310 and UBX-160

[Dor Ratz]

Thanks a lot Marcus

Dor

בתאריך יום ד׳, 5 ביולי 2023, 7:33 אחה״צ, מאת Marcus D. Leech ‏<
patchvonbr...@gmail.com>:

> On 05/07/2023 01:18, Dor Ratz wrote:
>
> Hey Marcus
>
> In my case I want to calibrate usrp with gnuradio as spectrum analyzer for
> the received signals.
>
> By measuring the correction factor between power(dBFS) in GRC to
> power(dBm) in a laboratory spectrum analyzer of the received signal.
>
> I used signal generator and in addition I've used my unique transmitting
> DUT.
>
>  Do you think a noise source can be useful for my purpose?
>
> Thanks a lot
>
> Dor
>
> I guess if your spectrum analyser is calibrated, then a calibrated noise
> source is redundant.
>
>
> בתאריך יום ב׳, 3 ביולי 2023, 8:20 אחה״צ, מאת Marcus D. Leech ‏<
> patchvonbr...@gmail.com>:
>
>> On 03/07/2023 12:24, Dor Ratz wrote:
>>
>> How are you Marcus?
>>
>> First, thanks a lot.
>>
>> I've done measurements for a specific Gain, frequency, temperature.
>> I've transmitted from a signal generator CW signal -> power splitter 1:2
>> to( spectrum analyzer and the USRP X310).
>> I first transmitted a CW, and then I transmitted another my system unique
>> signal.
>>
>> Can you please elaborate why you have suggested to use noise source? I'm
>> familiar with using it for Noise Figure measurements of DUT by using Y
>> Factor method, but I want to calibrate the power of signal between
>> Power[dBFS] in GRC to Power[dBm] presented in spectrum analyzer.
>>
>> Because a noise source is often better-calibrated than a narrowband
>> signal generator, and it kind of depends on what level
>>   of spectral detail you want calibrated.   If you want calibration steps
>> every few kHz, then a siggen may be a better fit.
>>
>>
>> I used RMS for [linear voltage] and after that 20*log(linear voltage) to
>> get Power[dBFS].
>> I understand that in the GNURadio flow graph everything is float-point
>> values in the range {-1.0,+1.0} and so I calculated power[dBFS] according
>> to 20*log10(1)=0[dBFS]
>>
>> I think the calibration was OK and I've found the correction factor
>> between Power[dBFS] in GNURadio to the Power[dBm] received in RX ANT
>> connector as was displayed in the spectrum analyzer at the same time by
>> using power splitter.
>>
>> As for saving complex\short to File Sink I'll update.
>>
>> Thanks
>> Dor
>>
>> [image: image.png]
>>
>> ‫בתאריך יום ד׳, 28 ביוני 2023 ב-23:43 מאת ‪Marcus D. Leech‬‏ <‪
>> patchvonbr...@gmail.com‬‏>:‬
>>
>>> On 28/06/2023 16:35, Dor Ratz wrote:
>>>
>>> Hey Marcus,
>>>
>>> Thanks.
>>>
>>> Let me see if I get it right.
>>>
>>> Please see the attached gnuradio setup below .
>>>
>>> 1. Does the USRP pass with Wire Format=Automatic the int16 samples to
>>> the host computer? The ADC of X310 is 14 bits represented by 16 bits
>>> samples, so the maximal possible value in time domain for a strong
>>> enough signal is 2^(14-1)= (+-8192 ) ?
>>>
>>> NO!  I've already said, the samples from the ADC are *scaled* before
>>> they hit the wire, into the wire format, which in this case
>>>   is sc16.Further, the samples that "hit the wire" are *after* any
>>> manipulations by the DDC.  The values on the wire
>>>   can go from +/- 32767, although they rarely actually do.
>>>
>>>
>>> 2. So if I open the file sink (which was saved as short = int16) with
>>> python as int16 and look in python in the time domain:
>>>
>>>- In the time domain the maximal possible value is still (+-8192 ) ?
>>>
>>> Once the samples hit the GR flow-graph they are typically in
>>> {-1.0,+1.0}, and then you can specify scaling coefficients when
>>>   you save them as complex int16.
>>>
>>>
>>>- In FFT, can I  calculate Power[dBFS] according to
>>>20*log10(8192)=0[dBFS]?
>>>
>>> I strongly suspect that you're trying to do power estimation based on an
>>> empirical model, rather than by actual measurement
>>>   with actual calibration equipment present.I have already said this
>>> is a bad approach, as have many others on this list.
>>>
>>>
>>>
>>> 3. If I want to open samples in QT GUI Sink as in the setup below, then
>>> can I do it as below with IShort to Complex block with scale factor = 8192,
>>> and then in the time domain in QT GUI Sink I will see :
>>>
>>>- In time domain - a float value with maximal possible value of
>>>(-+1) ? because it was normalized by 8192.
>>>-  In FFT , can I  calculate Power[dBFS] according to
>>>20*log10(1)=0[dBFS]?
>>>
>>>
>>> Thanks you,
>>>
>>> Dor
>>>
>>>
>>> [image: image.png]hugh
>>>
>>> [image: image.png]
>>>
>>>
>>> [image: image.png]
>>>
>>>
>>> [image: image.png]
>>>
>>>
>>> ‫בתאריך יום ב׳, 26 ביוני 2023 ב-21:46 מאת ‪Marcus D. Leech‬‏ <‪
>>> patchvonbr...@gmail.com‬‏>:‬
>>>
 On 26/06/2023 14:43, Dor Ratz wrote:

 Thanks Marcus.

 If so, then I can calibrate USRP -> GNURadio by writing down the :

 - Power of the signal in FFT in [dB] -> convert to [dBm] by comparing
 power when connected to a spectrum analyzer and changing Gain, frequency

Re: Re: why udp source and sink not work effieciny in gnuradio?

[Jim Melton]

Also, you need a throttle between your file source and UDO sink or you will try 
to send as fast as the file can read (which is almost certainly faster than 
your network. 

And, high speed network I/O generally requires some kernel tuning. 

Sent from my iPhone

> On Jul 4, 2023, at 3:57 AM, Marcus Müller  wrote:
> 
> Exactly this. By choosing UDP, you chose to drop packets when they are not 
> handled in time.
> So, this is working 100% as expected.
> 
> Best regards,
> Marcus
> 
>> On 04.07.23 09:20, Fabian Schwartau wrote:
>> Hi,
>> my guess would be that the file source and UDP sink are much faster than the 
>> UDP source and QT GUI Sink. As UDP is "fire and forget", the "transmitter" 
>> may be pushing more data over the network than the QT GUI Sink can handle.
>> To test this, you can replace the QT GUI Sink with a NULL sink, which just 
>> deletes the data. Or you can add a throttle block after the File Source to 
>> reduce the data rate.
>> Best,
>> Fabian
>>> Am 04.07.23 um 09:07 schrieb sp:
>>> why do UDP source and sink not work efficiently in Gnuradio?
>>> I want to use a UDP  source and sink in Gnuradio, for a low sample rate of 
>>> 10k I see that there is too many packet drop. why network tools does not 
>>> work effectively?
>>> can anyone guide you? thanks in advance
>>> 
>>> *more info:*
>>> I set payload size 1408 I set send null pkt as true or false all  state I 
>>> had not a good response
>>> see the screenshot and log
>>> 
>>> Screenshot from 2023-07-04 10-30-22.png
>>> 
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet.
>>> gr::log :WARN: udp_source0 - Too much data; dropping packet

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are 
confidential, may contain proprietary, protected, or export controlled 
information, and are intended for the use of the intended recipients only. Any 
review, reliance, distribution, disclosure, or forwarding of this email and/or 
attachments outside of Sierra Nevada Corporation (SNC) without express written 
approval of the sender, except to the extent required to further properly 
approved SNC business purposes, is strictly prohibited. If you are not the 
intended recipient of this email, please notify the sender immediately, and 
delete all copies without reading, printing, or saving in any manner. --- Thank 
You.

Convert PDU message to a PMT message

[Barry Duggan]

I would like to receive a PDU message containing a string using an Embedded 
Python Block and, after discarding certain messages, send a PMT message with 
that string to the output message port. My efforts so far have not produced a 
valid PMT format. My current code is:

```

import numpy as np

from gnuradio import gr

import pmt

import array



class blk(gr.sync_block):

    def __init__(self):

    gr.sync_block.__init__(

    self,

    name='EPB: Packet to PMT',   # will show up in GRC

    in_sig=None,

    out_sig=None)

    self.message_port_register_in(pmt.intern('msg_in'))

    self.message_port_register_out(pmt.intern('msg_out'))

    self.set_msg_handler(pmt.intern('msg_in'), self.handle_msg)



    def handle_msg(self, msg):

    _debug = 0  # set to zero to turn off diagnostics

    try:

    buff = pmt.to_python(pmt.cdr(msg))

    b_len = len (buff)

    except Exception as e:

    gr.log.error("Error with message conversion: %s" % str(e))

    if (_debug):

    print ("new_val =", buff, b_len)

    if (b_len != 52):

    self.message_port_pub (pmt.intern('msg_out'), 
pmt.cons(pmt.PMT_NIL,pmt.to_pmt(buff)))

    elif ((buff[0] != 37) and (buff[51] != 93)):

    self.message_port_pub (pmt.intern('msg_out'), 
pmt.cons(pmt.PMT_NIL,pmt.to_pmt(buff)))

```



Any help will be appreciated!



---

Barry Duggan