Re: USRP B210 Frequency Offset

[Marcus D. Leech]

On 15/05/2024 05:52, Moses Browne Mwakyanjala wrote:
I've encountered a consistent frequency offset of around 2ppm with my 
new B210. Operating at a sample rate of 4 MSPS with the "internal" 
clock, all calibrations were performed using a sine wave from an 
Agilent signal generator.


Though seemingly minor, the 800Hz offset at UHF poses challenges in 
receiving low-rate data from orbiting satellites. Is there an 
automated method to approximate and mitigate this offset? Currently, I 
manually adjust the frequency by subtracting the offset in ppm. 
However, I'm curious if there are more sophisticated solutions 
available, excluding reliance on GPS or a 10MHz reference.


Best regards,
Moses
The on-board clock on a B210 is good to about 2.5PPM.  So, it's working 
as you would expect.


There's nothing built in to the UHD API for this, because normally, if 
you care about clock accuracy beyond what the internal clock
  can supply, you use an external, better, clock.   GPSDOs are not very 
expensive these days, and you can pick up used

  10MHz OCXO units fairly cheaply as well...




image.png

Re: Period doesn't match for frequency sweeping using probe

[Marcus D. Leech]

On 03/05/2024 09:39, Huang Wei wrote:
I am actually trying to input this sweeping signal to a USRP sink 
(X310 + UBX 160) to let it sweep around its central frequency (e.g., 
200 MHz +/- 5 MHz). Do you have any suggestions for this configuration?


Thank you!
Wei
Sweeping the baseband is fine.  That should work.    My point was about 
re-tuning the hardware at those rates.





On Fri, 3 May 2024 at 14:27, Marcus D. Leech  
wrote:


On 03/05/2024 09:24, Huang Wei wrote:
> Hi Adrian and Marcus,
>
> That solved the problem : )
> Thank you very much for your help!
>
> Kind regards,
> Wei
You're welcome.

I'll note that your probe is operating at 10KHz.  Actual real radio
hardware will be unlikely to be able to
   re-tune at that rate, should you "graduate" to real hardware.

Re: Period doesn't match for frequency sweeping using probe

[Marcus D. Leech]

On 03/05/2024 09:24, Huang Wei wrote:

Hi Adrian and Marcus,

That solved the problem : )
Thank you very much for your help!

Kind regards,
Wei

You're welcome.

I'll note that your probe is operating at 10KHz.  Actual real radio 
hardware will be unlikely to be able to

  re-tune at that rate, should you "graduate" to real hardware.

Re: Period doesn't match for frequency sweeping using probe

[Marcus D. Leech]

On 03/05/2024 07:31, Adrian Winter wrote:


Hei Wei,

Try adding a Throttle block to the upper branch too. A quick test 
shows that if you have two independent data flow paths, the sample 
rate will be way too high (see log output in the lower left corner: 
rate is at 300 MS/s


Each independent sub-graph needs its own pacing mechanism.  Remember 
that Gnu Radio has no  *inherent* understanding
  of sample-rates.  They are usually an "artifice" added at the edges 
by hardware.  A throttle block provides that service

  when there's no hardware involved...

Re: B200-mini not detected thru GNU Radio

[Marcus D. Leech]

On 13/03/2024 16:13, Woods, Alex C wrote:

Hello,

I've constructed the Spectrum Analyzer as seen on this page (see 
following link to GNU radio wiki) in hopes to test the functionality 
of GNU radio's compatibility with the b200-mini I plan to use for a 
project:


https://wiki.gnuradio.org/index.php?title=Guided_Tutorial_Hardware_Considerations

Unfortunately, when I run execute the flow graph, I get:

RuntimeError: LookupError: KeyError: No devices found for -> Empty 
Device Address


and it doesn't run as intended. I've verified the connection of the 
device through UHD command uhd_find_devices (as well as several other 
commands), where it sees the b200-mini just fine, but GNU Radio isn't 
seeing it for some reason. The device is interfaced via USB.


This is similar to the error this StackExchange user encountered (see 
link below), but I was slightly confused on how to fix it with the 
advice provided in the highest-upvoted response.


https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for

If it has any effect on anything, I downloaded GNU Radio using the 
three lines at the top of the UbuntuInstall page on the wiki (linked 
below):


https://wiki.gnuradio.org/index.php/UbuntuInstall#:~:text=There%27s%20generally%20no%20need%20to%20build%20GNU%20Radio,for%20anyone%20who%20is%20new%20to%20GNU%20Radio.

I am new to GNU Radio as well as the operation of the b200-mini and 
SDRs in general. Help would be greatly appreciated!


Thanks,
Alex

Try:

"type=b200" in the device address field in your Gnu Radio UHD USRP source.

Re: uhd.find_devices() - AttributeError

[Marcus D. Leech]

On 05/03/2024 16:56, Trung Trieu wrote:

Hello all,

I've been having some issues with gnuradio 3.10 and still haven't 
figured it out yet. I'd really appreciate it if anyone could help me 
or have any pointers that I can follow.


For your reference, I have an Ubuntu 22 virtual machine running on 
VMware and installed gnuradio (as well as other dependencies) from the 
instructions at https://wiki.gnuradio.org/index.php/InstallingGR (I 
tried both installation methods via apt and via ppa but no luck).


The error message I have is:

-
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 
73, in find_devices
    return __builtins__['map'](to_pythonized_dev_addr, 
uhd_python.find_devices_raw(*args, **kwargs))
AttributeError: module 'gnuradio.uhd.uhd_python' has no attribute 
'find_devices_raw'. Did you mean: 'find_devices'?

-

Steps to reproduce:
1. Install gnuradio 3.10
2. From the command line, launch python3 by typing "python3"
    - >>> from gnuradio import uhd
    - >>> print(uhd.find_devices())
That's where the error occurs.

The content of 
'/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py' can also be 
found at 
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/python/uhd/__init__.py


Note that I don't have this issue with Ubuntu 20, which uses 
gruradio 3.8 and SWIG instead of PyBind11. So instead of 'uhd_python', 
it'll be 'uhd_swig' from the above error message. The code with 
gnuradio 3.8 can also be found at 
https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-uhd/python/uhd/__init__.py


Thank you all in advance!!
*Trung Trieu*
Ubuntu 20 has a much-older version of Gnu Radio AND a much-older (3.15) 
version of UHD.


Near as I can tell, gr-uhd doesn't expose find_devices() in gr-uhd, 
which is a wrapper for UHD specifically for Gnu Radio.

Re: Group name of python scripts generated by GRC

[Marcus D. Leech]

On 09/02/2024 09:04, Elof Wecksell via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:

You might be interested in the unix command newgrp, that can change the group 
id of your session such that new files greated should have this group.

The normal behavior for any program is to create files with the group of the 
current session. It would of course be possible for grc to have such an option 
but it seems like a very niche request.

/Elof
I'll note that changing the group ownership of a file is a privileged 
operation.    The "newgrp" command runs privileged in order
  to change your session group, and it confirms that the group you're 
changing to is one you're allowed to change to.


Now way in hades would it be a good idea for GRC to run privileged so 
that it could change file ownerships.


This class of question has ZERO to do with GRC and Gnu Radio, and MUCH 
more to do with "how to live and be a dev

  on Linux".

Re: Python Block : no access to code

[Marcus D. Leech]

On 01/02/2024 15:21, Paul Atreides wrote:

Tom:
1) This is really more of a Linux file system permissions issue, but I 
would guess that if you copy the EPY block to any directory in 
/home/user, you will be in good shape. If you still get the error, you 
may need to change the permissions of the actual python file, a quick 
Google search or stackoverflow will tell you how to do that.


When you place an embedded block in GNURadio companion, The block ID 
is automatically populated by default with the block type and an index 
(just like every other block),  because there are block contents for 
that particular index of the embedded block, a random stream 
characters is generated to associate the text file as the contents for 
that block. In GNURadio 3.10 you can change the generated name of the 
embedded block by editing the block ID field when you create the 
embedded block in GNURadio companion.


Hope this helps
Most apps that drop files in "/tmp" use file-name randomization to avoid 
collisions with other applications that may use "/tmp",
  and, indeed, other users.  Unix-family operating systems originated 
as multi-user systems, so with shared temporary directories
  like "/tmp" some mechanism for avoiding file-name collisions was 
developed.








On Feb 1, 2024, at 14:38, tom sutherland  wrote:


I am running a VirtualBox Ubuntu 22.043 with 
Radioconda/gnuradio-companion. I have a python block that I want to 
use but when I try to open it, I get the error */usr/bin/env: 
‘/tmp/epy_block_0_nlgw0hml.py’: Permission denied*. Its a 
directory/file that I don't have access to.

1)  How do I fix this issue?
2) Why does the Python Block, name = MyBlock, save anything to such a 
non-descriptive name like *epy_block_0_nlgw0hml.py* ?


Thanks...Tom

Re: Using RFNoC blocks for satellite systems

[Marcus D. Leech]

On 26/01/2024 17:28, Kevin McQuiggin wrote:

No it doesn’t!

Are we violently agreeing here?

The  B2xx family FPGAs aren't supported by the RFNOC toolchain, and 
they're not very big.  You could, probably "port"
  the RFNOC toolchain to these FPGAs, but my understanding is that it 
would be a lot of work.


Regardless, officially, RNOC IS NOT SUPPORTED on B2xx hardware.




Sent from my iPhone


On Jan 26, 2024, at 14:22, Marcus D. Leech  wrote:

On 26/01/2024 17:07, Daniel Estévez wrote:

Hi Yotam,

As far as I know, the B200 doesn't support RFNOC. From

https://www.ettus.com/sdr-software/rfnoc/

"all USRP devices from the third-generation on (X300 Series, E300 Series) are 
supported by RFNoC out-of-the-box".

Best,
Daniel.

This is the case, yes.  The FPGAs in the B2xx series aren't compatible with the 
RFNOC toolchain for one, and aren't really
   big enough to support the RFNOC framework inside the FPGA.



On 26/01/2024 21:04, יותם זיס wrote:
Hi everyone, I'm currently working on a bpsk modem for S-band communication 
with the Tevel and TAUSAT satellites. I recently started reading about RFNoc 
and it intrigued me for use in my project since I own a USRP B200. Would love 
some advice on whether or not to try this out and if so how to implement it 
correctly, thanks.

Attached - a picture of my flowgraph, currently the uplink is connected 
directly to the downlink but usually i use a lime mini for transmission.

Re: Using RFNoC blocks for satellite systems

[Marcus D. Leech]

On 26/01/2024 17:07, Daniel Estévez wrote:

Hi Yotam,

As far as I know, the B200 doesn't support RFNOC. From

https://www.ettus.com/sdr-software/rfnoc/

"all USRP devices from the third-generation on (X300 Series, E300 
Series) are supported by RFNoC out-of-the-box".


Best,
Daniel.
This is the case, yes.  The FPGAs in the B2xx series aren't compatible 
with the RFNOC toolchain for one, and aren't really

  big enough to support the RFNOC framework inside the FPGA.




On 26/01/2024 21:04, יותם זיס wrote:
Hi everyone, I'm currently working on a bpsk modem for S-band 
communication with the Tevel and TAUSAT satellites. I recently 
started reading about RFNoc and it intrigued me for use in my project 
since I own a USRP B200. Would love some advice on whether or not to 
try this out and if so how to implement it correctly, thanks.


Attached - a picture of my flowgraph, currently the uplink is 
connected directly to the downlink but usually i use a lime mini for 
transmission.

Re: 2 SDRs – Parallel Programming

[Marcus D. Leech]

On 05/01/2024 10:33, Jim Melton wrote:


This has less to do with GNU Radio and more to do with real-time 
programming .


A system is said to be real-time if the total correctness of an 
operation depends not only upon its logical correctness, but also upon 
the time in which it is performed.^[5] 
 
 Real-time systems, as well as their deadlines, are classified by the 
consequence of missing a deadline


Things that affect order of execution include:

  * The operating system scheduler
  o “Real-time” extensions are present in most Linux distros, but
require explicit enabling

;
more common scheduling strategies include “round robin”; for
precise scheduling, you would need a pre-emptive


strategy.
  o You may need to pin your process to a particular CPU (core)
  o Note that (depending on your hardware) a “sleep” function,
regardless of the requested delay, will not return in less
that 50us or so (this one surprised us recently).
  * Your hardware
  o in order for things to execute in parallel, there must be
parallel execution paths. Most modern CPUs have multiple cores
and threads within cores, so unless you are taxing your CPU
(possible) there should be compute paths available
  o Control of the radios is via some hardware port. If the two
devices use the same hardware (e.g., USB hub), there will be
some serialization

Simply put, real-time execution constraints are difficult to satisfy, 
and I would be surprised if a python GNU Radio application could 
achieve them. Maybe my brain is frozen in the past and it is very 
doable now, but that hasn’t been my experience.


---

*Jim Melton*


It has always come down to what is meant by "real time" and "happening 
at the same time".  It is the case these days that
  an ordinary OS on an ordinary CPU can satisfy what we might have 
called "soft real time" in the past without anything

  special.

In the case at hand, there's ZERO chance that the two threads will 
execute at exactly the same cadence, and that has very
  little to do with Gnu Radio and its implementation and more to do 
with operating system design and computing in
  general.   Throw in the additional complication of the connectivity 
hardware not necessarily being "parallel" -- if
  the two devices go through the same USB controller, the transactions 
will be serialized.


The "right" way to do what is wanted is using timed tuning, where you 
command both devices to tune at the same

  time *AS SEEN BY THE DEVICES*.  See:

https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD

There are two complications here:

  (A)  I don't know how well timed commands are really integrated into 
gr-uhd for applications originating in GRC
  (B)  The PLL synthesizers in the B2xx series are not known to be 
super-fast, with tuning latency of 100ms not
 being particularly unusual.  Indeed, PLL synthesizers in 
general aren't always that fast, although the AD936x

 series are among the slowest.

Re: Doppler

[Marcus D. Leech]

On 02/01/2024 05:01, Daniel Estévez wrote:

By the way,

Just for fun, there is this paper about what Doppler drift rates are 
physically meaningful in RF. This topic comes up when doing de-drift 
in narrowband SETI searches:


https://arxiv.org/pdf/1910.01148.pdf

Some of the objects at the bottom of Table 2 do indeed exceed 10 GHz/s 
even for S-band carrier frequencies. But these are crazy situations, 
such as a transmitter orbiting a neutron star very close to its surface.
Orbiting a transmitter around a neutron star, as one does for 
entertainment.  Or perhaps as a final-year project when attending

  Galactic University




Best,
Daniel.

On 01/01/2024 22:11, Marcus Müller wrote:

Liya,

Doppler shift Δf is proportional to both speed and carrier frequency 
/f/₀


Δ/f/ = /f/₀ · /v///c/₀,

where /v/ is the relative speed of your thing, and /c/₀ is the speed 
of light.


The highest frequencies we can, so far, do radio communications on, 
are in the range of f₀=150 GHz.


So, assuming you do communications on 150 GHz, for your Doppler shift 
to be Δ/f=/10 GHz higher after 1s, your acceleration must been


/a = /Δ/f / f/₀ · /c/₀ / 1s = 10 GHz / 150 GHz · 3·10⁸ m/s / s = 2/30 
· 3·10⁸ m/s² = 1/15 /c/₀/s.


The fastest object mankind has ever built is the Parker Solar Probe, 
which will burn up while it spirals into the sun, at a maximum 
velocity of ca 1/15 of the speed of light. It takes it years to reach 
that speed, not 1s.


So, you're assuming you're seeing a doppler from a satellite rotating 
around earth that sees a relative acceleration higher than a 
"satellite" around the sun actively being pulled into the sun by the 
sun's immense gravity.


That sadly makes no physical sense!

Best regards,
Marcus

On 01.01.24 07:51, Jiya Johnson wrote:

Yes I want to use 10GHz/s

On Sat, Dec 30, 2023, 4:05 PM Jiya Johnson  
wrote:


    Greetings everyone,
    https://github.com/daniestevez/reu-2023/tree/main/doppler
    I went through these grc files and tried to do drift_simulation, i
    am not getting the way to get 10GHz/s using inspectrum and
    frequency sink slope calculation i have attached the grc and
    screenshots.
    image.png
    image.png

Re: Doppler

[Marcus D. Leech]

On 01/01/2024 16:11, Marcus Müller wrote:


Liya,

Doppler shift Δf is proportional to both speed and carrier frequency /f/₀

Δ/f/ = /f/₀ · /v///c/₀,

where /v/ is the relative speed of your thing, and /c/₀ is the speed 
of light.


The highest frequencies we can, so far, do radio communications on, 
are in the range of f₀=150 GHz.


So, assuming you do communications on 150 GHz, for your Doppler shift 
to be Δ/f=/10 GHz higher after 1s, your acceleration must been


/a = /Δ/f / f/₀ · /c/₀ / 1s = 10 GHz / 150 GHz · 3·10⁸ m/s / s = 2/30 
· 3·10⁸ m/s² = 1/15 /c/₀/s.


The fastest object mankind has ever built is the Parker Solar Probe, 
which will burn up while it spirals into the sun, at a maximum 
velocity of ca 1/15 of the speed of light. It takes it years to reach 
that speed, not 1s.


So, you're assuming you're seeing a doppler from a satellite rotating 
around earth that sees a relative acceleration higher than a 
"satellite" around the sun actively being pulled into the sun by the 
sun's immense gravity.


That sadly makes no physical sense!

Best regards,
Marcus


I, ahem, can't math tonight!

Parker solar probe in its death-spiral will achieve 692000km/h (Note: 
per *hour*)  C=299792 km/s (Note: *second*).


So, 692,000/3600 = 192km/s

Which is 0.0006C, or about two orders of magnitude slower than my 
previous calculation...


However, that does NOT negate the point that simulating doppler of 
10GHz/s for "satellites" makes no physical sense at
  all.   We don't know how to move physical objects anywhere close to 
that fast, and we sure as heck don't know how to
  *accelerate* massy physical objects like that.   Objects in earth 
orbit have quite leisurely (relative to C) velocities.  The same is
  true of any of the deep-space probes humans have launched.  The one 
exception is the Parker Solar probe, but it will
  only reach nail-biting speeds near the end of its mission, and even 
*those* are decidedly leisurely compared to C.


Now, maybe this is all about searching for aliens making little tourist 
trips into near-earth space or something.  I dunno.
  I have to imagine that any object with non-trivial mass accelerating 
at those rates would leave signatures other

  that a silly little doppler signature, but what do I know?

Re: Doppler

[Marcus D. Leech]

On 30/12/2023 13:27, Daniel Estévez wrote:

Hello Jiya,

10GHz/s is a huge drift rate, unless it is for chirped radar or 
something similar. Did you really mean to use 10GHz/s?


Best,
Daniel.
"Ah, Houston, we're approaching the Black Hole, and speed says 0.C.  
Houston?  Houston?  Mom?"




On 30/12/2023 11:35, Jiya Johnson wrote:

Greetings everyone,
https://github.com/daniestevez/reu-2023/tree/main/doppler 

I went through these grc files and tried to do drift_simulation, i am 
not getting the way to get 10GHz/s using inspectrum and frequency 
sink slope calculation i have attached the grc and screenshots.

image.png
image.png

Re: controlling gain of USRP Sink

[Marcus D. Leech]

On 15/12/2023 15:58, Manuel Caldas wrote:


Hi all,

I am using an Ettus b200 mini for transmitting a tone at 4GHz (which 
in turn feeds a radiometer), through a signal source block and a USRP 
Sink. Also in my flowgraph I have a Qt GUI Range for manually setting 
the USRPs Gain. I manually change the gain and see perfectly in a 
fosphor sink how the power spectrum changes accordingly.


What I now want to do is to make the Gain follow a gaussian evolution 
over time (a single pulse is fine), which of course is not practical 
nor accurate to accomplish by manually changing the gain slider.


So, is there any way to achieve this? I'm using grc 3.10.8.0 (Python 
3.11.6) on a win 10 PC.


(btw, what I am actually trying to do is to simulate the transit of a 
radioastronomical point signal in front of an antenna, and see how my 
radiometer responds to that).


Best regards and thanks in advance!

/Manuel


I would instead of changing the RF gain, change the baseband magnitude 
over time -- probably using a custom embedded

  Python block -- if the sample rates aren't too high.

Re: MPM problem

[Marcus D. Leech]

On 22/11/2023 16:42, Alejandra Medina Díaz wrote:
I'm starting using USRP X440 with a fm receiver I used before with 
others USRPs, but when I execute the .grc I got:


Generating: '/home/lab03/Downloads/analizer1.py'

Executing: /usr/bin/python3 -u /home/lab03/Downloads/analizer1.py
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; 
UHD_4.2.0.1-0-g321295fb
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=10.182.30.35,type=x4xx,product=x410,serial=32B5D9F,fpga=X4_200,claimed=False,addr=10.182.30.35
[ERROR] [MPMD] MPM minor compat number mismatch. Expected: 4.2 Actual: 
4.0. Please update the version of MPM on your USRP device.

Traceback (most recent call last):
  File "/home/lab03/Downloads/analizer1.py", line 392, in 
main()
  File "/home/lab03/Downloads/analizer1.py", line 370, in main
tb = top_block_cls()
  File "/home/lab03/Downloads/analizer1.py", line 87, in __init__
self.uhd_usrp_source_0 = uhd.usrp_source(
RuntimeError: RuntimeError: MPM minor compat number mismatch. 
Expected: 4.2 Actual: 4.0. Please update the version of MPM on your 
USRP device.


I already checked the manual from this link 
https://files.ettus.com/manual/page_usrp_x4xx.html and I could do some 
but not the expected, now I got Actual:5.3.

Two things:

This question belongs on the usrp-users mailing list, not here.

The lowest version of UHD that supports the X440  (as opposed to X410) 
is UHD 4.5.0.0

Re: Code::Blocks and FIR pm_remez algorithm

[Marcus D. Leech]

On 01/10/2023 01:06, Nic Bretz wrote:
Thanks for taking the time to reply. Frankly, I don't know what I 
don't know, even after hours of online searches.


I've never seen an instance in an IDE where some folders are 
displaying and others, at the same level, are not. For somebody like 
me, new to GNU radio and CB, it's impossible to know if the issue is a 
quirk of the IDE or the software.


I've chosen CB because that's what I read about in the wiki. I tried 
VS Code but I couldn't get it to build, let alone run. At least CB builds.


The GNU Radio wiki is quite informative. For users. There is hardly 
anything in there for developers. I know, we figure out things, 
eventually. Except when we get stuck and run in circles. I spent hours 
of my spare time trying to get basic things to work, hours that I 
actually wanted to spend on algorithms.
Since Gnu Radio is *primarily* a *development framework* for developers 
of signal-processing software, one could argue
  that the entirety of the documentation is aimed at developers. I'll 
just pick some random examples:


https://wiki.gnuradio.org/index.php/BlocksCodingGuide

https://wiki.gnuradio.org/index.php?title=Creating_C%2B%2B_OOT_with_gr-modtool

https://wiki.gnuradio.org/index.php?title=Creating_Your_First_Block

Gnu Radio uses a bunch of underlying tools, like C++ and its compilers, 
Python, CMake, make, pybind11, etc, etc, etc.  What
  you WONT find is detailed tutorials on each of those tools within the 
Gnu Radio documentation hierarchy.   Information on each
  of those tools is better served in other forums, and, like most Open 
Source projects, Gnu Radio has limited resources.  It would be,
  quite honestly, wasteful of those resources to provide detailed 
tutorials on each of the tools that the Gnu Radio project uses.


I don't know why Code::Blocks isn't "seeing" the Gnu Radio code tree.  
That, I'm nearly 100% certain, isn't the fault of
  the Gnu Radio code tree.  There's nothing particularly "special" 
about it.   It is, after all, just a hierarchy of files, like
  any other file hierarchy in the history of ever.  If your editor of 
choice cannot see that hierarchy, it is likely not the

  fault of said hierarchy, at least, in my experience.




Anyway, sorry for the rant.

*From:* discuss-gnuradio-bounces+ayodha=hotmail@gnu.org 
 on behalf of 
Marcus D. Leech 

*Sent:* Saturday, September 30, 2023 9:11 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: Code::Blocks and FIR pm_remez algorithm
On 30/09/2023 22:42, N B wrote:

Helo,

I was looking at the FIR algorithm in pm_remez.cc and saw it is based 
on the old Janovetz implementation of Parks-McClellan. The author of 
one of my DSP books, Andreas Antoniou, makes the statement that he 
improved on the original Parsk-McClellan algorithm. I found another 
paper online where the author makes a similar statement.


I have no idea how accurate those statements are, but I am going to 
experiment with those algorithms. I'll make those initial experiments 
outside GNU Radio and if something good ever comes out of it, I would 
like to modify pm_remez.cc with the new algos, even if only for my 
personal use.


I'm getting to my issues, which I guess are really basic, but I'm new 
to Code::Blocks.


I created the .cbp file and opened the project in Code::Blocks. I was 
trying to trace the entire path from gr_filter_design to pm_remez.cc 
and wasn't getting anywhere.


When I look under the folder gr-filter, I see only two subfolders, 
lib and python. Eventually I looked in Github and there I could see 
several more subfolders under gr-filter, which I don't have in CB. (I 
couldn't be more grateful for the ability to search definitions and 
references in Github. I was able to trace the entire path in a few 
minutes)


My questions in order of importance are:

Why don't those folders display in CB?
Is it possible to Run the entire project in CB? It builds fine, but 
it just doesn't run.


Thanks,
Nic
Your question is a bit like asking George Lucas why the BluRay copy of 
Episode IV won't play in your machine


This isn't the Code::Blocks support mailing list, so my guess is that 
your question would be better asked in a more appropriate
  group.  There are literally *dozens* of editing/IDE environments 
that people use to work on Gnu Radio code.

Re: Code::Blocks and FIR pm_remez algorithm

[Marcus D. Leech]

On 30/09/2023 22:42, N B wrote:

Helo,

I was looking at the FIR algorithm in pm_remez.cc and saw it is based 
on the old Janovetz implementation of Parks-McClellan. The author of 
one of my DSP books, Andreas Antoniou, makes the statement that he 
improved on the original Parsk-McClellan algorithm. I found another 
paper online where the author makes a similar statement.


I have no idea how accurate those statements are, but I am going to 
experiment with those algorithms. I'll make those initial experiments 
outside GNU Radio and if something good ever comes out of it, I would 
like to modify pm_remez.cc with the new algos, even if only for my 
personal use.


I'm getting to my issues, which I guess are really basic, but I'm new 
to Code::Blocks.


I created the .cbp file and opened the project in Code::Blocks. I was 
trying to trace the entire path from gr_filter_design to pm_remez.cc 
and wasn't getting anywhere.


When I look under the folder gr-filter, I see only two subfolders, lib 
and python. Eventually I looked in Github and there I could see 
several more subfolders under gr-filter, which I don't have in CB. (I 
couldn't be more grateful for the ability to search definitions and 
references in Github. I was able to trace the entire path in a few 
minutes)


My questions in order of importance are:

Why don't those folders display in CB?
Is it possible to Run the entire project in CB? It builds fine, but it 
just doesn't run.


Thanks,
Nic
Your question is a bit like asking George Lucas why the BluRay copy of 
Episode IV won't play in your machine


This isn't the Code::Blocks support mailing list, so my guess is that 
your question would be better asked in a more appropriate
  group.  There are literally *dozens* of editing/IDE environments that 
people use to work on Gnu Radio code.

Re: FM Carrier Recovery for AOA Calculation

[Marcus D. Leech]

On 01/09/2023 16:39, Marcus Müller wrote:
Ah, nice! yeah, then this would work – but! any oscillator has drift, 
so two local oscillators will not stay on the same phase for long; if 
your first couple measurements are correct, but suddenly your 
directions become very wrong, that's what I'd investigate.


Cheers,
Marcus
Looks like the BB60C supports an external 10MHz reference clock, which 
would be utterly mandatory for anything requiring
  mutual phase-coherence, whether that's *sufficient* depends very very 
much on the internal architecture of the BB60C.





On 01.09.23 19:16, Michael Berman wrote:
The gr-aoa module has a calibration phase where you connect a source 
with a splitter and roughly equally lengthened cables to the two 
sources and it cross-correlates the two inputs to determine an 
initial phase difference.  Then, while the script is still running, 
you disconnect the calibration source and connect the antenna's, 
again with roughly equally lengthened cables to run the MUSIC algorithm.



Thank you very much,

Michael Berman

On Fri, Sep 1, 2023 at 11:00 AM Marcus Müller 
mailto:marcus.muel...@ettus.com>> wrote:


    If you don't know the relative phase of your two receiver chains, 
how are you going to

    know the direction of a signal?

    On 01.09.23 17:37, Michael Berman wrote:

    Marcus,

    Thanks for the reply!  I apologize, the GR package is gr-aoa, 
not gr-music, and can

    be found here (https://github.com/MarcinWachowiak/gr-aoa
    ). The NOAA broadcast 
is a NBFM signal.     I am using 2 Signal Hound receivers 
(https://signalhound.com/products/bb60c/
    ) with 2 antennas 
spaced on a beam.  Do I
    need to synchronize the 2 receivers with an external clock, or 
should they be fine

    free running independently?


    Thank you very much,

    Michael Berman

    On Fri, Sep 1, 2023 at 9:25 AM Marcus Müller mailto:mmuel...@gnuradio.org>> wrote:

    Not familiar with the details of NOAA signalling, but isn't 
the carrier of an FM

    signal
    *the FM signal*?

    For a DoA estimate, you'd correlate the different receive 
chains with each other

    to get a
    phase; so, as long as the signals do have some bandwidth 
that makes the problem

    less
    ambiguous, it'd work with any signal. I'm sadly not familiar 
with gr-music (and

    can't find
    it on cgran.org ), but MUSIC works as long 
as the signals at

    the different receive antennas
    are correlated and noise is not. You do not have to 
preprocess your FM signal!


    Best,
    Marcus

    On 01.09.23 17:09, Michael Berman wrote:
    > Does anybody know if there is a way to recover a carrier 
of an FM signal to

    use for an
    > Angle of Arrival calculation?  I am using GNURadio and 
gr-music and I am

    trying to use the
    > NOAA Weather Radio signals.
    >
    > Thank you very much,
    >
    > Michael Berman

Re: compiling gr-limesdr error

[Marcus D. Leech]

On 13/08/2023 14:55, robin ivetic wrote:

Hello,

I try to install gr-limesdr on arch linux true pacman, but after 
gnuradio upgrade on 3.10.7, can't do that any more, and compiling 
gr-limesdr gives me this, and files are there


CMake Warning (dev) at /lib/cmake/gnuradio/GrPython.cmake:21 
(find_package):
 Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs 
modules

 are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
 the cmake_policy command to set the policy and suppress this warning.

Call Stack (most recent call first):
 /lib/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
 CMakeLists.txt:77 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /lib/cmake/gnuradio/GrPython.cmake:27 
(find_package):
 Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs 
modules

 are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
 the cmake_policy command to set the policy and suppress this warning.

Call Stack (most recent call first):
 /lib/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
 CMakeLists.txt:77 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Extracting version information from git describe...
-- Found pybind11: //include (found version "2.11.1")
-- Configuring LimeSuite C++ Libraries...
CMake Error at /lib/cmake/LimeSuite/LimeSuiteConfig.cmake:49 (message):
 cannot find LimeSuite includes in //include
Call Stack (most recent call first):
 CMakeLists.txt:135 (find_package)

I have LimeSDR-USB, and when I'm using osmosdr sink block or Soapy 
LimeSDR sink below 30MHz, I'm geting this error, explained great here 
,and 
question is more for Myriadrf



MCU error 3 (SXR tune failed) on LimeSDR USB 

Hi! I wanted to check LimeGPS project, but was unable to do this. 
Right now I’m facing calibration issues when running it: Opening and 
initializing device... Reference clock 30.72 MHz Sample rate: 
250.0 Hz (Host) / 250.0 Hz (RF) Calibrating... Tx Calibration: 
MCU error 3 (SXR tune failed) Warning: Failed to calibrate device: Tx 
Calibration: MCU error 3 (SXR tune failed) Setup TX stream... Creating 
GPS task... Using static location mode. xyz = 1335616.6, -4648136.6, 
4144388.5 llh =...

discourse.myriadrf.org

//


MCU error 3 (SXR tune failed) on LimeSDR USB

but in my case, I will get error when I use more than 11.2e6 bandwith, 
that would be reason why I tried with gr-limesdr, but don't know how 
to bypass error.
Or maybe someone can comment error to bypass error bellow 30MHz, 
because issue is here for a long time, or did someone tried emulate 
limeSDR USB with USRP 200


Robin

gr-limesdr hasn't been maintained in nearly 4 years.  It isn't 
compatible with GR 3.10.X

Re: B2xx round trip delay

[Marcus D. Leech]

On 13/08/2023 00:36, Ali G. Dezfuli wrote:

Hi all,
I'd like to measure the round-trip delay (RTD) between two B200 USRPs. 
For that, I send a raised-cosined-filtered, BPSK modulated 
PN-sequence, and as soon as
I get this signal at the receiver, send back the same sequence from 
the Rx to the Tx, and by correlation, I find the RTD.
The question is that the measured RTD is not fixed. I wonder how can I 
make it fixed when the distance between the two USRPs is fixed.
After that (A -> B -> A) I want to do that in reverse order (B -> A -> 
B) and expect to have the same RTD.

Thanks
In your scenario, the latency will necessarily be variable--after all 
your samples are entering a computer program where those
  samples are processed and then sent back in the other direction. 
Since computer software on a general-purpose operating
  system cannot have fixed latency at fine-grained levels, this is 
completely expected.


This document may help:

https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD

Re: Rolling QT GUI Time Sink?

[Marcus D. Leech]

On 01/08/2023 22:41, Derek Kozel wrote:
There used to be the WX Strip chart which internally handled 
displaying slow signals and scrolling them. I keep hoping to implement 
it, but haven't yet made the time.

I wrote that WX feature "back in the day".

One can achieve the same effect by using the vector sink and having a 
Python block that produces the correct vector
  on the appropriate schedule.    Not as slick as have a "first class" 
implementation,  but I've been using that to produce

  strip-charts for quite a while.




https://github.com/gnuradio/gnuradio/issues/1629

On 7/19/2023 7:59 PM, Marcus Müller wrote:

Hi Fabian,

I'm afraid we currently don't have that, no :(

Best I can offer is the "new" throttle block, which can, at lower 
rates, make "blocks" of items appear in pieces smaller than a full 
maximum buffer size (i.e., that solves the problem that if 10s of 
samples fit in a buffer, GNU Radio will possibly only process a block 
of items every 10s, which makes e.g. the Qt time sink "stutter" very 
badly.)


Best,
Marcus!

On 19.07.23 18:09, Fabian Schwartau wrote:

Hi,
is there a way in GRC to get a rolling time sink?
That means no trigger, the signal just scrolls from right to left.

Best,
Fabian

Re: Total SDR Newbie

[Marcus D. Leech]

On 27/07/2023 10:41, Arnie Shore wrote:
While I have experience developing free, Open Source software in other 
environments like Computer-Aided Dispatch, Gnu radio has piqued my 
current interest.  Me and hardware haven't gotten along too well over 
the years -- I barely have a handle on Ohm's law -- but SDR  has my 
current attention.


I wonder if you can point me at interesting/useful postings/articles 
for me to get a handle on some practical examples.  Thanks, all.


AS

The Gnu Radio website has some tutorials:

https://wiki.gnuradio.org/index.php/Tutorials

Also, you'll likely want to give yourself some knowledge in radio in 
general, and for that I'd recommend the first
  few chapters of the ARRL Radio Amateurs Handbook.   It's quite 
accessible.  Any edition published in the last 30

  years is fine.

The "software" aspect of Software Defined Radio doesn't really relieve 
you of the burden of understanding how radio
  and radios work.  It just trades boxes of electronic components for 
software components.


Now, maybe it's the case that you aren't interested in *developing* SDR 
bits and pieces, but just want an SDR-based
  "casual airwave surfing" application--in which case, there are a 
plethora of apps out there, like GQRX, SDR++, etc, etc.

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus D. Leech]

On 25/07/2023 18:44, Gary Schafer wrote:

From: "Marcus D. Leech" 
To: discuss-gnuradio@gnu.org
Subject: Re: USRP B200mini Does Not Work in Gnu Radio With Latest
Version of Linux Mint (21.2)
Message-ID: 
Content-Type: text/plain; charset=UTF-8; format=flowed

On 25/07/2023 11:20, Sylvain Munaut wrote:
If that's the case, then Mint are now packaging a version of UHD 
that is NOT

 from NI/Ettus.

Doesn't UHD have like a plugin system that can dynamically load .so
files ? The UHD_MODULE_PATH thing ?

So it could be a perfectly legit UHD just with some soapy plugin
loaded dynamically.

Cheers,

  Sylvain


Yeah, so, in the presence of this plug-in, the "scan for radios" when
you don't give an explicit address is going to work
    differently, so:

uhd_usrp_probe --args "type=b200"

Should work, hopefully, because it will force it (I think) to go down
the "USRP devices" pathway.


Thank you, all, for the response. I learned more in the one minute it 
took to read through your (Marcus L, Sylvain, and Marcus M) answers 
then I did in several hours of trying to find an answer via Google.


We're one big step closer to an answer. When I tried "uhd_usrp_probe 
--args "type=b200"" on the command line, I got the following response:


[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [B200] Loading firmware image: 
/usr/share/uhd/images/usrp_b200_fw.hex...

[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image: 
/usr/share/uhd/images/usrp_b200mini_fpga.bin...

[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
  _
 /
|   Device: B-Series Device
| _
|    /
|   |   Mboard: B200mini
|   |   serial: 3279479
|   |   name: B200mini
|   |   product: 30521
|   |   revision: 6
|   |   FW Version: 8.0
|   |   FPGA Version: 7.0
|   |
|   |   Time sources:  none, internal, external
|   |   Clock sources: internal, external
|   |   Sensors: ref_locked
|   | _
|   |    /
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |    /
|   |   |   RX Dboard: A
|   |   | _
|   |   |    /
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |   RX Codec: A
|   |   |   |   Name: B200mini RX dual ADC
|   |   |   |   Gain Elements: None
|   | _
|   |    /
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |    /
|   |   |   TX Dboard: A
|   |   | _
|   |   |    /
|   |   |   |   TX Frontend: A
|   |   |   |   Name: FE-TX1
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |   TX Codec: A
|   |   |   |   Name: B200mini TX dual DAC
|   |   |   |   Gain Elements: None

I then went back to Gnu Radio and my flowgraph (again, just a USRP 
source going into a frequency sink) and put "type=b200" into the 
"Device Argument" entry of the USRP source block. This time, I 
received the following response:


Executing: /usr/bin/python3 -u 
/home/gary/SDR-Software/gnuradio/usrpSpectrumAnalyzer.py


[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automat

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus D. Leech]

On 25/07/2023 11:20, Sylvain Munaut wrote:

If that's the case, then Mint are now packaging a version of UHD that is NOT
from NI/Ettus.

Doesn't UHD have like a plugin system that can dynamically load .so
files ? The UHD_MODULE_PATH thing ?

So it could be a perfectly legit UHD just with some soapy plugin
loaded dynamically.

Cheers,

 Sylvain

Yeah, so, in the presence of this plug-in, the "scan for radios" when 
you don't give an explicit address is going to work

  differently, so:

uhd_usrp_probe --args "type=b200"

Should work, hopefully, because it will force it (I think) to go down 
the "USRP devices" pathway.

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus D. Leech]

On 25/07/2023 11:20, Sylvain Munaut wrote:

If that's the case, then Mint are now packaging a version of UHD that is NOT
from NI/Ettus.

Doesn't UHD have like a plugin system that can dynamically load .so
files ? The UHD_MODULE_PATH thing ?

So it could be a perfectly legit UHD just with some soapy plugin
loaded dynamically.

Cheers,

 Sylvain

Yes, it does.  I had totally forgotten about it, because it's not used a 
lot, but there's the "Make Soapy devices look like UHD
  devices" modules.  It may be the case that Mint now installs that 
stuff from Soapy.

Re: GPS module USRP x410

[Marcus D. Leech]

On 25/07/2023 09:36, Marcus Müller wrote:


Hi Theo,

for some USRPs, UHD used to export GPS strings as *sensors*:

https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_usage_sensors

You can make calls on the UHD USRP Source block to query these sensors:

https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html#a249fddbb3710046963c5a13fa5f47c2f

both from C++ and Python.

I'll note that "uhd_usrp_probe" has a sensors query interface, so you 
can use that bit of code as an example of use of the

  UHD API.

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus D. Leech]

On 25/07/2023 02:19, Sylvain Munaut wrote:

Hi,

The " type: soapy" probably means there is some weird plugin installed
making soapy device appear as UHD device or something. (and so it's
using any audio device as IQ source ...)

If that's the case, then Mint are now packaging a version of UHD that is NOT
  from NI/Ettus.



And uhd_usrp_probe only probes the first device which is not the
B200mini so you need to give it some address argument to select the
b200 mini.

Cheers,

Sylvain

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Marcus D. Leech]

On 24/07/2023 22:13, Gary Schafer wrote:
I just upgraded my system from Linux Mint 21.1 to 21.2. My system is 
an Intel i7-6700 based desktop with 32 GB of RAM. After loading the OS 
and going through my usual routine of loading programs and drivers, I 
discovered that I cannot use my USRP B200mini. I tried running a basic 
Gnu Radio flowgraph of USRP source to a frequency sink as a quick 
test. Right after I started it, it stopped with the statement, "Done 
(return code-11)". I'm not certain if this is a Gnu Radio problem, 
Mint problem, or USRP problem. I *suspect* it's a Mint / USRP problem. 
I've loaded libuhd4.1.0 as well as libuhd-dev and uhd-host. Normally, 
that's all that is required.


When I run "uhd_find_devices", I get:

[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
--
-- UHD Device 0
--
Device Address:
    serial: 11160936550978964554
    default_input: False
    default_output: False
    device_id: 4
    driver: audio
    label: Monitor of GM204 High Definition Audio Controller Digital 
Stereo (HDMI 3)

    type: soapy

--
-- UHD Device 1
--
Device Address:
    serial: 12015008079946540021
    default_input: True
    default_output: False
    device_id: 0
    driver: audio
    label: C922 Pro Stream Webcam Analog Stereo
    type: soapy

--
-- UHD Device 2
--
Device Address:
    serial: 13719246102091647219
    default_input: False
    default_output: False
    device_id: 3
    driver: audio
    label: Monitor of Built-in Audio Analog Stereo
    type: soapy

--
-- UHD Device 3
--
Device Address:
    serial: 3279479
    name: B200mini
    product: B200mini
    type: b200

Further, when I run uhd_usrp_probe, I get the following:

INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
  _
 /
|   Device: Audio
| _
|    /
|   |   Mboard: Audio
|   |   device_id: 0
|   |   origin: https://github.com/pothosware/SoapyAudio
|   |
|   |   Time sources:
|   |   Clock sources:
|   |   Sensors:
|   | _
|   |    /
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: 0.000 to 0.000 MHz
|   | _
|   |    /
|   |   |   RX Dboard: 0
|   |   | _
|   |   |    /
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: SoapyRF
|   |   |   |   Antennas: RX
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 6000.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |   RX Codec: 0
|   |   |   |   Name: SoapyADC
|   |   |   |   Gain Elements: None
|   | _
|   |    /
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: 0.000 to 0.000 MHz
|   | _
|   |    /
|   |   |   TX Dboard: 0
|   |   | _
|   |   |    /
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: None
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |   TX Codec: 0
|   |   |   |   Name: None
|   |   |   |   Gain Elements: None

This does not seem correct. For example, when running the same command 
on another system still running 21.1, I get much more detailed 
information about the B200mini. (It also says that it is loading a 
firmware image right after starting the command, which does not happen 
here.)


If anyone has any ideas, I'm all ears.

Thanks,

Gary


This looks like some confusion in the kernel about USB VID/PID values?

What does "lsusb" produce?

For USB devices, "uhd_find_devices" will look for USB devices with the 
correct VID/PID for NI/Ettus devices.  In your case, things
  seem quite confused.   This is likely to be a kernel issue, or maybe 
a "libusb" issue.  Dunno.

Re: Error strange: The daughterboard manager encountered a recoverable error in init.

[Marcus D. Leech]

On 17/07/2023 02:16, sp wrote:
when I want to use USRP x310 with ubx-160 and twin-rx daughterboard I 
have faced this strange log...


The daughterboard manager encountered a recoverable error in init.
Loading the "unknown" daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.

when I used uhd_usrp_probe I faced that TX for UBX-160 is unknown.
TX Frontend: 0
The other Marcus has already mentioned that this belongs properly on 
usrp-users, NOT discuss-gnuradio.


But my recollection is that the TwinRX/UBX-160 combination doesn't work 
because of conflicting clocking
  requirements on the motherboard.    If you try to use them 
separately, you'll likely find that they work.




|   |   | *Name: Unknown (0x0094) - 0
|   |   |   Antennas:
|   |   |   Sensors:
|   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   Gain Elements: None
|   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No*

How can solve these errors?

*complete log:*

uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.2.0.0-0-unknown

[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!
  _
 /
|       Device: X-Series Device
|     _
|    /
|   |       Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:32:72:23
|   |   mac-addr1: 00:80:2f:32:72:24
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 3216766
|   |   FW Version: 6.0
|   |   FPGA Version: 38.0
|   |   FPGA git hash: 26793b8
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|     _
|    /
|   |       RFNoC blocks on this device:
|   |
|   |   * 0/DDC#0
|   |   * 0/DDC#1
|   |   * 0/DUC#0
|   |   * 0/DUC#1
|   |   * 0/Radio#0
|   |   * 0/Radio#1
|   |   * 0/Replay#0
|     _
|    /
|   |       Static connections on this device:
|   |
|   |   * 0/SEP#0:0==>0/DUC#0:0
|   |   * 0/DUC#0:0==>0/Radio#0:0
|   |   * 0/Radio#0:0==>0/DDC#0:0
|   |   * 0/DDC#0:0==>0/SEP#0:0
|   |   * 0/Radio#0:1==>0/DDC#0:1
|   |   * 0/DDC#0:1==>0/SEP#1:0
|   |   * 0/SEP#2:0==>0/DUC#1:0
|   |   * 0/DUC#1:0==>0/Radio#1:0
|   |   * 0/Radio#1:0==>0/DDC#1:0
|   |   * 0/DDC#1:0==>0/SEP#2:0
|   |   * 0/Radio#1:1==>0/DDC#1:1
|   |   * 0/DDC#1:1==>0/SEP#3:0
|   |   * 0/SEP#4:0==>0/Replay#0:0
|   |   * 0/Replay#0:0==>0/SEP#4:0
|   |   * 0/SEP#5:0==>0/Replay#0:1
|   |   * 0/Replay#0:1==>0/SEP#5:0
|     _
|    /
|   |       TX Dboard: 0/Radio#0
|   |   ID: UBX-160 v2 (0x007d)
|   |   Serial: 325406E
|   | _
|   |    /
|   |   |       TX Frontend: 0
|   |   |   Name: UBX TX
|   |   |   Antennas: TX/RX, CAL
|   |   |   Sensors: lo_locked
|   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   Connection Type: QI
|   |   |   Uses LO offset: No
|     _
|    /
|   |       RX Dboard: 0/Radio#0
|   |   ID: UBX-160 v2 (0x007e)
|   |   Serial: 325406E
|   | _
|   |    /
|   |   |       RX Frontend: 0
|   |   |   Name: UBX RX
|   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   Sensors: lo_locked
|   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No
|     _
|    /
|   |       TX Dboard: 0/Radio#1
|   |   ID: Unknown (0x0094)
|   |   Serial: 31EF996
|   | _
|   |    /
|   |   |       TX Frontend: 0
|   |   |   Name: Unknown (0x0094) - 0
|   |   |   Antennas:
|   |   |   Sensors:
|   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   Gain Elements: None
|   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   Connection Type: IQ
|   |   |   Uses LO offset: No
|     _
|    /
|   |       RX Dboard: 0/Radio#1
|   |   ID: TwinRX Rev C (0x0095)
|   |   Serial: 31D7212
|   | 

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 

Re: Using volk_profile for all users on shared server

[Marcus D Leech]

Remove the file temporarily. Run a flow graph that consumes some resources. Put the volk config back in place. Compare. Sent from my iPhoneOn Jun 26, 2023, at 7:01 PM, Richard Bell  wrote:What is a good way to test whether this is working or not?On Thu, Jun 22, 2023 at 5:58 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote:
  

  
  
On 22/06/2023 20:50, Richard Bell
  wrote:


  
  Hello,


I am managing a server that is connected to several USRP
  N320s and USRP X300s, that many users access. The server is
  running Ubuntu 22.04 with GNU Radio 3.10.6.0 and UHD 4.4.0.0,
  installed from source.


I would like to know if there is a way to run
  "volk_profile" once, for all users, instead of every user
  needing to run this individually. Is this possible?


Thank you,

  Rich
  

/etc/volk/volk_config   
  from a very very cursory inspection of the code...
  

  

Re: Help Regarding Transmitting Gain of USRP N-200

[Marcus D. Leech]

On 25/06/2023 16:49, Arhum Ahmad wrote:

Respected sir,
I am using N-200 USRP for transmitting a signal. While transmitting, I 
havechangedthe Gain value in the SDRutransmitting block, but my signal 
strength at the receiver remains the same. I also stop and restart the 
code but the change in gain does not affect the received signal. I 
have tried the changing gain via both available options i.e., input 
port and dialog, but it seems to have no effecton the receiver. The 
signal strength at the receiver remains the same. I have tried 30 
dB(Maximum gain) to 0 dB (minimum gain) in both cases received SNR is 
the same(i.e.,15 dB). I am using a wireless connection in 
line-of-sight, with minimum Tx gain at least a fewdropsin SNR should 
be observed. I have also tried -50dB (just checking) but noeffect in 
the SNR is observed. The same thing I havetried using B210 as Tx, Rx 
signal strength does change in this case. However, while using N-200, 
noeffect of changing the gain value is observed. Somehow gainvalue is 
fixed in N-200 while using the MATLABSDRu block. Can you PLEASE HELP 
ME!!! IT IS VERY, VERY IMPORTANT.



Well, neither usrp-users nor discuss-gnuradio are support lists for MATLAB.

You haven't mentioned which daughter-card you are using in the N200, 
which would certainly help to fill in information about

  what *might* be going on.


Does your receiver setup use AGC?  Do you know what its set-points are?

If you simply look at the spectrum on the RX end as you vary gain on the 
TX end, do you see a change?   At the higher end,
  SNR may not change very much, depending on how it is being measured, 
etc.

Re: Using volk_profile for all users on shared server

[Marcus D. Leech]

On 22/06/2023 20:50, Richard Bell wrote:

Hello,

I am managing a server that is connected to several USRP N320s and 
USRP X300s, that many users access. The server is running Ubuntu 22.04 
with GNU Radio 3.10.6.0 and UHD 4.4.0.0, installed from source.


I would like to know if there is a way to run "volk_profile" once, for 
all users, instead of every user needing to run this individually. Is 
this possible?


Thank you,

Rich

/etc/volk/volk_config from a very very cursory inspection of the code...

Re: how to use 2 usrp b210 to receive synchronously

[Marcus D. Leech]

On 30/05/2023 08:12, Gwenhael Goavec-Merou wrote:

With the link:
https://lists.gnu.org/archive/html/discuss-gnuradio/2019-11/msg00034.html

Sorry

Gwen


The key is to set a common start-time on the two multi_usrp objects 
(after making sure that both units have

  a common understanding of clock-time).

But note that you likely won't achieve good-quality *phase coherence* 
with this setup due to the way the
  AD9361 chip works, and the way the external-clock PLL works in the 
B2xx series.

Re: Resource issues when trying to record 2 FM broadcast

[Marcus D. Leech]

On 20/05/2023 09:12, Martin Lefkowitz wrote:


Here is the screen capture of the Marcus Leech version of the two FM 
demodulate as described here


https://wiki.gnuradio.org/index.php?title=Frequency_Xlating_FIR_Filter

https://github.com/patchvonbraun/wfm_stuff

With a samplerate of 2.4M it uses about 60% of the 4 core I5 I am 
using for this project


If anybody wants the grc pm me.

The other email contains the Zans version of stereo demod.
Your taps for the freq-xlating filters aren't properly specified. They 
must be the output of one of the taps-generator

  functions--use the Low Pass Filter Taps block.

Further, your desired parameters will lead to a very large filter.    
This is mostly controlled by the transition width parameter,
  and as that parameter becomes a smaller fraction of the sample-rate, 
the filter grows non-linearly.   Consider a
  "lazier" transition width, and use an FFT filter instead--the FFT 
filter structure is more efficient once you have more

  than perhaps 30-50 taps.

I haven't touched the "wfm_stuff" code in a long long time, so no 
guarantees about anything--including performance.

Re:

[Marcus D. Leech]

On 16/05/2023 03:12, Natasya Nurul Putri wrote:

Hello Everyone
I want to ask about hot to connect USRP devices on ubuntu
I have done USRP install on ubuntu. but, when I connect USRP device to 
PC. However, on ubuntu OS the device (USRP)  is not found.


How to solve this problem?
Looking for you replies, thankyou
What type of USRP device?  There are about a dozen different types these 
days...

Re: Getting GPS data into stream

[Marcus D. Leech]

On 04/05/2023 12:09, Jim Melton wrote:

You are confusing data representation with data presentation. The flaws in Excel are NOT 
issues with the data format. So long as the data format clearly and consistently 
represents that content, then the representation is "good".

If you want to overcome limitations in Excel's presentation (import, 
interpretation), then that's an Excel issue. You can overcome it by manually 
doing the import and explicitly asserting the data type of each column, or you 
can create something more custom.

Realize that more and more your data is likely to be consumed by some other 
data science tool (R, Python/numpy/pandas, etc.) and you quickly see how 
pushing Excel issues into the data representation layer is a losing proposition.

---
Jim Melton
For myself, I'm not actually committed to any particular text format, 
but .csv was helpful for some of the "customers" of
  my apps, because they're used to doing "casual" science extraction 
using Excel.    For relatively low-rate/low-volume
  data, I find that text formats let me explore it for first-order 
sanity-checking, and it also allows for processing with
  a number of different tools without having to bring in great 
lumbering packages and libraries.


I can process my .csv data with AWK, Ad-Hoc Python, GnuPlot and Octave 
and R without too much fuss--because the columns
  are regular and in known places, and typically floating-point or 
integers.


When you move towards data that has much higher rates/volumes, and has 
more exotic semantics, like pulsar processing,
  you start to abandon text.   But 99% of my "user community" are 
amateur science types, whose experiments are somewhat
  ad-hoc, and are usually confined to simple observing modes where 
low-rate textual logging makes considerable sense...






-Original Message-
Sent: Thursday, May 4, 2023 01:40
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: Getting GPS data into stream

Hey Marcus,

as you say, for a lot of science you don't get high rates – so I'm really less 
worried
about that. More worried about Excel interpreting some singular data point as 
date; or, as
soon as we involve textual data, all the funs with encodings, 
quoting/delimiting/escaping…
(not to mention that an Excel set to German might interpret different things as 
numbers
than a Northern American one).

I wish there was just one good CSV standard that tools adhered to. Alas, that's 
not the
case, and especially Excel has a habit of autoconverting input and losing data 
at that point.
So, looking for an alternative that has these well-defined constraints and 
isn't as
focused on hierarchical data (JSON, YAML, XML), far too verbose but excellent 
to query
with command line tools (XML), completely impossible to correctly parse as 
human or parser
in its full beauty (YAML)… Just some tabular data notation that's textual, 
appendable, and
not a party of guesswork for the reading tool.
We could just canonalize calling all our files

marcusdata.utf8.textalwaysquoted.iso8601.headerspecifies_fieldname_parentheses_type.csv

but even that wouldn't solve the issue of excel seeing an unquoted 12.2021 and 
deciding
the field being about christmases past.

So, maybe we just do some rootless JSON format that starts with a SigMF object 
describing
the file and its columns, and then basically is just a sequence of JSON arrays

[ 1.212e-1, 0, "Müller", 24712388823 ]
[ 1.444e-2, 1, "  \"\"!", 111 ]
[ 2.0115-1, 0, "Cygnus-B", 0 ]

(I'm not even sure that's not valid JSON; gut feeling tells me we should be 
putting []
around the whole document, but we don't want that for streaming purposes. 
ECMA-404 doesn't
seem to *forbid* it.)

That way, we get the metadata in a format that's easy to skip by simpler tools, 
but
trivial to parse with the right tools (I've grown to like `jq`), and the data 
into a
well-defined format. Sure, you can't dump that into Excel, still, but you know 
what, if it
comes down to it, we can have a python script that takes these files and 
actually converts
them to valid XLSX without the misconversion footguns, and that same tool could 
also be
run in a browser for those having a hard time executing python on their 
machines.

Cheers,
Marcus
On 03.05.23 23:05, Marcus D. Leech wrote:

On 03/05/2023 16:51, Marcus Müller wrote:

Do agree, but really don't like CSV, too underspecified a format, too many ways 
that
comes back to bite you (aside from a thousand SDR users writing emails that 
their PC
can't keep up with writing a few MS/s of CSV…)

I like CSV because you can hand your data files to someone who doesn't have a 
complete
suite of astrophysics tools, and they
can slurp it into Excel and play with it.


How important is plain-textness in your applications?

I (and many others in my community) tend to throw ad-hoc tools at data from 
ad-hoc
experiments.  In the past, I used a lot

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 16:51, Marcus Müller wrote:


Do agree, but really don't like CSV, too underspecified a format, too 
many ways that comes back to bite you (aside from a thousand SDR users 
writing emails that their PC can't keep up with writing a few MS/s of 
CSV…)
I like CSV because you can hand your data files to someone who doesn't 
have a complete suite of astrophysics tools, and they

  can slurp it into Excel and play with it.



How important is plain-textness in your applications?
I (and many others in my community) tend to throw ad-hoc tools at data 
from ad-hoc experiments.  In the past, I used a lot
  of AWK to post-process data, and these days, I use a lot of 
Python.    Text-based formats lend themselves well to this kind
  of processing.  Rates are quite low, typically.  Like logging an 
integrated power spectrum a few times a minute, for example.


There are other observing modes where text-based formats aren't quite so 
obvious--like pulsar observations, where filterbank
  outputs might be recorded at 10s of kHz, and then post-processed with 
any of a number of pulsar tools.


In all of this, part of the "science" is extracted in "real-time" and 
part in post-processing.





Best,
Marcus

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 14:59, Fabian Schwartau wrote:

Sorry, forget it. Wrong sink...

You probably want:

https://wiki.gnuradio.org/index.php/File_Meta_Sink


Am 03.05.23 um 20:52 schrieb Fabian Schwartau:
OK, I think I found an easier way (at least for me), without having 
to write my own module - never done that.
I used the "Tags Strobe" block in combination with the "Python 
Module" for my gps_get_position() function.
Anyway, where can I find a definition of the format of the "Tagged 
File Sink"? I need to read this with antoher program, without 
gnuradio, but in python.


Best,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from a socket or however gspd works, I must admit I'm not 
sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am 
kind of stuck and don't know how a possible solution for that might 
look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 14:04, Marcus Müller wrote:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from  a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am kind 
of stuck and don't know how a possible solution for that might look 
like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian




Quite apart from the GPSD-specific stuff, it would be useful to have a 
kind of "annotated formatted data" file sink for low-rate
  data (like scientific data, etc) which supports CSV outputs, and has 
some way of ordering any tags that come in with the
  data and formatting them appropriately, but still be reasonably 
"generic"  (in that the block doesn't really *know* anything
  about the tags, and can be told how to format them).  Maybe *in 
addition* you could pass the block a series of methods to

  call at some configurable cadence.

This somewhat overlaps with what SigMF tries to do, but this is 
formatted data, inherently low-rate, with formatted

  annotations.

I nearly always end up doing this in a custom way for my applications, 
but having a generic block would be cool, and not
  hard to do.   Could be entirely in Python, since we're talking "low 
rate" (like perhaps a few per second at most).

Re: Pail of Milky Way Horn Radio Telescope

[Marcus D. Leech]

On 02/05/2023 19:17, Glen Langston wrote:

Hi Marcus Leech (and Muller),

Well you beat me to it!

It’s great that you can pre-confirm my results.  I’ll have to look at the
rest of your memos.   Do you mind if we cross-post your memo CERRA memo,
as a LightWork memo too?  Maybe it will be better to just reference your memos
on the LightWork page.  Just thinking while typing…

You produced a beautiful spectrum of the Milky Way, if you love that kind of 
thing, like I do!
Calibrating, by looking at the Ground, is pretty reliable and easy.

Cheers

Glen


Wide-field spectra at milky-way transit near Cygnus are generally pretty 
nice.


Here's a kind of "extremal" of these types of horn antenna:

https://photos.app.goo.gl/Kn49pWqQ3kiiZwTq8

We had that one built by a local sheet-metal/HVAC shop for under 
C$200.00.    The diameter at the exit is about 23"

  as I recall.

The plan was to use it to illuminate our sub-reflector at the 
observatory, but we had a change of heart after we realized
  that plan was going to require a LOT of "civil engineering".   So, we 
converted the 12.8m dish to prime focus, and that

  well-built (but kinda 'amateur') horn is just sitting there.

Re: Pail of Milky Way Horn Radio Telescope

[Marcus D. Leech]

On 02/05/2023 19:17, Glen Langston wrote:

Hi Marcus Leech (and Muller),

Well you beat me to it!

It’s great that you can pre-confirm my results.  I’ll have to look at the
rest of your memos.   Do you mind if we cross-post your memo CERRA memo,
as a LightWork memo too?  Maybe it will be better to just reference your memos
on the LightWork page.  Just thinking while typing…
You can feel free to cross-post.  That was the original idea of our memo 
series.




You produced a beautiful spectrum of the Milky Way, if you love that kind of 
thing, like I do!
Calibrating, by looking at the Ground, is pretty reliable and easy.

Cheers

Glen



On May 2, 2023, at 7:03 PM, Marcus D. Leech  wrote:

On 02/05/2023 18:58, Marcus Müller wrote:

Hey Glen,

this is really cool stuff!

Tried to give this a bit of reach on Mastodon [1], but I'm far from the 
audience I used to have on twitter.

It's pretty cool that a galvanized pail does the job so well, would have 
thought zinc wouldn't be low-loss enough a surface coating, but was proven 
wrong by awesome results :) The best case of being wrong!

I especially like that this is a solution that needs so little "craftiness" and 
seems quite robust. Just drill a hole, watch (and then obviously like) a few videos and 
send Glen an email to get a free feed :D

If I had one complaint, it's that you promise a shopping list in the appendix – 
but there's no appendix!

I'd also state very early in the guide (maybe actually with a flashy yellow 
"sticker" on the title page?) that it comes with video documentation (30 min in 
total[2]). I think that's quite a relief to a teacher who doesn't want to risk building 
something new based on text only, especially when it involves mechanical work!

Cheers,
Marcus

PS: I think if you're really going to leave it out in the weather, maybe add a 
Polymeric Low-Absorption Small-Thickness Inherently Costefficient Best-fit 
Antenna enGulfing (PLASTICBAG) radome?


[1] https://mastodon.social/@funkylab/110301361379949802
[2] For those wondering: these videos:
https://www.youtube.com/playlist?list=PLFMYhHhJW1VDYESTcHJIiwNbRQXWpFlyF

On 02.05.23 16:53, Glen Langston wrote:

Hello Aficionados!

We’ve just released a marvelous summary of how to build a “Pail of Milky Way”
horn radio telescope.   This is described in LightWork memo 32.

https://github.com/WVURAIL/lightwork/blob/master/memos/LightWorkMemo032-PailOfMilkyWay-r5.pdf

The memo concludes with a plot of one day’s observations, showing
what you can see with a horn radio telescope.   The Doppler shifted
Cygnus and Perseus Spiral arms of the Milky Way are visible.

Comments and improvements welcomed.

Data are all obtained using Gnuradio designs available from the DSPIRA web site.
https://github.com/WVURAIL/gr-radio_astro

Thanks to Kevin Bandura at WVU and the Green Bank Observatory Staff.

Cheers

Glen





Some of this reminds me of the memo I published 1.5 years ago on a similar 
subject:

http://www.ccera.ca/files/memos/ccera-memo-0014.pdf

Re: Pail of Milky Way Horn Radio Telescope

[Marcus D. Leech]

On 02/05/2023 18:58, Marcus Müller wrote:

Hey Glen,

this is really cool stuff!

Tried to give this a bit of reach on Mastodon [1], but I'm far from 
the audience I used to have on twitter.


It's pretty cool that a galvanized pail does the job so well, would 
have thought zinc wouldn't be low-loss enough a surface coating, but 
was proven wrong by awesome results :) The best case of being wrong!
You wouldn't want to make extended wave-guides out of zinc-plated 
steel.  But for small numbers of lambda, the loss is
  quite small.  I routinely make dish feeds for 21cm from 15cm (6") 
HVAC duct.   The spiral wound stuff is quite stiff and

  maintains its shape well...

Re: Pail of Milky Way Horn Radio Telescope

[Marcus D. Leech]

On 02/05/2023 18:58, Marcus Müller wrote:

Hey Glen,

this is really cool stuff!

Tried to give this a bit of reach on Mastodon [1], but I'm far from 
the audience I used to have on twitter.


It's pretty cool that a galvanized pail does the job so well, would 
have thought zinc wouldn't be low-loss enough a surface coating, but 
was proven wrong by awesome results :) The best case of being wrong!


I especially like that this is a solution that needs so little 
"craftiness" and seems quite robust. Just drill a hole, watch (and 
then obviously like) a few videos and send Glen an email to get a free 
feed :D


If I had one complaint, it's that you promise a shopping list in the 
appendix – but there's no appendix!


I'd also state very early in the guide (maybe actually with a flashy 
yellow "sticker" on the title page?) that it comes with video 
documentation (30 min in total[2]). I think that's quite a relief to a 
teacher who doesn't want to risk building something new based on text 
only, especially when it involves mechanical work!


Cheers,
Marcus

PS: I think if you're really going to leave it out in the weather, 
maybe add a Polymeric Low-Absorption Small-Thickness Inherently 
Costefficient Best-fit Antenna enGulfing (PLASTICBAG) radome?



[1] https://mastodon.social/@funkylab/110301361379949802
[2] For those wondering: these videos:
https://www.youtube.com/playlist?list=PLFMYhHhJW1VDYESTcHJIiwNbRQXWpFlyF

On 02.05.23 16:53, Glen Langston wrote:

Hello Aficionados!

We’ve just released a marvelous summary of how to build a “Pail of 
Milky Way”

horn radio telescope.   This is described in LightWork memo 32.

https://github.com/WVURAIL/lightwork/blob/master/memos/LightWorkMemo032-PailOfMilkyWay-r5.pdf 



The memo concludes with a plot of one day’s observations, showing
what you can see with a horn radio telescope.   The Doppler shifted
Cygnus and Perseus Spiral arms of the Milky Way are visible.

Comments and improvements welcomed.

Data are all obtained using Gnuradio designs available from the 
DSPIRA web site.

https://github.com/WVURAIL/gr-radio_astro

Thanks to Kevin Bandura at WVU and the Green Bank Observatory Staff.

Cheers

Glen






Some of this reminds me of the memo I published 1.5 years ago on a 
similar subject:


http://www.ccera.ca/files/memos/ccera-memo-0014.pdf

Re: Latency due to hardware initialization

[Marcus D. Leech]

On 25/04/2023 11:46, Ahmad Oweis wrote:
Thanks Marcus. I'm getting latency in the range of seconds, and this 
was the only way I could explain it..


Is this mentioned anywhere in the documentation? How can I learn more 
about the scheduler operation?


Thanks,


How are you measuring latency?  Do you mean:
  "from the time I start the program to the time signals start coming 
out of my radio"?   In that case, yeah, it takes a
  non-trivial amount of time to get the radio initialized, and Gnu 
Radio cannot possibly start sending samples until it

  is initialized.





On Tue, 25 Apr 2023, 17:23 Marcus D. Leech,  
wrote:


On 25/04/2023 02:23, Ahmad Oweis wrote:

Hi all,

I'm investigating the factors behind the latency in my simple GRC
flow graph, I have a theory and I'd be grateful if someone can
confirm it or refute it.

Say I have a simple flow graph consisting of a file source
connected to a hardware sink.

My understanding: when I run the flow graph, the source starts
producing samples and storing them in the buffer. In the
meantime, the hardware sink is initializing (loading FPGA, etc.).
Once the hardware is ready to transmit samples, it starts
consuming from the buffer. This initialization delay adds to the
overall system latency. Is this correct? or does the source only
start producing samples after the hardware is initialized?

If my understanding is correct, how can we avoid this delay? Is
there a way to ask the file source to wait until the hardware is
ready and then start sending samples?

Thank you
-- 
Ahmad Oweis

Gnu Radio doesn't start running the graph until all the blocks in
it are initialized--that includes hardware source/sinks.

Re: Latency due to hardware initialization

[Marcus D. Leech]

On 25/04/2023 02:23, Ahmad Oweis wrote:

Hi all,

I'm investigating the factors behind the latency in my simple GRC flow 
graph, I have a theory and I'd be grateful if someone can confirm it 
or refute it.


Say I have a simple flow graph consisting of a file source connected 
to a hardware sink.


My understanding: when I run the flow graph, the source starts 
producing samples and storing them in the buffer. In the meantime, the 
hardware sink is initializing (loading FPGA, etc.). Once the hardware 
is ready to transmit samples, it starts consuming from the buffer. 
This initialization delay adds to the overall system latency. Is this 
correct? or does the source only start producing samples after the 
hardware is initialized?


If my understanding is correct, how can we avoid this delay? Is there 
a way to ask the file source to wait until the hardware is ready and 
then start sending samples?


Thank you
--
Ahmad Oweis
Gnu Radio doesn't start running the graph until all the blocks in it are 
initialized--that includes hardware source/sinks.

Re: GNURadio/USRP stream tag execution not as expected

[Marcus D. Leech]

On 18/04/2023 15:46, Nicolas Buhr wrote:
Update: I found a way to make it work on the X310 (and in a limited 
way also for the B210)


If I implement it as a bursty transmission (with tx_sob, tx_eob and 
tx_time tag) I can calculate the time of the gain change from tx_time 
and the sample rate and add it to the tx_command tag.

This only works for the X310.

For the B210 the time tag doesn‘t work for some reason. But on a 
bursty transmission the position of the tx_command tag works to some 
extend (not on the exact sample asked for, but with some delay).


My guess is that the B2xx series use the AD936x series, and part of the 
DSP chain is in the chip, and that chip doesn't know
  anything about time tags, so only the FPGA parts of time-tag 
processing know anything about them.

Re: E312 RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 'get_num_xbars'

[Marcus D. Leech]

On 12/04/2023 12:43, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & 
Open-Source Toolkit for Software Radio wrote:
then i should have uhd 3.9LTS both in the host and the e312? because 
i've been using GNU-Radio 3.8 with UHD 4.3.

The E312 isn't like other network-connected or even USB-connected USRPs.

The intended use is as an embedded platform--it's a dual-core ARM system 
with a USRP radio as an internal peripheral.


The "network mode" was only ever intended for initial "sanity checks", 
and even then, only at very-low sample rates

  (100-200kSPS to the host).

The usage model is that you develop code that runs natively on the ARM, 
and perhaps offloads some work to the

  FPGA via the RFNoC architecture.

But if you really do want network mode, my understanding is that you 
have to stick with a UHD 3.9 environment.





i apologize if i make basics questions, im new using GNU-Radio and the 
e312


El mié, 12 abr 2023 a las 11:22, Marcus D. Leech 
() escribió:


On 12/04/2023 10:49, JORGE GONZALEZ ORELLANA via GNU Radio, the
Free &
Open-Source Toolkit for Software Radio wrote:
> Hello everyone
>
> I was fixing a problem with the mpm version, for some reason, I had
> different versions both in my host and in the e312, i fixed that
> problem by installing GNU-radio on the host but now when I try
to use
> the e312 I get this error.
>
You should probably read this:

https://files.ettus.com/manual/page_usrp_e3xx.html#e31x_migration

In particular, network mode is no longer supported on E3xx after
the MPM
migration and UHD 3.15


>
>

--
> Generating: '/home/uno/GNURADIO EJEMPLOS/Analizador.py'
>
> Executing: /usr/bin/python3 -u /home/uno/GNURADIO
EJEMPLOS/Analizador.py
>
> /home/uno/GNURADIO EJEMPLOS/Analizador.py:168: DeprecationWarning:
> distutils Version classes are deprecated. Use packaging.version
instead.
>   if StrictVersion("4.5.0") <= StrictVersion(Qt.qVersion()) <
> StrictVersion("5.0.0"):
> /home/uno/GNURADIO EJEMPLOS/Analizador.py:66: DeprecationWarning:
> distutils Version classes are deprecated. Use packaging.version
instead.
>   if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
> UHD_3.15.0.0-2build5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>

mgmt_addr=192.168.10.42,type=e3xx,product=e310_sg3,serial=32132F0,name=ni-e31x-32132F0,fpga=n/a,claimed=False,addr=192.168.10.42
> Traceback (most recent call last):
>   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 195, in

>     main()
>   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 173, in
main
>     tb = top_block_cls()
>   File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 92, in
__init__
>     self.uhd_usrp_source_0 = uhd.usrp_source(
>   File
"/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line
> 125, in constructor_interceptor
>     return old_constructor(*args)
>   File
"/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 2787, in make
>     return _uhd_swig.usrp_source_make(device_addr, stream_args,
> issue_stream_cmd_on_start)
> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC
> function 'get_num_xbars'
>
> >>> Done (return code 1)
>

---
>
> does anyone know what could it be? i look up on google and
everything
> i found it was for the N3xx series and does not seems to work
>
> thanks for your time

Re: E312 RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 'get_num_xbars'

[Marcus D. Leech]

On 12/04/2023 10:49, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & 
Open-Source Toolkit for Software Radio wrote:

Hello everyone

I was fixing a problem with the mpm version, for some reason, I had 
different versions both in my host and in the e312, i fixed that 
problem by installing GNU-radio on the host but now when I try to use 
the e312 I get this error.



You should probably read this:

https://files.ettus.com/manual/page_usrp_e3xx.html#e31x_migration

In particular, network mode is no longer supported on E3xx after the MPM 
migration and UHD 3.15





--
Generating: '/home/uno/GNURADIO EJEMPLOS/Analizador.py'

Executing: /usr/bin/python3 -u /home/uno/GNURADIO EJEMPLOS/Analizador.py

/home/uno/GNURADIO EJEMPLOS/Analizador.py:168: DeprecationWarning: 
distutils Version classes are deprecated. Use packaging.version instead.
  if StrictVersion("4.5.0") <= StrictVersion(Qt.qVersion()) < 
StrictVersion("5.0.0"):
/home/uno/GNURADIO EJEMPLOS/Analizador.py:66: DeprecationWarning: 
distutils Version classes are deprecated. Use packaging.version instead.

  if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; 
UHD_3.15.0.0-2build5
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.42,type=e3xx,product=e310_sg3,serial=32132F0,name=ni-e31x-32132F0,fpga=n/a,claimed=False,addr=192.168.10.42

Traceback (most recent call last):
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 195, in 
    main()
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 173, in main
    tb = top_block_cls()
  File "/home/uno/GNURADIO EJEMPLOS/Analizador.py", line 92, in __init__
    self.uhd_usrp_source_0 = uhd.usrp_source(
  File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 
125, in constructor_interceptor

    return old_constructor(*args)
  File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line 
2787, in make
    return _uhd_swig.usrp_source_make(device_addr, stream_args, 
issue_stream_cmd_on_start)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC 
function 'get_num_xbars'


>>> Done (return code 1)
---

does anyone know what could it be? i look up on google and everything 
i found it was for the N3xx series and does not seems to work


thanks for your time

Re: Modifying File Sink

[Marcus D. Leech]

On 03/04/2023 04:12, DİREN ERDEM AYDIN wrote:

Thanks for the response Marcus appreciate it!

But can you explain more how can I use "constructed" filename that 
includes frequency information? I have QT GUI Range which has ID 
lo_freq, when I tried to insert that info into file sink's file 
section like "C:\Users\aydindi\Desktop\sept_2\buff1_lo_freq.txt", 
extracted file does not contain numerical freq info as expected..


I can handle multiple separated txt files in matlab using a for loop. 
I would like to modify file sink like (' buff1_%d.txt ', lo_freq) but 
I am not quite sure about the file section accepts this kind of input.

for i=1:6
f = fopen(sprintf('pll_re_1_3_%d.txt', i), 'rb');
rx_pll_re{i} = fread(f, Inf, 'float');
fclose all;
f = fopen(sprintf('pll_im_1_3_%d.txt', i), 'rb');
rx_pll_im{i} = fread(f, Inf, 'float');
fclose all;
end
The file sink block (I assume you're using GRC to build your 
flow-graphs?) has a "filename" parameter.  Like most parameters

  in GRC, that parameter actually accepts a python expression, so:

"buff1_%d" % lo_freq

In that parameter field will do what you want.

I strongly suggest learning a bit of Python to use GRC.

Your "for loop" example isn't quite relevant, since GRC uses what's 
called a "data flow" programming model.  At its top level,

  it's NOT a "procedural" programming environment.




On Mon, Apr 3, 2023 at 12:46 AM Marcus D. Leech 
 wrote:


On 02/04/2023 17:41, DİREN ERDEM AYDIN wrote:

Dear all,

I would like to modify the file sink so that when I changed the
receiver frequency during simulation, the file sink will create a
new file and record new frequency data there. Is it possible to
do that? and where can I find the source code of the existing
file sink in gnu radio?

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./

You don't need to modify the filesink to do that.  You just have
to use a "constructed" filename that includes frequency information.
  When the filename changes, the filesink will automatically close
the current file and start a new one under the new name.

Gnu Radio source is on github:

https://github.com/gnuradio/gnuradio

gr-blocks/lib   is where filesink_impl and filesink_base live.




/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./

Re: Modifying File Sink

[Marcus D. Leech]

On 02/04/2023 17:41, DİREN ERDEM AYDIN wrote:

Dear all,

I would like to modify the file sink so that when I changed the 
receiver frequency during simulation, the file sink will create a new 
file and record new frequency data there. Is it possible to do that? 
and where can I find the source code of the existing file sink in gnu 
radio?


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./
You don't need to modify the filesink to do that.  You just have to use 
a "constructed" filename that includes frequency information.
  When the filename changes, the filesink will automatically close the 
current file and start a new one under the new name.


Gnu Radio source is on github:

https://github.com/gnuradio/gnuradio

gr-blocks/lib   is where filesink_impl and filesink_base live.

Re: N310 radio Sample Rate setting

[Marcus D. Leech]

On 25/03/2023 15:45, George Edwards wrote:

Hello GNURadio Community,

I am about to use a N310 radio to transmit and receive data. My 
problem is I do not know how to interpret the sample rate parameter. I 
will pose some questions that I am seeking answer to (I read there are 
3 Master Clocks for the N310):


Q1. The transmitter Sample Rate setting: is this the sample rate of 
the data that will enter the N310 hardware from the GRC software 
component?

yes.



Q2. The receiver Sample Rate setting: is this the sample rate that the 
N310 hardware outputs the connected GRC software component?

Yes



Q3. Now I was reading the interpolation/decimation in the N310 radio 
and there were statements made about the device having 3 Master 
Clocks. Let's assume I choose the Master Clock frequency of 125e6 for 
the transmitter and I wish to upsample by a factor of 100 in the N310 
transmitter. I take it that this assumes that  GRC component connected 
to the N310 USRP Tx block must be running at a sample rate 1.25e6 and 
that by setting the Sample Rate in the USRP block to 1.25e6 (with the 
Master Clock set to 125e6) then N310 hardware will upsample the data 
entering to 125e6, right?

Yes.



Q4. Now, for the converse at the receiver: with the USRP Master Clock 
set to 125e6 and USRP Sample Rate set to 1.25e6, then the USRP block 
will deliver a sample rate of 1.25e6 to the attached  GRC component, 
right?

Yes,



Q5. What happens if I do not select one of the Master Clocks, but  
provide the Sample Rates at the respective USRP Tx/Rx?
The default master-clock if you don't specify in a device argument is by 
default (as I recall) 125MHz.   But that can be
  easily verified by asking for some sample-rate that is a proper 
fraction of 125MHz, and seeing if UHD changes it to

  something different.

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.

Re: FFT Size and Signal & Vector Sources Amplitude Unit

[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.

Re: Qt ImportError

[Marcus D. Leech]

On 07/03/2023 15:58, Daniel R. Marlow wrote:


-Original Message-
From: discuss-gnuradio-bounces+marlow=princeton@gnu.org 
 On Behalf Of Marcus D. 
Leech
Sent: Tuesday, March 7, 2023 3:19 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Qt ImportError

On 07/03/2023 15:05, Daniel R. Marlow wrote:

from PyQt5 import Qt

Make sure you have your system setup to run Python3 by default?

I have Ubuntu 22.04, same as you.  I don't have this problem. I installed 
everything from APT packages.


Hi Marcus,

Thanks.I was indeed picking up Python 2 by default.   Running Python3 
was better, but now I get hung up on StrictVersion():

Warning: failed to XInitThreads()
Traceback (most recent call last):
   File "/home/marlow/21cm_dev/sineWaveFlowGraph.py", line 238, in 
 main()
   File "/home/marlow/21cm_dev/sineWaveFlowGraph.py", line 211, in main
 if StrictVersion("4.5.0") <= StrictVersion(Qt.qVersion()) < 
StrictVersion("5.0.0"):
NameError: name 'StrictVersion' is not defined

Cheers,
Dan



Try:

sudo apt install packaging python3-packaging

Re: Qt ImportError

[Marcus D. Leech]

On 07/03/2023 15:05, Daniel R. Marlow wrote:

from PyQt5 import Qt

Make sure you have your system setup to run Python3 by default?

I have Ubuntu 22.04, same as you.  I don't have this problem. I 
installed everything from APT packages.

Re: Spurs in UBX-160 Daughterboard with USRP X310

[Marcus D. Leech]

On 06/03/2023 08:54, Dor Ratz wrote:

Hey Marcus,

Thanks a lot.

I'm using external 10 MHz reference clock (REFCLK) with 1e-12[Hz] 
frequency resolution -> it feeds my PLL in the UBX-160 daughterboard 
in the X310 USRP.
The REFCLCK input to the X310 is used to control the master-clock(s) on 
the motherboard, which, in turn produce clocks for
  the daughtercards--but the daughtercards never see your external 
clock directly.


So, *when defining "mode_n=integer"* in the Device Address parameter 
of the UHD: USRP Sink block in GNURadio to set PLL in integer-N mode, 
*what is exactly R-DIVIDER= reference divider of the PLL*?


I've looked in the PLL (max2871) datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf

According to it:
"The minimum R counter divide ratio is 1, and the maximum divide ratio 
is 1023"


I understand that if for example, the R counter=(R-DIVIDER)=1000 -> 
the frequency resolution is 10MHz/1000 = 0.01MHz= 10KHz, correct?


But I don't know what is the R-DIVIDER chosen in the PLL with the 
settings in gnuradio.


Thanks,

Dor

You'd have to go looking through the source code.  Unless someone from 
R happens to know off the top of their heads.
  10 years ago, I kept all of this in my head--when there were FAR 
fewer products to keep track of and the codebase was

  more modest.









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


On 02/03/2023 13:09, Dor Ratz wrote:

Hey,

Do you know how to assess the RF PLL resolution in integer-N mode?

I've looked in ANALOG max2871 PLL datasheet - not sure I found
the answer there.

https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf

The Ettus team is CC here too - it will be helpful to know what
you suggest.

Thanks,
Dor

It will depend on the REFCLK that is being used by that board (I
do not happen to know off the top of my head), and by
  whatever flexibility in reference divider the PLL has.

In an Integer-N PLL (and you can spend quite a bit of time
learning how PLL synthesizers work online), the "step size" is
  dependent on the REFCLK, which itself may have a divider on it. 
So, let's say your REFCLK is 10MHz and there's a divider
  that can divide the reference clock by up to 1, then your
minimum step size is 1kHz.   This is in tension with the
  fact that having a high ratio between the desired frequency and
the reference frequency tends to create signal-quality issues,
  like, as I recall, phase noise.  But I'd research the datasheet
and the overall concept of PLL synthesis.

My recollection on the X310 is that the reference-clock frequency
is 100MHz, but that's just a hazy memory.






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

On 01/03/2023 13:14, Dor Ratz wrote:

Hey Marcus, How are you?

Not sure if you got my email.

Do you know anyway I can change transmitted frequency using
PMT message when doing your solution?


In addition, something that seemed to help me:

I used this:


https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html


In the USRP Sinc block, in center frequency parameter, I've
put this:

uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)

With this, the transmitted 1003MHz signal is cleaner and the
spur is now further away at 16KHz offset with amplitude of
60dBc below the signal.

This alone cleans the spectrum!

In addition, I type "mode_n=integer" in the
Device Address parameter of the UHD: USRP Sink block, but it
doesn't seem to affect. The tuning without DSP correction in
the FPGA seems to just be sufficient to clean the spectrum.

Why is that? Do you recommend using something else?

Thanks

Dor

Note that only works if the underlying RF PLL has enough
"resolution" to make that work--particularly in integer-N mode.

I'm surprised that the DDC/DUC have such significant "close
in" spurs.    I don't know if there's anyone from the R team
  on here who can authoritatively comment, but this is a bit
of a surprise.






‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת ‪Dor Ratz‬‏
<‪dorrat...@gmail.com‬‏>:‬

Hi Marcus,

Can I pass the desired center frequency with a PMT message?
I want to dynamically change the transmitted center
frequency of UHD: USRP Sink block.

So static frequency in the block is not sufficient.

Thanks
Dor

‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת ‪Marcus
Müller‬‏ <‪marcus.muel...@ettus.com‬‏>:‬

Hi Dor,

 

Re: Spurs in UBX-160 Daughterboard with USRP X310

[Marcus D. Leech]

On 02/03/2023 13:09, Dor Ratz wrote:

Hey,

Do you know how to assess the RF PLL resolution in integer-N mode?

I've looked in ANALOG max2871 PLL datasheet - not sure I found the 
answer there.

https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf

The Ettus team is CC here too - it will be helpful to know what you 
suggest.


Thanks,
Dor
It will depend on the REFCLK that is being used by that board (I do not 
happen to know off the top of my head), and by

  whatever flexibility in reference divider the PLL has.

In an Integer-N PLL (and you can spend quite a bit of time learning how 
PLL synthesizers work online), the "step size" is
  dependent on the REFCLK, which itself may have a divider on it. So, 
let's say your REFCLK is 10MHz and there's a divider
  that can divide the reference clock by up to 1, then your minimum 
step size is 1kHz.   This is in tension with the
  fact that having a high ratio between the desired frequency and the 
reference frequency tends to create signal-quality issues,
  like, as I recall, phase noise.  But I'd research the datasheet and 
the overall concept of PLL synthesis.


My recollection on the X310 is that the reference-clock frequency is 
100MHz, but that's just a hazy memory.







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


On 01/03/2023 13:14, Dor Ratz wrote:

Hey Marcus, How are you?

Not sure if you got my email.

Do you know anyway I can change transmitted frequency using PMT
message when doing your solution?


In addition, something that seemed to help me:

I used this:

https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html


In the USRP Sinc block, in center frequency parameter, I've put this:

uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)

With this, the transmitted 1003MHz signal is cleaner and the spur
is now further away at 16KHz offset with amplitude of 60dBc below
the signal.

This alone cleans the spectrum!

In addition, I type "mode_n=integer" in the
Device Address parameter of the UHD: USRP Sink block, but it
doesn't seem to affect. The tuning without DSP correction in the
FPGA seems to just be sufficient to clean the spectrum.

Why is that? Do you recommend using something else?

Thanks

Dor

Note that only works if the underlying RF PLL has enough
"resolution" to make that work--particularly in integer-N mode.

I'm surprised that the DDC/DUC have such significant "close in"
spurs.    I don't know if there's anyone from the R team
  on here who can authoritatively comment, but this is a bit of a
surprise.






‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת ‪Dor Ratz‬‏
<‪dorrat...@gmail.com‬‏>:‬

Hi Marcus,

Can I pass the desired center frequency with a PMT message?
I want to dynamically change the transmitted center frequency
of UHD: USRP Sink block.

So static frequency in the block is not sufficient.

Thanks
Dor

‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת ‪Marcus Müller‬‏
<‪marcus.muel...@ettus.com‬‏>:‬

Hi Dor,

>  1. How to change the to integer_n tuning? Should I
just type "mode_n=integer" in the
>     Device Address parameter of the UHD: USRP Sink
block in the grc?

yes. Or, better, instead of just tuning to the target
frequency, you can pass a
uhd.tune_request_t to
uhd_usrp_{sink,source}.set_center_frequency, like this:

my_uhd_block.set_center_frequency(uhd.tune_request_t(
               target_freq = 2.4e9,
               args="mode_n=integer"))

(you can also use a uhd.tune_request_t in the RF
frequency fields of the GRC block)

Note that you're probably best off using tune_request_t
anyway, as it allows you to tune
your LO far away from your band of interest, given the
analog bandwidth allows for that,
using `target_freq=` and `rf_freq` or `dsp_freq`.

For more information on tuning, see the UHD manual [1]

>  2. How to know for sure what the mode(integer of
fractional) of the NCO is? Can I print
>     its status/get it somehow?

looking at the UHD source code: the routines responsible
for tuning just themselves check
for "mode_n" being set to "integer" in the device or tune
request arguments.

Best regards,
Marcus

[1]
https://files.ettus.com/manual/page_general.html#general_tuning

Re: Spurs in UBX-160 Daughterboard with USRP X310

[Marcus D. Leech]

On 01/03/2023 13:14, Dor Ratz wrote:

Hey Marcus, How are you?

Not sure if you got my email.

Do you know anyway I can change transmitted frequency using PMT 
message when doing your solution?



In addition, something that seemed to help me:

I used this:

https://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html


In the USRP Sinc block, in center frequency parameter, I've put this:

uhd.tune_request(target_freq=1003e6, dsp_freq=0,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)

With this, the transmitted 1003MHz signal is cleaner and the spur is 
now further away at 16KHz offset with amplitude of 60dBc below the signal.


This alone cleans the spectrum!

In addition, I type "mode_n=integer" in the
Device Address parameter of the UHD: USRP Sink block, but it doesn't 
seem to affect. The tuning without DSP correction in the FPGA seems to 
just be sufficient to clean the spectrum.


Why is that? Do you recommend using something else?

Thanks

Dor
Note that only works if the underlying RF PLL has enough "resolution" to 
make that work--particularly in integer-N mode.


I'm surprised that the DDC/DUC have such significant "close in" 
spurs.    I don't know if there's anyone from the R team

  on here who can authoritatively comment, but this is a bit of a surprise.






‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-15:08 מאת ‪Dor Ratz‬‏ 
<‪dorrat...@gmail.com‬‏>:‬


Hi Marcus,

Can I pass the desired center frequency with a PMT message?
I want to dynamically change the transmitted center frequency of
UHD: USRP Sink block.

So static frequency in the block is not sufficient.

Thanks
Dor

‫בתאריך יום ב׳, 27 בפבר׳ 2023 ב-13:44 מאת ‪Marcus Müller‬‏
<‪marcus.muel...@ettus.com‬‏>:‬

Hi Dor,

>  1. How to change the to integer_n tuning? Should I just
type "mode_n=integer" in the
>     Device Address parameter of the UHD: USRP Sink block in
the grc?

yes. Or, better, instead of just tuning to the target
frequency, you can pass a
uhd.tune_request_t to
uhd_usrp_{sink,source}.set_center_frequency, like this:

my_uhd_block.set_center_frequency(uhd.tune_request_t(
               target_freq = 2.4e9,
               args="mode_n=integer"))

(you can also use a uhd.tune_request_t in the RF frequency
fields of the GRC block)

Note that you're probably best off using tune_request_t
anyway, as it allows you to tune
your LO far away from your band of interest, given the analog
bandwidth allows for that,
using `target_freq=` and `rf_freq` or `dsp_freq`.

For more information on tuning, see the UHD manual [1]

>  2. How to know for sure what the mode(integer of
fractional) of the NCO is? Can I print
>     its status/get it somehow?

looking at the UHD source code: the routines responsible for
tuning just themselves check
for "mode_n" being set to "integer" in the device or tune
request arguments.

Best regards,
Marcus

[1]
https://files.ettus.com/manual/page_general.html#general_tuning

Re: Galileo Frequency Shifting and Filtering

[Marcus D. Leech]

On 01/03/2023 13:01, Kyeong Su Shin wrote:

Hello all:

Regarding the signal amplification:

  * Amplifiers CAN improve the SNR, when used properly. The idea is to
minimize the noise figure of the receive chain by putting a good
LNA and filters (prevents LNA overload) in front of the
chain(Friis law for noise). Since wideband SDRs often do not have
great Rx frontend (claimed noise figures are often not met in
real-world environments, due to the lack of preselector
filtering), these amplifiers in active GNSS antennas do actually
improve the signal quality.


I'll point out that:
    (A) Most "active" GPS/GNSS antennas have an LNA, and the antenna 
structure is a printed-on-high-Er-ceramic patch antenna.
  Such antennas are quite narrow-band, so, there's already 
filtering ahead of the pre-amp.   Such antennas are also,

  unfortunately, lossy, even within the pass-band.


  * That said, the gain level of such amplifiers is not that important
(as long as the level is somewhere around 20 - 30 dB). Their noise
figure is. Unfortunately, sellers and manufacturers often do not
publish the typical noise figure of the circuits.

If you care about noise figure, then your receiver noise-figure doesn't 
really matter as much as the LNA that physics and
  coaxial cable dictates you have right up at the antenna.  Unless your 
receiver is literally dangling off the antenna outdoors,
  its noise figure (as long as it isn't totally horrific) doesn't 
actually matter that much because you'll have an LNA right up
  at the antenna.    Active GPS/GNSS antennas satisfy this requirement 
already to a great extent.  The problem is that in
  most environments (except perhaps rural and middle-of-nowhere), you 
*need* some filtering ahead of the LNA, which
  necessarily eats into the noise figure of the LNA.  (See, as you say, 
Friis noise chain analysis).




  * Still (as mentioned several times already), you are probably not
going to see the real signals on your spectrum plot. Matched
filtering is necessary (or maybe cyclostationary detectors?) .
Using simulated signals is not a bad idea, I think, since that
would make debugging a bit easier.

The only situation in which you'd see the signal (as an extended 
increase in the apparent noise floor) is when your
  front-end noise figure is really really low, and perhaps you're 
pointing at only a single GPS satellite.


The "trick" in GPS and similar spread-spectrum systems is that if you 
know the spreading code and offset, you can
  "despread" the signal, vastly increasing the effective SNR on the 
underlying BPSK signal and proceed from there.  But
  the signal architecture was *deliberately* designed so that you 
couldn't "see" it with ordinary equipment if you didn't

  know the spreading code.





 *

Regards,
Kyeong Su Shin


*보낸 사람:* It's a cat  대신 
discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org 


*보낸 날짜:* 2023년 3월 1일 수요일 오후 10:55
*받는 사람:* David Dima 
*참조:* GNURadio Discussion List 
*제목:* Re: Galileo Frequency Shifting and Filtering
Amplifier only increase power (signal plus noise), they can't give you 
better SNR.
Anyway, It's much better to use a CW signal generator to help you 
debug the frequency converter chain (remember to keep output power 
low, e.g. -60dBm). You can use freq sink to check every stage of your 
flowgraph, and use Range / slider widget to control block parameters 
to search and check. If the signal disappears, or the passband doesn't 
meet your requirement, the problem can be easily located.



David Dima  于2023年3月1日周三 21:50写道：

Hi,

Sure, but the power of this kind of signals is below noise level.
Current antenna amplifies 30dB but it still not enough to see
anything in the spectrum (I have checked it alredy).

Regards,
David


El mié., 1 mar. 2023 7:27, It's a cat 
escribió:

If you have a signal generator, GNSS simulator or a high gain
antenna, you can verify your settings by adding a spectrum
display (Qt Freq Sink) or something like that to your receiver
path.
Because many things can go wrong in your setup, if you
misunderstand something. Just try to verify this directly. If
there's a signal you should be able to see it on the spectrum
display.


David Dima  于2023年2月28日周二 02:00写道：

Hi guys,
I am trying to simultaneously record Galileo's E5a and E5b
signals as follows:
imagen.png
I have tried to record them separately by tuning the local
oscillator in the middle of the signals bandwidths and
sampling at 25MHz and it worked. But when I try to shift
and filter to get the signals in a different file, it does
not work. I have no idea what am i doing wrong.
Galileo's Signal Plan is as 

Re: Galileo Frequency Shifting and Filtering

[Marcus D. Leech]

On 01/03/2023 08:50, David Dima wrote:

Hi,

Sure, but the power of this kind of signals is below noise level. 
Current antenna amplifies 30dB but it still not enough to see anything 
in the spectrum (I have checked it alredy).


Regards,
David
You generally won't be able to see GPS signals in the spectrum--unless 
you have a spectacularly good LNA right up at
  your antenna, and that antenna better not be a dielectric patch 
antenna (as is typical for GNSS/GPS antennas).






El mié., 1 mar. 2023 7:27, It's a cat  escribió:

If you have a signal generator, GNSS simulator or a high gain
antenna, you can verify your settings by adding a spectrum display
(Qt Freq Sink) or something like that to your receiver path.
Because many things can go wrong in your setup, if you
misunderstand something. Just try to verify this directly. If
there's a signal you should be able to see it on the spectrum display.


David Dima  于2023年2月28日周二 02:00写道：

Hi guys,
I am trying to simultaneously record Galileo's E5a and E5b
signals as follows:
imagen.png
I have tried to record them separately by tuning the local
oscillator in the middle of the signals bandwidths and
sampling at 25MHz and it worked. But when I try to shift and
filter to get the signals in a different file, it does not
work. I have no idea what am i doing wrong.
Galileo's Signal Plan is as follows:

Re: Error With GPSDO USRP x300

[Marcus D. Leech]

On 22/02/2023 18:14, Jones, James (jtjones49) wrote:
Hello, I have a USRP x300 and I am trying to use the GPS module for 
clock sync. I am running Ubuntu 20 and am using external GPS antennas 
and am using GNUradio version 3.10.5.1 . I have the following 
arguments for the USRP source block:


Sync: Unknown PPS
Time Source: Default
Clock Source: O/B GPSDO

However, when running this block I get the following error:

Traceback (most recent call last):
  File "/home/.../Documents/test.py", line 290, in 
    main()
  File "/home/.../Documents/test.py", line 268, in main
    tb = top_block_cls()
  File "/home/.../Documents/test.py", line 92, in __init__
self.uhd_usrp_source_0_0.set_clock_source('gpsdo', 0)
RuntimeError: RuntimeError: Reference Clock PLL failed to lock to 
gpsdo source.


Any help is appreciated and thank you to Marcus Müller for helping me 
resolve the incompatibility with the USRPs.


James Jones

Oh, also, if there's a source connected to the external REF IN 
connector, try disconnecting it.  On at least *some* hardware
  versions the external clock input can interfere with the on-board 
GPSDO clock.

Re: Error With GPSDO USRP x300

[Marcus D. Leech]

On 22/02/2023 18:14, Jones, James (jtjones49) wrote:
Hello, I have a USRP x300 and I am trying to use the GPS module for 
clock sync. I am running Ubuntu 20 and am using external GPS antennas 
and am using GNUradio version 3.10.5.1 . I have the following 
arguments for the USRP source block:


Sync: Unknown PPS
Time Source: Default
Clock Source: O/B GPSDO

However, when running this block I get the following error:

Traceback (most recent call last):
  File "/home/.../Documents/test.py", line 290, in 
    main()
  File "/home/.../Documents/test.py", line 268, in main
    tb = top_block_cls()
  File "/home/.../Documents/test.py", line 92, in __init__
self.uhd_usrp_source_0_0.set_clock_source('gpsdo', 0)
RuntimeError: RuntimeError: Reference Clock PLL failed to lock to 
gpsdo source.


Any help is appreciated and thank you to Marcus Müller for helping me 
resolve the incompatibility with the USRPs.


James Jones

Did you source the GPSDO from Ettus/NI, or from somewhere else?  Can you 
confirm that it's connected correctly?


If you look at the on-board LEDs here:

https://kb.ettus.com/X300/X310#On-Board_LEDs

What does the GPS LOCK light say after a few (10s of) minutes being 
connected to the antenna?

Re: Spurs in UBX-160 Daughterboard with USRP X310

[Marcus D. Leech]

On 21/02/2023 08:43, claudio.franch...@tlrnet.eu wrote:


Hi Dor,

   if the 6kHz spurious from the carrier are discrete, it 
has nothing to do with phase noise, but rather could be residuals from 
fractional divisions of the NCOs. On the other hand, with reference to 
the measurements reported in the document that you find here 
https://files.ettus.com/performance_data/ubx/, on page 230 and 385, it 
can be seen that the output power with 15dB of gain should be around 
to +5/+6dBm, at least that's what it looks like. 2dB or 3dB of 
difference are not negligible, I wouldn't want there to be 
intermodulation at the input, but then you should see replicas even 
further away from the carrier.


Try to attenuate the input level a little: if the spurs decrease 
non-linearly it is input intermodulation, otherwise they are spurious 
from the NCO.


Claudio


The PLL synthesizer is the MAX2871, datasheet below:

https://www.analog.com/media/en/technical-documentation/data-sheets/max2871.pdf

The TX-side mixer is the ADL5375, datasheet below:

https://www.analog.com/media/en/technical-documentation/data-sheets/ADL5375.pdf

These two components will dominate in terms of phase-noise and spur 
performance.


You might try setting the synthesizer in integer-N mode, if your target 
frequency is amenable to integer_n tuning:


https://files.ettus.com/manual/structuhd_1_1tune__request__t.html


*From:* discuss-gnuradio-bounces+claudio.franchini=tlrnet...@gnu.org 
 *On 
Behalf Of *Dor Ratz

*Sent:* Tuesday, February 21, 2023 12:41 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Spurs in UBX-160 Daughterboard with USRP X310

Hello,

I have some problems with spurs in ubx-160 daughterboard with USRP 
X310. Interesting thing.


I transmit in Gnuradio simple signal source of cosine wave in 
frequency 1003MHz with Gain=15dB and connect the USRP to spectrum 
analyzer.


I can see the signal in 1003MHz in +8dBm as expected, but why do I see 
spur in 1003.006MHz (6KHz offset) at amplitude of (-40dBc) relative to 
the transmitted signal?


It can be seen when with small enough RBW and span values in the 
spectrum analyzer.


As far I understand from ubx 160 daughterboard RF information spec, 
the phase noise should be (-90dBc/Hz) -(-100dBc/Hz) and not that high 
as I get.


I don't know if my spur source is phase noise or some other spectral 
issue.


I'm well below  the values of Tx max power and TX OIP3 of ubx-160.

Thanks a lot for any advice.

Re: Issue with UHD and GNUradio

[Marcus D. Leech]

On 15/02/2023 18:13, Jones, James (jtjones49) wrote:
Hello, I need to use the latest version of UHD to work with my USRP 
image. The version that comes with GNUradio will not work as it is not 
updated. I have the latest version of UHD installed on my computer, 
but when installing GNUradio it installs and uses the outdated and 
incompatible version of UHD. How can I change GNUradio to use the 
version of UHD installed on my computer? I am running Ubuntu 20 and 
was originally following the instructions sent by Ettus Research 
attached to this email.


If you need any more information, please ask and thank you.


I'll note that Ubuntu 22.04 has more-recent versions of both GR and UHD:

GR  3.10.1.1
UHD 4.1.0.5-3

You didn't mention which USRP you have -- for some of them, there 
haven't been any meaningful updates in at least

  a couple or three years.   So older UHD will be just fine.

Re: Galileo E5a and E5b bands simultaneously receiver with GRC

[Marcus D. Leech]

On 14/02/2023 15:16, Sylvain Munaut wrote:

Hi,



- Number of channels: 1 ( Since USRP 2190 model has only 1 local oscillator, it 
will not be possible to use 2 simultaneously channels for receiving)

Well, you could still tune the RF between the two freq and then use
the DDC to shift and decimate each channel separately so that you can
have a sample rate much much lower than bringing the full 50 MHz to
the PC.
It saves on USB traffic, making it more reliable and on host side processing.

Just my 2 ct.

Cheers,

Sylvain


You presumably mean the USRP 2901 ?

In which case, yes, there's only 1 LO shared between the two RX inputs.


You'll need to explore here:

https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

Using a RF tuning policy of "manual" and a DSP tuning policy of 
"manual", and extract the appropriate pieces.

Re: How to display a part of the GRC spectrum?

[Marcus D. Leech]

On 03/02/2023 12:44, George Edwards wrote:

Hi Marcus,

I do not have any hardware. I am doing everything in simulation. I 
designed the grc to translate a QPSK modulated signal to a rf freq of 
1GHz at a sample rate of 3GHz. Running this signal into QT freq sink 
or a webgui freq sink shows the upconverted modulated signal at 1GHz, 
with a support base that is miniscule over such a wide freq range +/- 
1.5 GHz. So I would like to know if there is a way to instruct either 
GUI's such that the display pops up over a range of 1G +/- 2 MHz or a 
range of my choosing at the sample rate I am working at?


Thank you!
George
If it's just in simulation, I guess I don't understand why you need to 
"simulate" such high sample rates if your signal is only fairly
  narrow.  It is usually the case that for actual hardware, signals are 
delivered as a complex baseband at whatever your sample
  rate is.  You might need to shift stuff around a bit sometimes, which 
is where the frequency-xlating filters and friends come

  into play.

In simulation, you almost never need to simulate the actual radio 
hardware *at its operating frequencies and bandwidths*.
  In fact, doing that in Gnu Radio *in real time* would be extremely 
challenging on ordinary computers the frequencies

  you've quoted.

When folks talk about Gnu Radio as a "useful simulation tool", they're 
mostly talking about simulating DSP
  processing chains *at the rates typically seen in complex baseband 
delivered by hardware*, and NOT necessarily
  about it being a tool that is useful to simulate actual hardware -- 
at least, not in real time.





On Fri, Feb 3, 2023, 9:38 AM Marcus D. Leech  
wrote:


On 03/02/2023 11:30, George Edwards wrote:

Hi Fabian,
Thanks for your suggestion!

However, it will not help me because I would like to see the
spectrum displayed over the proper range 1GHz +/- 4MHz.

George


I think we now need more information about your setup.  What type
of hardware?    I know of no hardware that can deliver
  samples at 3Gsps into a host computer that is also compatible
with Gnu Radio.

Processing samples at 3Gsps in an ordinary computer even with
blazing-edge current CPU tech is a "significant challenge",
  and you sure as heck aren't going to do it in Gnu Radio.

My *suspicion* is that you're confused about the difference
between the *desired center frequency*, bandwidth, and corresponding
  sample rate.



On Fri, Feb 3, 2023, 9:06 AM Fabian Schwartau
 wrote:

Hi George,

I don't know if the Frequency sink can do that for you, but I
guess it
cannot.
One way is to mix the signal with a complex oscillation and a
multiplier
with the oscillator running at the negative frequency you
wish to
downshift the signal. Then low-pass filter and downsample the
signal.
You can then feed that into the Frequency sink and also set you
oscillator frequency as offset frequency in the sink's settings.

Best,
Fabian

Am 03.02.23 um 16:52 schrieb George Edwards:
> Dear GNURadio Community,
>
> Let's say I build a GRC flowgraph operating at a sample
rate of 3 GHz
> and wish to display the spectrum over the fixed range of
1GHz +/- 4MHz,
> how do I get the QT GUI Frequency sink to plot over this range?
>
> Thank you!
>
> George

Re: How to display a part of the GRC spectrum?

[Marcus D. Leech]

On 03/02/2023 12:07, George Edwards wrote:

Thank you Marcus, thank you everyone!

A more fundamental question I have is: Let's assume I was working at a 
low sample rate, say 32 kHz. Both the QT Freq GUI and the webgui would 
display a spectrum between -16 kHz +16 kHz. Suppose, I would like the 
displays to pop-up over the range 5-12 kHz, is there a way to instruct 
either the QT or webgui block to plot what I consider my range of 
interest at a sample rate of 32 kHz?


Thanks for all your inputs.

Regards,
George
Yeah, you can just use the UI controls to "zoom in" if that's all you 
care about.


If you want it (the GUI block) to be only "seeing" that spectrum, then 
the frequency-xlating FIR/FFT filter does what you want.





On Fri, Feb 3, 2023, 9:12 AM Marcus Müller  wrote:

First of all, that's a high sampling rate!

You would want to shift the signal (e.g using the "Rotator" block, or
just by using a signal source at the shift frequency and a
(conjugate)
multiplication), then decimate it by a factor of 3 GHz / 8 MHz = 375.

 From a point of view of designing the decimator, decimation by
375 is
quite a mouthful - it requires a filter transition width of
significantly less than 1/375 of the input Nyquist rate. So, it would
seem advisable to do this decimation in a cascade of decimators –
in the
extreme case, decimation by 3, by 5, by 5, by 5.

Best regards,
Marcus

On 2/3/23 16:52, George Edwards wrote:
> Dear GNURadio Community,
>
> Let's say I build a GRC flowgraph operating at a sample rate of
3 GHz
> and wish to display the spectrum over the fixed range of 1GHz +/-
> 4MHz, how do I get the QT GUI Frequency sink to plot over this
range?
>
> Thank you!
>
> George

Re: How to display a part of the GRC spectrum?

[Marcus D. Leech]

On 03/02/2023 11:30, George Edwards wrote:

Hi Fabian,
Thanks for your suggestion!

However, it will not help me because I would like to see the spectrum 
displayed over the proper range 1GHz +/- 4MHz.


George

I think we now need more information about your setup.  What type of 
hardware?    I know of no hardware that can deliver
  samples at 3Gsps into a host computer that is also compatible with 
Gnu Radio.


Processing samples at 3Gsps in an ordinary computer even with 
blazing-edge current CPU tech is a "significant challenge",

  and you sure as heck aren't going to do it in Gnu Radio.

My *suspicion* is that you're confused about the difference between the 
*desired center frequency*, bandwidth, and corresponding

  sample rate.



On Fri, Feb 3, 2023, 9:06 AM Fabian Schwartau  wrote:

Hi George,

I don't know if the Frequency sink can do that for you, but I
guess it
cannot.
One way is to mix the signal with a complex oscillation and a
multiplier
with the oscillator running at the negative frequency you wish to
downshift the signal. Then low-pass filter and downsample the signal.
You can then feed that into the Frequency sink and also set you
oscillator frequency as offset frequency in the sink's settings.

Best,
Fabian

Am 03.02.23 um 16:52 schrieb George Edwards:
> Dear GNURadio Community,
>
> Let's say I build a GRC flowgraph operating at a sample rate of
3 GHz
> and wish to display the spectrum over the fixed range of 1GHz
+/- 4MHz,
> how do I get the QT GUI Frequency sink to plot over this range?
>
> Thank you!
>
> George

Re: How to display a part of the GRC spectrum?

[Marcus D. Leech]

On 03/02/2023 11:04, Fabian Schwartau wrote:

Hi George,

I don't know if the Frequency sink can do that for you, but I guess it 
cannot.
One way is to mix the signal with a complex oscillation and a 
multiplier with the oscillator running at the negative frequency you 
wish to downshift the signal. Then low-pass filter and downsample the 
signal. You can then feed that into the Frequency sink and also set 
you oscillator frequency as offset frequency in the sink's settings.


Best,
Fabian
That's pretty-much what the frequency-xlating FIR filter/FFT filter 
block is for...


Also, sampling at 3GHz?  Into an ordinary computer?  Really?




Am 03.02.23 um 16:52 schrieb George Edwards:

Dear GNURadio Community,

Let's say I build a GRC flowgraph operating at a sample rate of 3 GHz 
and wish to display the spectrum over the fixed range of 1GHz +/- 
4MHz, how do I get the QT GUI Frequency sink to plot over this range?


Thank you!

George

Re: Grc_gnuradio import blks2 replacement?

[Marcus D. Leech]

On 01/02/2023 13:03, George Edwards wrote:
Porting an older version of some code that used an earlier version of 
gnuradio libs, and am rebuilding with gnuradio 3.10.  Old code 
referred to an import of blks2 from grc_gnuradio which then fails with 
No module named grc_radio. Is there a replacement for that module?
My recollection is that stuff got reorganized and obsoleted in the 
3.6-->3.7 transition, and what remains ended up in

  gr-blocks in 3.7--not sure about 3.10.

Re: Qt widgets Improvement

[Marcus D. Leech]

On 29/01/2023 14:20, Rohit Bisht wrote:


I'd like to start with "integrating gnu with qt creator" because it 
would make it easier to write code in the integrated qt environment 
and speed up build, run, and testing. I believe adjusting the cmake 
file and fixing paths to missing library files would be the way to go 
(though I'll require more directions on that).


Then "adding new widgets" followed by "improving them" .
I guess it depends on what you think the dominant design doctrine should 
be  "gorgeous UI with the DSP as a kind of afterthought",
  or "robust DSP with the UI as a kind of afterthought".   I don't 
think that Qt designer is a particularly productive way to design

  the DSP bits of a DSP application.

The whole "form is more important than function" is a bit of leftover 
brain-death promulgated by Steve Jobs, and it was as

  wrong-headed then as it is now, IMHO.

Re: Dual-Frequency simultaneously receiver using one USRP 2901

[Marcus D. Leech]

On 26/01/2023 09:02, claudio.franch...@tlrnet.eu wrote:


Hi, David,

the USRP 2901 is a dual channel RTX, so it can definitely receive two 
different channels at the same time, i.e. two different (carrier) 
frequencies. We just have to see the management through GNURadio, but 
here I refer to those who are more experienced than me with the software.


In principle you can put a split downstream of the antenna and then go 
on the two channel inputs, however keep in mind that with the splitter 
you introduce a signal loss that can go from 3.5dB to 5dB or more, 
depending on the splitter (3dB is anyway theoretical and unavoidable). 
This means that, not only do you have the loss value of the splitter 
on the signal level, but even more marked the fact that it worsens the 
noise figure by the same amount. If the dynamics is enough it's fine, 
otherwise it would be better to use separate antennas. Be careful not 
to go into transmission on a channel if you use a splitter and a 
single antenna!


Claudio

*From:* discuss-gnuradio-bounces+claudio.franchini=tlrnet...@gnu.org 
 *On 
Behalf Of *David Dima

*Sent:* Thursday, January 26, 2023 9:33 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Dual-Frequency simultaneously receiver using one USRP 2901

Hi,

I am trying to simultaneously receive two signals from Galileo at 
different frequencies (1176.45 MHz and 1575.42 MHz) using a single 
antenna, a USRP 2901, and the GNU Radio Companion (GRC) software. I 
would like to know if it is possible to do this with a single USRP, 
that is, is the USRP able to receive two different frequencies at the 
same time?


In the affirmative case, is it ok to just split the incoming signal 
from the antenna with a splitter and connect it to two ports the USRP?


Many thanks in advance,

David

The USRP 2901 is the same as the USRP B210, and as such, uses an RF 
Front End (RFFE) chip that has only a SINGLE
  Local Oscillator in each direction.   The chip (AD9361) is designed 
for 2 x 2 MIMO applications where both channels are

  mutually coherent and tuned to the same frequency.

So you can't tune that front-end chip to a different frequency for each 
channel.   What you CAN do, using manual
  DDC tuning is have two narrower-band channels that aren't separated 
by more than about 30MHz, and you tune
  the RF hardware to half-way between your two channels.  But in your 
case, this won't work because your

  channels are too far apart


In terms of your splitter question--YES, this works just fine. I've even 
used cheap Satellite TV splitters in such applications
  without much issue--type-F to SMA adapters are readily available even 
through Amazon.

Re: **Cant use UHD SINK and UHD Source in the same flowgraph

[Marcus D. Leech]

On 16/01/2023 16:30, Taylor Clark wrote:

sorry about that,

I am away from the laptop but I am using
maint3. 8-gnauradio(v3.8.5.0 to be specific)
uhd v4. 3.0-rc2

I will also note I have tried gnuradio v3.9.4.0 and have the same 
problem. the device is claimed by one uhd block which functions.  I 
didn't know if gnuradio was in charge of executing the networking via 
uhd or not but I believe the uhd blocks are not started at the same 
time and uhd cannot claim a device that is already claimed


in the flowgraph I am targeting the same x410 with type=x4xx in the 
uhd sink and source block.


I am using a zmq server for getting data, adding crc and fec with 
modulation then outputting to uhd sink. Over an ssma cable on the 
physical device I plug tx/Rx into RX2.  I then use uhd source on the 
same flow graph to read it.


again, thank you for your consideration!

Are you specifying the SFP+ streaming-port address, or the management 
address?


Gnu Radio has no idea what UHD does "under the covers".    UHD knows how 
to deal with the situation where there's both a
  "source" and a "sink".  It has handled this configuration since the 
very beginning.


It would be useful to see your flow-graph (or, even better, a minimum 
flow-graph that displays the issue).


I don't have an X410 myself, but other network-based USRPs are used ALL 
THE TIME for flow-graphs that use it in both

  directions simultaneously...

Re: **Cant use UHD SINK and UHD Source in the same flowgraph

[Marcus D. Leech]

On 16/01/2023 09:52, Taylor Clark wrote:

Hey all,

I am using the x410 with a flowgraph that has uhd source and uhd sink 
in the same flowgraph however, I believe its because the device is 
already claimed.


Here is the output I am getting
  self.uhd_usrp_source_1 = uhd.usrp_source(
  File 
"/usr/local/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 
125, in constructor_interceptor

    return old_constructor(*args)
  File 
"/usr/local/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line 
2806, in make
    return _uhd_swig.usrp_source_make(device_addr, stream_args, 
issue_stream_cmd_on_start)

RuntimeError: LookupError: KeyError: No devices found for ->
Device Address:
    x4xx:

Is it possible to use these two together and have them claim the 
device as one


Regards,
Taylor Clark

This should "just work".

Can you share the flow-graph you're using, and the version of UHD and 
Gnu Radio?


In general, USRP-specific queries belong on the usrp-users mailing list, 
rather than here, although I agree that there's

  significant overlap in this question...

Re: Updating FPGA image on Ettus N321

[Marcus D. Leech]

On 10/01/2023 18:03, Joseph Maloyan wrote:

Hello,

I am currently trying to update the image of the FPGA. I am following 
the guide at this link...

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide

When I try to update through network, I get the following regarding 
mismatched compat numbers...



INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,skip_init=1

[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[INFO] [MPM.Rhodium-0] Enabling LO distribution board
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[ERROR] [MPM.PeriphManager] Major compat number mismatch for component 
`FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: Major 
compat number mismatch for component `FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully 
initialized!

[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc', 
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo', 
'/lib/firmware/n320.dts']' returned non-zero exit status 1

[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The 
task loop will now exit, things may not work.rpc::timeout: Timeout of 
1ms while calling RPC function 'reclaim'

[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at 
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not 
rpc->request_with_token("unclaim")) { 
uhd::_log::log(uhd::log::warning, 
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp", 
322, "MPMD", std::this_thread::get_id()) << "Failure to ack 
unclaim!";; } -> rpc::timeout: Timeout of 1ms while calling RPC 
function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function 
'update_component'


When I try to update through embedded mode I get the following...

INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,addr=192.168.1.230,skip_init=1

[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: No 
device 'e0006000.spi' in 'platform'
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully 
initialized!

[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc', 
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo', 
'/lib/firmware/n320.dts']' returned non-zero exit status 1

[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The 
task loop will now exit, things may not work.rpc::timeout: Timeout of 
1ms while calling RPC function 'reclaim'

[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at 
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not 
rpc->request_with_token("unclaim")) { 
uhd::_log::log(uhd::log::warning, 
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp", 
322, "MPMD", std::this_thread::get_id()) << "Failure to ack 
unclaim!";; } -> rpc::timeout: Timeout of 1ms while calling RPC 
function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function 
'update_component'


What is causing this? I currently have the latest version of USRP, and 
I have downloaded the latest images through sudo uhd_images_downloader.


Thanks
Joe



This is a fairly USRP-specific question, unrelated to Gnu Radio in 
particular.


This type 

Re: USRP B210 TX/RX switching between transmitting and receiving

[Marcus D. Leech]

On 10/01/2023 14:11, Daniel Estévez wrote:

On 10/01/2023 20:01, okan erturk wrote:

So TX has a priority over RX, am I right?


I don't now for sure, but I guess that would make sense, because 
typically you would be attempting to RX continuously, while TXing some 
bursts (which would leave gaps in the RX stream). I don't know if the 
RX gaps are missing samples, zeroed-out samples, or something else.


Best,
Daniel.


There's no interruption in the digital side of things.  The RX front-end 
will be connected to RX2 during transmission.  It will
  likely only "see" your transmissions if there isn't an antenna 
connected to the RX2 antenna port.

Re: USRP B210 TX/RX switching between transmitting and receiving

[Marcus D. Leech]

On 10/01/2023 14:01, okan erturk wrote:

So TX has a priority over RX, am I right?

Not sure what you mean by "priority".

The RX/TX port will be connected to the TX whenever it's transmitting.

The RX chain can either be connected to the RX2 port all the time, or if 
it's configured for
  TX/RX, the ATR (Automatic Transmit Receive) logic in the FPGA will 
switch the RX chain

  between the TX/RX and RX2 ports whenever there's an active transmission.

In the case of Karen's flow-graph, it transmits all the time, so the RX 
chain will be switched
  to the RX2 antenna port, regardless of what its preferred antenna 
setting is.


Now, IN ADDITION to all of this, since the maximum isolation between 
antenna ports is not
  super high, the RX chain WILL SEE YOUR TRANSMISSIONS.   You just need 
to be prepared for

  that.





On Tue, Jan 10, 2023, 21:54 Daniel Estévez  wrote:

On 09/01/2023 18:20, Karen young wrote:
> Hi,
>
> I want to use the single port (TX/RX) from USRP B210 to switch
between
> transmitting and receiving. I have selected "Ch0: Antenna:
TX/RX" for
> both the USRP sink and source blocks as shown in the figure. I
expect
> the TX/RX port will show orange light. But the USRP hardware still
> transmits through TX/RX port (Red light on), and receives
through RX2
> port (Green light on).
>
> What needs to be set if only using a single TX/RX port for
switching
> between transmitting and receiving?

Hi Karen,

It seems that you're trying to transmit continuously, since the
Signal
Source is delivering samples to the USRP sink all the time. The TX/RX
port cannot be used for simultaneous transmit and receive. It can
only
do one at a time (but can switch during the flowgraph execution).

To receive whenever you are not transmitting something, you need
to use
burst transmissions
(https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission).
I
think that if you do this, the USRP will switch to transmit when you
send it a burst, and will switch to receive whenever it has
nothing to
transmit.

Best,
Daniel.

Re: 3.9/3.10 and UHD Firmware

[Marcus D. Leech]

On 09/01/2023 20:25, Eric McDonald wrote:
I'm running Ubuntu 20.04 and have an x310.  I flashed it with the 
latest 'apt install libuhd-dev' which appeared to be UHD 4.3 and put 
the FPGA at capability 39. However, 'apt install gnuradio-dev' 
installs GR 3.10 which installs libgnuradio-uhd3.10.4 which installs 
libuhd3.15.0.


None of the usual uhd_find_devices utilities are installed nor are the 
images_downloader.py or the burner so I don't know how to update the 
firmware to match.


If it helps, below is what I see when trying to connect.

Thanks,
Eric

My guess is you have a PPA configured, and different components are 
being fetched from the regular Ubuntu repository and

  whatever PPA you're pointing at.

The default version of GR for Ubuntu 20.04 is GR 3.8.1.0.

You might try package "uhd-host" to get the host tools installed.

Re: AFSK Demodulator attempt fail

[Marcus D. Leech]

On 05/01/2023 20:32, ke wrote:

Hi.

I'm trying to demodulate an AFSK signal, but I'm getting intermittent 
signal on the output. What am I doing wrong?


The GRC file:

https://nas.egzi.duckdns.org/share.cgi?ssid=4977729dc7584c24ad4fd6c941e08301 





First thing that pops out at me is that it's unlikely that a satellite 
AFSK channel is going to have a deviation of 75K--that suggest
  broadcast FM band, and not the narrow-band FM channels that are 
typically used for AFSK data.   But that's just and

  educated guess.

Re: USRP B210 overflow and underflow

[Marcus D. Leech]

On 03/01/2023 17:31, Karen young wrote:

  Hi Marcus,

Great! I removed the high pass filter for comparison, do see much less 
underflow and overflow errors.
May I ask how do the over 1000 taps come from? I do not understand how 
you get this number.
If I have to use a high pass filter, how to reduce its effect on 
slowing down the operation speed?


Thanks
Karen
If you use the "High Pass filter taps" object, and hand it the same 
parameters you used, then do a len(x) on

  that object, it comes back at 1250.

The length of a FIR filter is proportional to the ratio between the 
sample-rate and the transition width. Gnu Radio
  uses a version of the Parks-McLellan filter-design algorithm (which 
is in turn a variant of Remez Exchange).
  The algorithms try to find a filter that is optimal both in length 
and passband parameters.  The filter length tends

  to grow considerably as this ratio gets larger.

This is basic DSP stuff, and not specific to Gnu Radio.  ANY DSP 
framework that uses FIR filters will have similar

  issues.

Now what you might want to do is generate the taps with the "High Pass 
Filter Taps" object, and then use those taps
  as the coefficients in a generic FFT filter--the FFT filters tend to 
be more computationally efficient for larger numbers
  of taps, where "larger" is somewhat system specific, but I tend to 
use them for anything where there are more than

  about 50 or 60 taps.






On Tue, Jan 3, 2023 at 5:00 PM Marcus D. Leech 
 wrote:


On 03/01/2023 16:53, Karen young wrote:

sample_rate is 5M
what it is you're doing at those rates: I am using a USRP B210 to
transmit and receive pulse signals using attached antennas. The
antennas work at 430MHz. See attached fig.
and what kind of computer/OS you're using:
image.png

One thing that struck me--your high-pass filter is very
compu-spendy -- with those parameters, there's over 1000 taps.
   That's considered rather chunky.

Since it's a decimation=1 filter, it will have to perform over
1000 multiply-accumulate operations and the matching shift
  operations on every sample.

That may be what's slowing you down.

Re: USRP B210 overflow and underflow

[Marcus D. Leech]

On 03/01/2023 16:53, Karen young wrote:

sample_rate is 5M
what it is you're doing at those rates: I am using a USRP B210 to 
transmit and receive pulse signals using attached antennas. The 
antennas work at 430MHz. See attached fig.

and what kind of computer/OS you're using:
image.png
One thing that struck me--your high-pass filter is very compu-spendy -- 
with those parameters, there's over 1000 taps.

   That's considered rather chunky.

Since it's a decimation=1 filter, it will have to perform over 1000 
multiply-accumulate operations and the matching shift

  operations on every sample.

That may be what's slowing you down.

Re: USRP B210 overflow and underflow

[Marcus D. Leech]

On 29/12/2022 10:56, Karen young wrote:

Hi,

I am using a USRP B210 to transmit and receive pulse signals using 
attached antennas, and try to measure the phase delay between the 
transmitted and received signals. I do not understand why the 
following problems are happening. What can I do to fix them? Attached 
is the model.


1. The usrp_source overflow and usrp_sink underflow errors occur 
frequently, the received signal (in Red) is jumping accordingly as 
shown in Fig 1.


2. Since the transmitted signal is positive pulse, I am expecting the 
received signal is also positive. While the received signals are: 
sometimes positive peak, sometimes negative peaks as shown in Fig 2.


Thanks
Karen
Overruns and Underruns are caused by your computer being unable to "keep 
up" with the sample streaming requirements of

  the hardware.

You might add:

num_recv_frames=256
num_send_frames=256

To your device arguments, which can help "ride through" short-term 
performance insufficiency.

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

On 28/12/2022 23:55, Ali G. Dezfuli wrote:

seems it's ok:

$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; 
UHD_4.3.0.0-14-g1e718d9b

[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
  _
 /
|       Device: USRP2 / N-Series Device
|     _
|    /
|   |       Mboard: N200r4
|   |   hardware: 2576
|   |   mac-addr: 00:80:2f:0a:ce:45
|   |   ip-addr: 192.168.20.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: F1700B
|   |   name: ali_01
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |    /
|   |   |       RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |    /
|   |   |       RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |    /
|   |   |       RX Dboard: A
|   |   |   ID: WBX v3, WBX v3 + Simple GDB (0x0057)
|   |   |   Serial: EDR29PFXW
|   |   | _
|   |   |    /
|   |   |   |       RX Frontend: 0
|   |   |   |   Name: WBXv3 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |    /
|   |   |       TX DSP: 0
|   |   |
|   |   |   Freq range: -200.000 to 200.000 MHz
|   | _
|   |    /
|   |   |       TX Dboard: A
|   |   |   ID: WBX v3 (0x0056)
|   |   |   Serial: EDR29PFXW
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple 
GDB, WBX-120 + Simple GDB (0x004f)

|   |   |   Serial: EDR29PFGS
|   |   | _
|   |   |    /
|   |   |   |       TX Frontend: 0
|   |   |   |   Name: WBXv3 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None

You might try backing-out to UHD 4.2 or even UHD 4.1.0.5 (which is what 
is packaged with Ubuntu 22.04).


I recall (haven't found the thread on usrp-users yet) that there was a 
problem with the _cal utilities in UHD 4.3.


I'd recommend that you join the usrp-users mailng list, where more 
USRP-specific discussions take place.

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

On 28/12/2022 23:35, Ali G. Dezfuli wrote:

thanks Marcus,
I have checked benchmark_rate with no lost packets even at the highest 
rate of 25 Ms/s.

It is connected via ethernet 1G.

Isn't it because of outdated firmware and fpga?

If the FPGA code is out-of-date, UHD will complain.

What does

uhd_usrp_probe    have to say about it.





the output of benchmark_rate:

$ ./benchmark_rate --rx_rate 25e6

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; 
UHD_4.3.0.0-14-g1e718d9b

[00:00:00.000444] Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N200r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: WBXv3 RX+GDB
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: WBXv3 TX+GDB

[00:00:01.466484658] Setting device timestamp to 0...
[00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
[00:00:11.467783232] Benchmark complete.


Benchmark rate summary:
  Num received samples:     249982026
  Num dropped samples:      0
  Num overruns detected:    0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


Done!

On Thu, Dec 29, 2022 at 8:04 AM Ali G. Dezfuli  wrote:

thanks Marcus,
I have checked benchmark_rate with no lost packets even at the
highest rate of 25 Ms/s.
It is connected via ethernet 1G.

Isn't it because of outdated firmware and fpga?


the output of benchmark_rate:

$ ./benchmark_rate --rx_rate 25e6

[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
UHD_4.3.0.0-14-g1e718d9b
[00:00:00.000444] Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N200r4
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: WBXv3 RX+GDB
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: WBXv3 TX+GDB

[00:00:01.466484658] Setting device timestamp to 0...
[00:00:01.467214590] Testing receive rate 25.00 Msps on 1 channels
[00:00:11.467783232] Benchmark complete.


Benchmark rate summary:
  Num received samples:     249982026
  Num dropped samples:      0
  Num overruns detected:    0
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


Done!

On Wed, Dec 28, 2022 at 7:00 PM Marcus D. Leech
 wrote:

On 28/12/2022 04:55, Ali G. Dezfuli wrote:
> Hi all,
> I have gnuradio on this system:
> ubuntu 22.04
> uhd 4.3.0.0-14-g1e718d9b
> gnuradio v3.11.0.0git-316-gc11667ef
>
> I have a USRP N200 from 2011 but have not worked with it for
the last
> couple of years.
> After a long while, I just run $ uhd_cal_tx_dc_offset but
got the
> following error:
>
> Creating the usrp device with:
,ignore_cal_file=1,ignore-cal-file=1...
> [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
> UHD_4.3.0.0-14-g1e718d9b
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Running calibration for WBXv3 TX+GDB
> Daughterboard serial: EDR29PFXW
> Calibration frequency range: 68.75 MHz -> 2200 MHz
>

SSUSUS[WARNING]

> TX error detected! Repeating current iteration
>

SSU[WARNING]

> TX error detected! Repeating current iteration
>

SS[WARNING]

> TX error detected! Repeating current iteration
> SSS[WARNING] TX error detected! Repeating
current
> iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected! Repeating current iteration
> [WARNING] TX error detected

Re: usrp n200 problem: error when running uhd_cal_tx_dc_offset

[Marcus D. Leech]

On 28/12/2022 04:55, Ali G. Dezfuli wrote:

Hi all,
I have gnuradio on this system:
ubuntu 22.04
uhd 4.3.0.0-14-g1e718d9b
gnuradio v3.11.0.0git-316-gc11667ef

I have a USRP N200 from 2011 but have not worked with it for the last 
couple of years.
After a long while, I just run $ uhd_cal_tx_dc_offset but got the 
following error:


Creating the usrp device with: ,ignore_cal_file=1,ignore-cal-file=1...
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; 
UHD_4.3.0.0-14-g1e718d9b

[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
Running calibration for WBXv3 TX+GDB
Daughterboard serial: EDR29PFXW
Calibration frequency range: 68.75 MHz -> 2200 MHz
SSUSUS[WARNING] 
TX error detected! Repeating current iteration
SSU[WARNING] 
TX error detected! Repeating current iteration
SS[WARNING] 
TX error detected! Repeating current iteration
SSS[WARNING] TX error detected! Repeating current 
iteration

[WARNING] TX error detected! Repeating current iteration
[WARNING] TX error detected! Repeating current iteration
[WARNING] TX error detected! Repeating current iteration
[WARNING] TX error detected! Repeating current iteration
[WARNING] TX error detected! Repeating current iteration
[WARNING] TX error detected! Repeating current iteration
terminate called without an active exception
Aborted (core dumped)

I would be grateful if somebody helps me with this error.
regards
AGD
The occurrence of 'S' signifies a sequence-number error, the underlying 
cause of which is usually the network stack.


If you use the "benchmark_rate" example at modest sample-rates, does 
this still occur?



How are you connected to the USRP?  What type of network interface do 
you have?   Are you running on the native hardware,

  or in a VM?  Have you tried replacing the network cable?

Re: Is there something similar to the zero-span of spectrum analyzers in gnuradio?

[Marcus D. Leech]

On 19/12/2022 10:50, Juan Antonio wrote:

I think I'm not explaining myself well again.

What I want to see in the time domain is a single carrier of an 8mhz 
signal. That's why I was referring to the zero-span function of 
spectrum analyzers.


I have tried to isolate a single 1K carrier using filters but I did 
not get good results. That is why I was looking for something simpler, 
where simply indicating the frequency, I would have the output that 
specific frequency in the time domain. Something like a very narrow 
band  raw iq(or magnitude) demodulator
Isolating a 1KHz-wide signal from an 8MHz bandwidth in a single step is 
likely to create *enormous* filters.  Do you really need

  to bring in 8MHz of bandwidth?

If this were my problem, I'd use frequency-xlating-fft-filter to rotate 
the center of the desired carrier down to baseband, and

  then use a multi-stage filter-decimator chain to narrow the bandwidth.

I've said this in both this forum and others in the past.  Gnu Radio *IS 
NOT* a "radio with a lot of knobs to tweak", but a
  domain-specific software-development environment.    It's somewhat 
rare in Gnu Radio for there to be a "button I can push to
  make my answers come out".   What this means is that in order to be 
successful developing Gnu Radio flow-graphs
  to accomplish some specific task, there's usually some amount of 
background in signals, signal-processing, and software

  development required.

Another things to consider is this:  the field, loosely-described, as 
"useful and interesting things one might do at the
  intersection  between radio and computers" is likely approaching 
infinite.  Which means that no finite effort could
  ever possibly address each one of those useful and interesting 
things--some coding may be required.  This same observation
  applies to the software universe in general, even ignoring SDR and 
DSP and the like...

Re: 回复： 回复： Problems implementing USRP b210 dual channel transceiver

[Marcus D. Leech]

On 07/12/2022 07:49, 能书能言 wrote:
    The number of data packets in ① is not correct, but the number of 
data packets in ② is correct. Therefore, to avoid more problems, I 
choose ②.
    By viewing the pictures in the attachment and your explanation, f_ 
RF is LO frequency? Then the two channels share one LO, so setting f_ 
Offset adjusts the frequency to f_ target?

 I tried the following:
        freq1=   2.4G
    freq2=   2.39G
    lo_off1=   5M
        lo_off2=  -5M
    samp_rate=300K
    But the problem still exists, and the bit error rate is very high : (
Another thing I forgot to say is that I did a dual channel 
transmission experiment before (I call it experiment A. ), and the 
parameter settings are the same as when I first set them（freq1 = 2.4G, 
freq2=2.39G, lo_off1=2M, lo_off2=-2M,samp_rate=300k）,which performs 
very well. The only difference between experiment A and this 
experiment now is that the modulation of the signals on the RFA and 
RFB of experiment A are different. I copied the USRP sink and USRP 
source components directly from the GRC of experiment A, and the 
parameter settings are the same, experiment A performed very well, but 
in this experiment a high BER occurred, so now I am confused where the 
problem lies

Best regards！


You need to look *in detail* about how tune_request works.

In particular, the default policy for both the rf_freq and the dsp_freq 
is *AUTO*, which is not what you want in this case:


https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

You likely want to tune the LO to half-way between your two desired 
frequencies, and then use DSP offsets from that.


With a policy of "auto", it will try to tune the chip so that the 
specified frequency appears in the baseband, but using

  an offset tuning--that's not *quite* what you want.

You need to specify the same (in-the-middle) rf_freq for both channels, 
with MANUAL policy, and set the DSP offset

  appropriately, again with MANUAL policy.

Re: Implementation of OFDM TX and RX using GNURadio and USRP

[Marcus D. Leech]

On 27/11/2022 16:05, Daniel Estévez wrote:

On 27/11/2022 17:23, Marcus D. Leech wrote:

On 27/11/2022 05:26, Daniel Estévez wrote:


Hi,

Another option for extracting one or a range of items from a vector 
is to use Vector to Stream followed by Keep 1 in N or Keep M in N. 
See near the bottom of this flowgraph for an example:


https://github.com/daniestevez/reu-2022/blob/main/polyphase/polyphase_filter.grc 



Best,
Daniel.

That would only allow the first or first-N of the streams to be 
captured, rather than some arbitrary single stream, no?


No, because these blocks have an initial offset parameter (and if they 
didn't, we could use "Skip Head"). As an example, say that we have 
1024-point FFTs given as vectors and we only want the FFT bin number 42.


We do vector to stream, then Keep 1 in N with N = 1024 and initial 
offset = 42. This would give us a stream where only the FFT bin number 
42 appears.


Now say that w want FFT bin numbers 42, 43, 44, 45. We do vector to 
stream, then Keep M in N with N = 1024, M = 4, initial offset = 42. 
This would give us a stream that contains:


bin_42(t0), bin_43(t0), bin_44(t0), bin_45(t0), bin_42(t1), 
bin_43(t1), bin_44(t1), bin_45(t1)...


If desired, we can turn this into vectors of 4 elements using stream 
to vector or use a deinterleave block to separate each of the bins in 
its own stream.


Best,
Daniel.

Hah!  I've used "Keep One in N" and "Keep M in N" for *years*, and never 
noticed that!   Color me chagrined.

Re: Implementation of OFDM TX and RX using GNURadio and USRP

[Marcus D. Leech]

On 27/11/2022 05:26, Daniel Estévez wrote:


Hi,

Another option for extracting one or a range of items from a vector is 
to use Vector to Stream followed by Keep 1 in N or Keep M in N. See 
near the bottom of this flowgraph for an example:


https://github.com/daniestevez/reu-2022/blob/main/polyphase/polyphase_filter.grc 



Best,
Daniel.

That would only allow the first or first-N of the streams to be 
captured, rather than some arbitrary single stream, no?

Re: Implementation of OFDM TX and RX using GNURadio and USRP

[Marcus D. Leech]

On 26/11/2022 20:56, Al Amiri, Wesam (waalamiri42) wrote:

Thanks for your reply, Mr. Leech!

This is what I am trying to do in this stage, but my embedded python 
block causes the flowgraph to freeze when I run it.

I will try to figure out how to fix that!

Regards,
Wesam

*From:* discuss-gnuradio-bounces+waalamiri42=tntech@gnu.org 
 on behalf of 
Marcus D. Leech 

*Sent:* Saturday, November 26, 2022 6:44 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: Implementation of OFDM TX and RX using GNURadio and USRP

*External Email Warning*

*This email originated from outside the university. Please use caution 
when opening attachments, clicking links, or responding to requests.*



On 26/11/2022 15:19, Al Amiri, Wesam (waalamiri42) wrote:

Dears,

I am working on the implementation of OFDM TX and RX using GNURadio 
3.10.3 and USRP N210 (with UHD_4.2.0). In the implementation, I 
followed the GRC flow graph provided by GNU Radio Workshop (Slides 
259 - 260) with changing the carrier frequency to 2 GHz, Sampling 
rate 1MHz at TX, and 10 MHz for Rx.
The Tx USRP is connected to a Log Periodic antenna and similarly for 
the Rx USRP. There is no LOS between the TX and Rx antennas. They 
directed toward a reflective board so that the transmitted signal 
will be reflected by the board and received by the receiver. The 
implementation works fine, and I was able to receive the OFDM signal 
by the RX USRP.
What I am trying to do is to *extract some carriers from the FFT bins 
at the demodulator to do phase measurements on each one of the 
extracted carriers*.
I tried to create my own block to do that, but that didn't work and 
caused the GRC graph to freeze. Then, I tried to do that offline 
using Matlab, where I attached the FFT block to a file sink.
In Matlab, I plotted the absolute of I/Q samples of the file sink as 
shown in the attached figure. But still, I am not able to distinguish 
between the subcarriers.


Could anyone please give me advice how to extract certain carriers 
from the FFT bins of the demodulator?


Regards,
Wesam Al Amiri
Without completely dissecting your flow-graph, if this were MY 
problem, I might make an embedded Python block that allows me
  to select a single FFT bin and pass that along to an analysis 
function.  The FFT output is a vector, so it should be straightforward
  to implement a "pick a single carrier" function in Python, since 
your sample-rate is only 1Msps, and your FFT size is (I think) 64,
  that means your function has to deal with a new vector at 15kHz, 
which is achievable for a Python embedded block.


That's a quick thought based on an only superficial analysis of the 
problem, and others here might have better ways of

 doing it.


I just thought of this little "idiom" for picking a single item from a 
vector, that doesn't require that you write your own block.

  It takes advantage of "busports" (as a notational convenience).



The key here is the multiply-const, where you set the constant to a 
vector with a "1" in the position that you want to
 "pick", and 0s elsewhere.  Convert that to a set of streams, and then 
add the streams--in this case we use a bus-port
  on the output of the vector-to-streams and the input of the 'add'.  
Since only one of those streams will contain
  non-zero data after the multiply-const, you can see that this has the 
effect of picking only a single FFT "bin" as a
  sample stream, and doesn't require that you navigate the intricacies 
of writing your own embedded Python block.

  It's likely much faster, too.

This is a common need, I suspect, and I wonder if there's another block 
that does this, but with some other,

  clever, domain-specific name.



There are probably other idiomatic ways to do this, but this is what I 
thought of just a few minutes ago...

Re: Implementation of OFDM TX and RX using GNURadio and USRP

[Marcus D. Leech]

On 26/11/2022 15:19, Al Amiri, Wesam (waalamiri42) wrote:

Dears,

I am working on the implementation of OFDM TX and RX using GNURadio 
3.10.3 and USRP N210 (with UHD_4.2.0). In the implementation, I 
followed the GRC flow graph provided by GNU Radio Workshop (Slides 259 
- 260) with changing the carrier frequency to 2 GHz, Sampling rate 
1MHz at TX, and 10 MHz for Rx.
The Tx USRP is connected to a Log Periodic antenna and similarly for 
the Rx USRP. There is no LOS between the TX and Rx antennas. They 
directed toward a reflective board so that the transmitted signal will 
be reflected by the board and received by the receiver. The 
implementation works fine, and I was able to receive the OFDM signal 
by the RX USRP.
What I am trying to do is to *extract some carriers from the FFT bins 
at the demodulator to do phase measurements on each one of the 
extracted carriers*.
I tried to create my own block to do that, but that didn't work and 
caused the GRC graph to freeze. Then, I tried to do that offline using 
Matlab, where I attached the FFT block to a file sink.
In Matlab, I plotted the absolute of I/Q samples of the file sink as 
shown in the attached figure. But still, I am not able to distinguish 
between the subcarriers.


Could anyone please give me advice how to extract certain carriers 
from the FFT bins of the demodulator?


Regards,
Wesam Al Amiri
Without completely dissecting your flow-graph, if this were MY problem, 
I might make an embedded Python block that allows me
  to select a single FFT bin and pass that along to an analysis 
function.  The FFT output is a vector, so it should be straightforward
  to implement a "pick a single carrier" function in Python, since your 
sample-rate is only 1Msps, and your FFT size is (I think) 64,
  that means your function has to deal with a new vector at 15kHz, 
which is achievable for a Python embedded block.


That's a quick thought based on an only superficial analysis of the 
problem, and others here might have better ways of

 doing it.

Re: Changing USRP subdevice on the fly

[Marcus D. Leech]

On 22/11/2022 16:24, Moses Browne Mwakyanjala wrote:

Hi everyone,
I wrote a simple program for a usrp b210. I would like to change the 
RX antenna on the fly. That is, antenna 0 should be RX2 on Subdevice 
A:A and antenna 1 RX2 on Subdevice A:B as shown in the piece of code 
below. The problem I face is that I can't change the subdevice on the 
fly. The usrp->set_rx_subdev_spec(sRxSubDev) call doesn't seem to have 
any effect if it is called more than once. How should I proceed?


 std::string sRxSubDev;
 switch(m_Settings.m_nTMAntenna)
 {
 case 0:// Using antenna 1
 sRxSubDev = std::string("A:A");
 break;
 case 1:// Using antenna 2
 sRxSubDev = std::string("A:B");
 break;
 }
 usrp->set_rx_subdev_spec(sRxSubDev);
 usrp->set_rx_antenna("RX2");
Thanks in advance,
Moses.

You would likely have to tear down the streamer and start a new one.

Alternately, you could just stream both channels at the same time, and 
simply drop the samples from the part of the stream

  you don't care about.

Re: Changing AD9363 registers from Gnuradio level(or libuhd)

[Marcus D. Leech]

On 19/11/2022 08:33, Nikoloz Glonti wrote:

Dear Gnuradio community,

Is it possible to somehow control(read/write) AD93xx registers from 
level of gnuradio(or in libuhd)?
I would like to change settings of AGC in chip, but don't know where 
to start?


best regards
Niko



It depends on exactly what you want to do.

If you just want to turn AGC on/off, UHD (and the UHD source in Gnu 
Radio) already allows you to do that via the

  RF Controls.

If you want to modify things like the AGC setpoints, you'll have to dive 
below the API level, I think and modify UHD

  code.

UHD tries to present a unified API to applications, so that applications 
can be mostly "agnostic" with respect to the actual

  hardware in use.  So there isn't any "direct to the registers" API.

Re: Query about OFDM Receiver with USRP

[Marcus D. Leech]

On 17/11/2022 10:23, Al Amiri, Wesam (waalamiri42) wrote:

Hello,

I am working on the implementation of OFDM TX and  RX using USRP N210 
and GNURadio.
I used the the grc flow graphs done by GNURadio workshops and I was 
able to receive the OFDM signal and demodulate it.
Also, I connected a constellation sink to the Palyoad Stream Virtual 
Source at the RX side (after demodulation), and I got 4 constellation 
points which is corresponding

to the QPSK similar to the Tx cosntellation.
However, when I removed the Smidl and Cox synchronization to check the 
phase rotation from the CFO (please see attached) , I still have the 
same 4 constellation points without phase rotation. Do you know why 
this happens?
You haven't described your physical setup, but if you have TX 
looped-back to RX, there won't be any phase rotation since
  the TX and RX are both phase-locked to the same master oscillator 
on-board the N210.  In "real-life" scenarios, of course,

  there will be phase rotation between the TX and RX.




One more thing please, is there any way to extract a certain 
subcarrier from the FFT at the receiver side. I need to do some post 
processing on one of the subcarriers?


Regards,
Wesam Al Amiri

Re: Questions about the IF signal processing structure of USRP N210

[Marcus D. Leech]

On 12/11/2022 06:58, Ze Zhang wrote:

Hello Kyeong Su Shin

Thanks very much for your kindly reply.
First, the information about the software radio structure contains 
three kinds, which are Low-pass sampling architecture, RF direct 
band-pass sampling architecture, and IF band-pass sampling 
architecture. Among them, according to the second generation USRP 
structure, only the IF band-pass structure is designed for analog 
down-conversion.


The N210's structure(reference attachment) contains the DDC notation. 
And DDC contains the digital down conversion. As you 
mentioned thelow-frequency IF stage is optional.  Does this mean that 
the digital shifting in the IF is to adjust for the bias caused by the 
previous down-conversion?  Or this step can be controlled by command.


It is frequently the case that the frequency "step size" of a 
synthesized down/up-converter is finite and somewhat large.
  So, among other things, the DDCs are there to make sure that the I/Q 
signal delivered to the host computer is at exactly

  0Hz.

This process is normally completely automatic, but fine control over it 
is documented here:


https://files.ettus.com/manual/page_general.html#general_tuning

You haven't shared which daughtercard you're using with yoru N210--the 
details will change depending on which daughtercard.








Kyeong Su Shin  于2022年11月11日周五 16:52写道：

Hello Ze Zhang:

First, there is a dedeicated mailing list for USRP-specific
questions: USRP-users. https://kb.ettus.com/Mailing_Lists

"the information mentioned that the common structure for all USRPs
is the IF bandpass sampling structure," -> where did you find this
information? This is, in general, not true. USRP N200/N210s,
especially, usually default to zero-IF (direct conversion) mode
(not always, though).

In case of the USRP N200s/N210s, daughterboards implement the
RF/IF (if exists) stages of the transceivers and the motherboards
implement the baseband and the digital stages of the transceivers.
The daughterboards often do not have any IF stages, and directly
convert the signal to the baseband. The motherboards CAN implement
a low-frequency IF stage by digitally shifting the baseband
signals before the decimation stage. This is optional, and not
used by default.

Regards,
Kyeong Su Shin

*보낸 사람:* Ze Zhang  대신
discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org

*보낸 날짜:* 2022년 11월 11일 금요일 오후 3:56
*받는 사람:* discuss-gnuradio@gnu.org 
*제목:* Questions about the IF signal processing structure of USRP
N210

Hi,

I am using the URSP N210, and have some questions regarding the
internal IF (intermediate frequency) signal processing structure
of USRP N210.

In the websites, the information mentioned that the common
structure for all USRPs is the IF bandpass sampling structure, and
in the previous

question(https://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg7.html)
it was mentioned that USRP N210 is the common second generation
USRP structure.

So is there any difference between the second-generation USRP
structure and the digital IF transceiver structure? Also, what is
the IF frequency range of the RF signal received by the N210 after
analog down-conversion?

Is it possible to get the value of the local oscillator frequency
or the value of IF frequency by the setting carrier frequency?

Re: burst mode for hackrf one

[Marcus D. Leech]

On 05/11/2022 12:14, Roland Schwarz wrote:



I never complaint that the behavior is different from my expectations. 
(I inadvertently filed a bug, sorry for that.) Instead I am just 
looking for the correct point to start, without reinventing the wheel. 
Since documentation on the topic is sparse and understanding the data 
flow from looking at three different layers, which are not implemented 
in the same way as you say is hard, I thought I could try to get some 
insight from the knowledgeable's on this list. :-)


Now *some* of this can kind of sort of be "faked" in the drivers. But 
things like hardware-precise burst timing?  Nope.


As a first step I am not looking for 'precise' burst timimg. When I 
create a burst PDU and convert it with PDU to Stream I am happy if 
that packet is sent out by the transmitter. Currently the send buffer 
waits until it is full before any data gets out of the tx.
So it seems that the question you're *actually* asking is somewhat 
disjoint from the question I *thought* you were asking--

  my apologies.

It *sounds* like you want to understand how to get "bursty" behavior 
from Gnu Radio's overall "streaming" doctrine--and THAT

  is only tangentially related to the underlying hardware.

"I created a PDU, sent it through the modulators, but the resulting 
buffer is small enough that it's getting 'hung up' inside GR".
   Since I'm not a TX guy primarily, I'm not actually sure how this is 
dealt with, and others might have some insights--there
  have been a crap-tonne of people who have used GR for TX, and often 
in "bursty" mode--like sending CW on HF, for example.
  One technique that likely works OK is "zero stuffing".  You send a 
constant stream of 0s in "idle" state, and when a PDU comes

  along it interrupts the otherwise-boring stream of 0s.

Re: burst mode for hackrf one

[Marcus D. Leech]

On 05/11/2022 10:39, Marcus Müller wrote:

Hi Roland,

On 05.11.22 14:00, Roland Schwarz wrote:
Unfortunately it seem I put the cart before the horse by having 
submitted a bug request about something I expected to work but now 
find needs more thought. 


Ha! "I, as a user, am in a reasonable expectation that something 
should work, now I figure it doesn't" might also indicate that some 
things might be in need of better documentation!



I hope this mailing list is the right place for discussion.


So far it's been a fantastic place :)

HackRF One is a device designed for half duplex operations, this is 
why I believe it is safe to assume it will be able to do burst 
transmissions on a hardware level.


There's a TX amp/RX amp/bypass switch (U12/U14), controlled by the 
logic, which could indeed be used for rapidly switching off TX.


Unfortunately the gr-soapy driver, which implements burst 
transmission which will work with UHD (at least I have been told so), 
don't work with the SoapyHackRF driver to do burst mode.


I guess what that means is that when the Soapy sink is in tagged 
bursts mode (you set a length tag), it will set the the 
SOAPY_SDR_END_BURST flag at the right point after a length tag, before 
sending the samples and flags off to the underlying device driver.


UHD knows how to deal with that; there's a mechanism to transport that 
"OK, and after that last sample of this sample packet, you stop 
transmitting" info from PC to do device.


So far I have not found a description or even mentioning of burst 
mode in the soapy driver model documents. Since I was told the 
gr-soapy driver will work with UHD I was looking for a SoapyUHD or 
the like, but there is none.


Dunno where you look, but at the place where JBlum keeps his SoapySDR, 
he also keeps his SoapyUHD:


https://github.com/pothosware/SoapyUHD



I found
Soapy BladeRF Sink
Soapy Custom Sink
Soapy HackRF Sink
Soapy LimeSDR Sink
Soapy PLUTO Sink

however not Soapy UHD Sink. What am I misunderstaning here?


These sinks are just "convenience sinks". SoapySDR is a plugin 
architecture: there's just actually one block, the Soapy sink, and it 
doesn't know which hardware you have, or how to talk to that – but you 
can install plugins for SoapySDR that actually know hardware, and then 
you can stream to that hardware.


These inidividual sinks just "pre-fill" all the configuration so that 
this type of device is used, and that the device-specific settings are 
done.


Has anyone already considered burst mode or has experience with any 
of BladeRF, LimeSDR or PLUTO drivers?


No experience on my side with TX bursting.
But, source code tells me the SoapySDR driver for HackRF does support 
handing down the "end of stream" information to the device:


https://github.com/pothosware/SoapyHackRF/blob/4e40fa19fa3b64f335d48ce112859acbaecee6c4/HackRF_Streaming.cpp#L386 



So, should work the same as when using a USRP instead of a HackRF.

Best regards,
Marcus

I will also point out that it's naive to assume that all SDR hardware 
supports the same set of features, or even that those

  features are implemented in the same way.

Once you move beyond the basic "stream some samples in either direction" 
usage model, each SDR can be fairly

  different in terms of feature sets.

USRPs have historically offered the richest feature set in order to 
support "bursts" and precisely-timed transmission, etc.
  Many of the other SDRs are catching up to this, and some will never 
have anything beyond the basic streaming

  model.

Now *some* of this can kind of sort of be "faked" in the drivers. But 
things like hardware-precise burst timing?  Nope.
  That requires hardware support, and unless the target hardware was 
"born" with that hardware support, no amount of

  "faking it" with software will help...

Re: GnuRadio within docker container access to ettus/n310 requires host mode network

[Marcus D. Leech]

On 2022-10-19 11:52, Jim Melton wrote:


MR,

Docker creates an abstraction over the physical machine, isolating the 
software inside from the rest of the machine.


What you are describing is the expected behavior of the default Docker 
network interface. When you run in *--network=host* mode, you are 
telling Docker to by-pass it’s networking layer and to share the host 
network as if you were a native application. This is the easiest way 
to get network applications working in Docker, but as you note, there 
are security issues.


Further complicating things, if you are running on Windows or Mac, is 
that your Docker image actually runs in a lightweight Linux VM running 
on your computer, because of host operating system limitations. I have 
no experience with non-native (Linux) Docker, so just know that 
dealing with physical devices is a non-trivial configuration.


Some things (like multicast) are darn near impossible using the Docker 
network. I don’t know how the UHD discovers the SDR. If you don’t run 
*--network=host*, you will to explicitly forward the 
port(s)/protocol(s) used by your radio to your Docker container. Note 
that TCP and UDP require separate forwarding rules as needed.


UHD uses a *broadcast* packet to do discovery, and even in a 
non-VM/docker environment, system security settings

  can prevent the non-privileged user from doing broadcast.


Similarly, access to USB devices requires some careful configuration. 
Again, the host device must be exposed (typically through a volume 
mount) into the container for the container to see it. The link you 
shared shows how the USB device is exposed. Note also that the 
container requires escalated privilege (*--privileged*) for this to work.


What you are observing is less a limitation of GRC and more the normal 
behavior of Docker.


---

*Jim Melton*



*From:*Discuss-gnuradio *On Behalf Of *M Esc
*Sent:* Wednesday, October 19, 2022 06:51
*To:* discuss-gnuradio@gnu.org
*Subject:* [EXTERNAL] GnuRadio within docker container access to 
ettus/n310 requires host mode network


(similar cross post issued to uhd/usrp stack exchange)

I have a GNURadio/GNURadio Companion 3.10 on an Ubuntu 20.0.4 docker 
image, where the image is also loaded up with the 4.10 UHD N310 
libraries and osmocom libraries (and some Xterm stuff).  I'm running 
the container of the image on an Ubuntu 20.0.4 host.


I can connect my N310 (also running 4.10 UHD libs) to the host and 
ping the N310.


I can fire up the docker image as a container and ping the N310 from 
within the container.


When I run "uhd_find_devices" within the container, the command 
reports No UHD Devices found.


When I run GNR companion within the container and set up a USRP/UHD as 
a sink with a simple sine wave source, and try to run the blocks, it 
will fail.


However, if I run the container in the docker network=host mode, I can 
successfully run uhd_find_devices and see the N310's info and can 
successfully run the GNR companion with a simple USRP/UHD sink.


I had a similar experience running a nooelec USB SDR and a pluto USB 
SDR  on the same host, i.e. when attaching the USB radios and then 
running the container in network=host mode, I could run my GNR 
Companion blocks successfully, but only when in network=host mode.


So it would *appear* that the network=host mode is required to 
successfully run GNR (either headless or with GNR companion) is required.


I also set up and ran the sample non-GNR/headless container created 
by: https://hub.docker.com/r/openverso/ettus-uhd 
 and found that I also 
had to add a network=host parameter to the commands listed on that 
page before I could successfully run a uhd_find_devices against my N310.


I'd prefer not to use host network mode for a number of reasons, so 
wondered if anyone else has experienced this apparent limitation 
and/or how they solved it.


By the way, our group considered trying to use a macvlan network 
rather than the host network mode, and that might help the N310 access 
problem, but we don't think that it will solve the same problem that 
we saw with the USB devices (nooelec/pluto).


Bottom line question: has anyone else run into the limitation of 
running gnuradio source/sink to an external SDR from within a docker 
container and being forced to use network=host mode?


Thanks

MR

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