Re: FFT Size and Signal & Vector Sources Amplitude Unit

[Marcus D. Leech]

On 09/03/2023 10:14, Wolfgang Wilde wrote:
In fact, in real world and with real measurement devices, the units 
are not related to "instantaneous voltages" and even lesser "voltages 
seen at the antenna". Any form of antenna may deliver different 
voltages. Is it some Yagi antenna? Or is the active element a closed 
loop? Both forms would differ totally in "antenna voltage" and both 
forms will transform the "antenna signal" over impedance 
transformation to for example some 75 Ohms impedance cable for 
consumer products or some 50 Ohms impedance cable when you have some 
TRX system. Real RF _measurements_ are all related to RF-power. Even 
the often used db/µV targets at a given power, as it only gives valid 
information when you also provide the impedance of your RF system. 
This means: talking about a signal of 40 dB/µV could be both, enough 
for FM receiption or to less for it, depending on what impedance (50 
Ohms/ 75 Ohms/ 240 Ohms?) you are refering to!


Never the less you do not have any SDR-Sticks out there with given 
sensitivity nummbers. Even the more expensive devices like HackRF and 
all the Ettus Research devices are not "measuring" some RF field 
strength. All you get is somehow a resulting numeric factor of how 
good the SDR can detect some signal. The sensitivity does vary widely 
over the frequency ranges of this devices and it is by no means really 
directly proportional to some RF power or even a voltage at the 
antenna port or your antenna. You may to some degree use SDR-Sticks or 
devices like HackRF, USRP's and so on for qualitative informations 
about a radio signal, but it won't tell you anything about the real 
power of a signal, as opposite to RF measurement systems! With all my 
devices (ranging from RTL2832 based sticks over HackRF and others) you 
get jumps in signal strength when you do a full band power scan. This 
happens for example, when the SDR hardware switches to some other 
oscillator setting. All of my devices can do a full band scan of at 
least 1 GHz or even more, but none of them can do it by just stepping 
up the Synthesizer PLL without for example using harmonics of the base 
PLL Frequency for mixing down to the IF band or Baseband. And for each 
time switching to another harmonic you get signal strength jumps. And 
with each other PLL frequency you might get other mixing products, 
ghosting from other frequencies and so on. So, the kind of SDR we 
refer to here can not give any numeric factors to RF power nor RF 
voltages. It is just a numeric value, somehow more or less 
proportional to the quality the SDR can receive the signal. No units, 
no absolute values at all.



Regards
I'll repeat this again, because you clearly didn't "get" it.   The 
numbers coming out of the signal-processing chain are
  *linearly proportional* to the instantaneous (as in at the moment the 
sample was taken by the ADC) voltage as seen
  at the antenna input to the receiver.   This says *NOTHING* about the 
antenna itself, nor whatever cabling and other

  bits-and-pieces are between the receiver input port and the antenna.

YES, the calibration constants will, absolutely, vary over the 
tuning/bandwidth/sample-rate capabilities of the receiver.
  But if they *ARE NOT* linearly-proportional (or mostly-so) to the 
instantaneous antenna-*PORT* input voltage, then we

  might as well all go home.

The samples that arrive into your flow-graph aren't some handy-wavy 
random thing that kinda-sorta represents the
  real world.  They are very-definitely a *linear proxy* for the 
instantaneous voltage as seen at the antenna input port
  at the time that it was sampled.  Again, if they aren't very close to 
this, then we might all just as well go home and

  take up basket-weaving.

What IS true about actual laboratory measurement instrumentation is that 
such instrumentation is *calibrated* over
  it's operating range (in as many steps as seems reasonable) to 
produce results that are directly-tied to physical units.


You can do EXACTLY THE SAME THING with even a cheap receiver like the 
RTL-SDR, HackRF, USRPs, LimeSDRs, etc, etc.
  In fact, USRPs (some of them) now have a *CALIBRATION INTERFACE AND 
API* that allows you to use them in the

  same way as you can use a laboratory instrument.

In MANY actual cases, you'd like your radio to be calibrated over some 
much-smaller range of its operating parameters--
  you'll be using it for perhaps a single application, where 
understanding what is appearing at the antenna input ports

  in terms of power or (by a bit of simple math, voltage) may be important.

In MY case, I calibrate in degrees-K of noise power, because that's 
relevant to my usage of these types of radios for

  radio astronomy.

Your post makes it seem like SDRs are delivering samples that bear only 
the weakest relationship to the physical world,

  and that just isn't true.  IT CAN'T BE.

Data flow stops in grc

[George Edwards]

Dear GNURadio Community,
I am using Ron's Github dvbs2 project that streams data  from Tx to Rx to
view the Star Wars clip. I am streaming qpsk data and his grc works fine. I
built 3 blocks that do RRC pulse shaping, timing and frame recovery. I
inserted my blocks between the transmitter and receiver and validate that
the qpsk data that goes into the first of my block is similar to the qpsk
data coming out of the last of my block by dumping the signals to file
sinks. On the receiver side the signal is fed to the LDPC Decoder which
expects a qpsk Constellation signal. The problem is that the Decoder does
not see the signal leaving my last block even though I can dump the signal
to a file sink and view it. I have complex output from my block connected
to complex input at Ron's Decoder.

I will appreciate any suggestion for a solution.

Regards,
George

Reverse engineering .py file grc

[George Edwards]

Hello GNURadio Community,


We are looking for a way to reverse engineer some Gnuradio Python blocks
that were created by folks no longer with our company to the corresponding
GRC files. Is anyone familiar with a tool that can do this for us?

Thank you!

Regards,
George

Re: File Meta Sink question

[Volker Schroer]

Hello,

I think your import statement should start with small letter i. Capital
letter I leads to the error message you described.

-- Volker
Am 09.03.23 um 17:06 schrieb Hassel, George:

Hello,

I'm having some difficulty with saving metadata.   I'm trying to use
File Meta Sink as a block in gnuradio companion, and I get an error
message in the Extra Dict. filed that "Value "pmt.make_dict()" cannot be
evaluated: name 'pmt' is not defined.    I try to add in an Import block
that says Import pmt, and get an error that says "Param -
Import(imports): Bad import syntax: "pmt".

If I instead just use a python script with import pmt, I still get
errors involving the File Meta Sink blocks.

I tried to make sure that pmt was installed with pip3 install pmt, but
that causes an error with finding the paths for gnuradio.   I resolved
that by following the instructions at
https://wiki.gnuradio.org/index.php/ModuleNotFoundError
, but again
come back to the same errors involving pmt.

My Ubuntu version is 22.10
My gnuradio version is 3.10.3.0
My python3 version is 3.10.7

Thanks for any assistance you can provide!

-George Hassel

File Meta Sink question

[Hassel, George]

Hello,

I'm having some difficulty with saving metadata.   I'm trying to use File
Meta Sink as a block in gnuradio companion, and I get an error message in
the Extra Dict. filed that "Value "pmt.make_dict()" cannot be evaluated:
name 'pmt' is not defined.I try to add in an Import block that says
Import pmt, and get an error that says "Param - Import(imports): Bad import
syntax: "pmt".

If I instead just use a python script with import pmt, I still get errors
involving the File Meta Sink blocks.

I tried to make sure that pmt was installed with pip3 install pmt, but that
causes an error with finding the paths for gnuradio.   I resolved that by
following the instructions at
https://wiki.gnuradio.org/index.php/ModuleNotFoundError, but again come
back to the same errors involving pmt.

My Ubuntu version is 22.10
My gnuradio version is 3.10.3.0
My python3 version is 3.10.7

Thanks for any assistance you can provide!

-George Hassel

Re: FFT Size and Signal & Vector Sources Amplitude Unit

[Wolfgang Wilde]

In fact, in real world and with real measurement devices, the units are 
not related to "instantaneous voltages" and even lesser "voltages seen 
at the antenna". Any form of antenna may deliver different voltages. Is 
it some Yagi antenna? Or is the active element a closed loop? Both forms 
would differ totally in "antenna voltage" and both forms will transform 
the "antenna signal" over impedance transformation to for example some 
75 Ohms impedance cable for consumer products or some 50 Ohms impedance 
cable when you have some TRX system. Real RF _measurements_ are all 
related to RF-power. Even the often used db/µV targets at a given power, 
as it only gives valid information when you also provide the impedance 
of your RF system. This means: talking about a signal of 40 dB/µV could 
be both, enough for FM receiption or to less for it, depending on what 
impedance (50 Ohms/ 75 Ohms/ 240 Ohms?) you are refering to!


Never the less you do not have any SDR-Sticks out there with given 
sensitivity nummbers. Even the more expensive devices like HackRF and 
all the Ettus Research devices are not "measuring" some RF field 
strength. All you get is somehow a resulting numeric factor of how good 
the SDR can detect some signal. The sensitivity does vary widely over 
the frequency ranges of this devices and it is by no means really 
directly proportional to some RF power or even a voltage at the antenna 
port or your antenna. You may to some degree use SDR-Sticks or devices 
like HackRF, USRP's and so on for qualitative informations about a radio 
signal, but it won't tell you anything about the real power of a signal, 
as opposite to RF measurement systems! With all my devices (ranging from 
RTL2832 based sticks over HackRF and others) you get jumps in signal 
strength when you do a full band power scan. This happens for example, 
when the SDR hardware switches to some other oscillator setting. All of 
my devices can do a full band scan of at least 1 GHz or even more, but 
none of them can do it by just stepping up the Synthesizer PLL without 
for example using harmonics of the base PLL Frequency for mixing down to 
the IF band or Baseband. And for each time switching to another harmonic 
you get signal strength jumps. And with each other PLL frequency you 
might get other mixing products, ghosting from other frequencies and so 
on. So, the kind of SDR we refer to here can not give any numeric 
factors to RF power nor RF voltages. It is just a numeric value, somehow 
more or less proportional to the quality the SDR can receive the signal. 
No units, no absolute values at all.



Regards



Am 08.03.23 um 22:35 schrieb Marcus D. Leech:
On 08/03/2023 15:43, DİREN ERDEM AYDIN via GNU Radio, the Free & 
Open-Source Toolkit for Software Radio wrote:

Dear All,

Changing only FFT size of the freq sink block during simulation drops 
signal power drastically, screenshots are given in the attachments. I 
am providing the pulse burst from the vector source as 6144 points (6 
ones and the rest of the points are zero). Since FFT sink blocks show 
the average power of the points on freq domain, increasing FFT size 
would increase the number of zeros in the buffer so power is reduced.


What do you think about this approach, is it ok? and there are 
fluctuations in the 32k example, that's why it is thicker than 4k 
plot, what is the reason for this?


Moreover, no unit is written in vector or signal sources amplitude 
sections. Are units assumed as volts?


Regards,
dea



/Yasal Uyarı: MEF ÜNİVERSİTESİ bu mesajın içeriği ile ilgili hiçbir 
yasal sorumluluk taşımaz./
/Legal Disclaimer: MEF UNIVERSITY does not accept any legal liability 
or responsibility for the content of this message./
Units are *UTTERLY UNSCALED*, but Gnu Radio normally operates within 
{-1.0,+1.0} for floating-point values.


Most hardware drivers honor this system and scale their (complex, 
usually) samples appropriately--so those samples will
  be *linearly related* to the instantaneous *voltage* as seen at the 
antenna, but turning that into real-world values
  is up to the user, typically.    Gnu Radio itself has no idea what 
these samples *mean* in terms of the real world.
  Any actual hardware device will perform considerable analog (and 
then digital) signal processing on the antenna signals.
  So all that you know when you get those samples into Gnu Radio is 
that they're (mostly) linearly-related to an antenna voltage.