[USRP-users] Re: X310 Buffers - 200Msps

[Rob Kossler via USRP-users]

Hi,
regarding FPGA Rx buffer, I am wondering if you can use the DRAM as a
buffer (e.g., host_tx => dram => duc => radio_tx).  As far as I remember,
you can't use the DRAM as a FIFO if you are running 2 channels both at 200
MS/s. The DRAM FIFO bandwidth is insufficient.  But, if your data rate is
less or you only have 1 Tx channel, this may be an option.  I'm not
positive it will solve the underrun but the DRAM FIFO is 1GB deep. This
could be an alternative to using DPDK.
Rob

On Mon, Jul 22, 2024 at 9:31 AM  wrote:

> Hi,
>
> Thanks for the answer in 2).
>
> What about 1) *FPGA Rx Buffer Size:*
>
>-
>
>What is the FPGA Rx buffer size on the X310?
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Recording and playing back RF Activity

[Rob Kossler via USRP-users]

On Tue, May 21, 2024 at 9:34 PM Marcus D. Leech  wrote:
>
> On 21/05/2024 21:05, Hamid Niknami wrote:
>
> Thank you for your reply. REgarding the write speed, I assume that fast SD;s 
> should be able to easily do that:
>
> The NVMe Gen4 x4 interface delivers extreme performance of up to 7,500MB/s 
> seq. read and 6,850MB/s seq. write speeds.
>
> Well, of course, fast disk-drives are necessarily connected to a computer, 
> with the attendant operating-system and
>   CPU bottlenecks.  It's not like the SDR just directly talks to you disk 
> drives with no intervening "system stuff".
>
>
> By synchronization, I mean that all three SDRs start sampling at the same 
> time (with less than 1us difference).
>
> That should be doable.
>
>
> The questions that I have are as below:
> Q1) Considering the fact that I will have a minimum of three SDRs, can one 
> instance of the GNU Radio running on my PC handle three or more SDRs?
>
> Keeping in mind *performance* considerations, that shouldn't be an issue.   
> Gnu Radio places each block in its own thread,
>   and for quirky reasons each of your B2xx blocks will need to be separate.
>
>
> Q2) Is there any ready to use GNU Radio Flow graph for such a scheme to work?
>
> There may be.  You could check cgran.org, or ask on the discuss-gnuradio 
> mailing list.  But, really, the set
>   "useful and interesting things one might do at the intersection of radio, 
> DSP, and computers" is large-to-infinite.
>   So expecting something "out there" that does exactly the thing you want to 
> do is, I would say, naive.
>
>
> Q3) Can you suggest any other low cost approach for recording and playing 
> back 100MHz bandwidth at 2.4GHz?
>
> Not immediately.  But I've been an SDR guy since 2004, and a USRP guy since 
> shortly after that.  So, that's kind of
>   where my head-space is at.

Hi Hamid,
I will just add a few comments.
1) If you want 100 MHz bandwidth, I would highly recommend getting a
model that can handle that bandwidth (such as X300, X310, etc).
Although this device is more expensive than 3 B200 devices, it will be
much easier and provide a fully coherent 100 MHz signal.
2) if you want to record to the PC, I would recommend recording to a
RAM-drive (ramfs) if possible. This, of course, depends on whether
your PC has enough RAM to hold your required number of samples. If you
have enough RAM, you will have less problems (such as overflow,
out-of-sequence packets) if you record to a RAM-based file and then
transfer it to your SSD later.
3) if your sample depth requirement is even shorter, it is possible
that the onboard device RAM could store your recording (unless you
want it saved for later use).  The RFNoC Replay block can record the
incoming Rx signal (up to 1GB or 250MS on the X3xx, I think) which you
could later play out from device RAM to the Tx path. But, this may not
be as easy from gnuradio (i'm not really sure) so it might require a
custom program (python or c++) using the UHD API.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Sharing one UHD device across multiple hosts

[Rob Kossler via USRP-users]

On Sun, May 5, 2024 at 4:47 PM Marcus D. Leech  wrote:
>
> On 05/05/2024 16:00, Marcus Müller wrote:
> > That alternate streaming target functionality re-emerged in later UHD
> > versions for RFNoC-supported devices.
> Is there an example of this somewhere?  I only vaguely remember seeing
> this...

https://files.ettus.com/manual/page_stream.html#stream_remote
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Freq synchronization between two X310s

[Rob Kossler via USRP-users]

Hongwei,
In addition to the PLL that tracks the external 10MHz ref to produce the
internal 10 MHz ref, there are the four PLLs that track the internal 10 MHz
ref to produce the four LO signals (2Tx/2Rx) as you mentioned.  But, the
phase variation from the LO PLLs is much less - I don't really know
the reason for this. This is why you see less noisy results for the cases
where the transmit and receive channels are on one device.

However, even in the one device case, if you compare the phase stability of
a system with "shared LO" such as can be implemented with X310/TwinRx,
N310, or N321 systems, you will see that the relative phase is
significantly less noisy on these devices as compared to the X310/UBX
one-device results ("stable" results) in your case.
Rob

On Thu, May 2, 2024 at 4:01 AM zhou  wrote:

> Thanks, Rob and Marcus.
>
> A single tone is repeatedly transmitted to make a continuous stream out of
> the Tx antenna. It is periodically sampled in Rx; the interval is about 1s.
> The sample time is aligned with the beginning of the transmitted signal to
> make sure we sample at the same time across antennas. We calculate the
> angle of the first complex sample of capture to evaluate the signal phase.
>
> I agree with you that there can be some phase wobble between the 10M ref
> signals applied to PLLs in two devices because of temperature or other
> random factors, however, inside a USRP, there are four independent PLLs for
> 2 Tx and 2 Rx. The 10M ref signals to them should also be wobbling. But my
> measurements show that within the same USRP, phase is pretty stable between
> Tx and Rx. Any explanation on this?
>
> Kind regards.
> Hongwei
>
>
> On Wednesday, 1 May 2024 at 20:34:15 BST, Marcus D Leech <
> patchvonbr...@gmail.com> wrote:
>
>
> It’s also why you can’t get tight instantaneous phase alignment between
> two GPSDO devices even when on the same antenna.
>
> Sent from my iPhone
>
> On May 1, 2024, at 2:12 PM, Rob Kossler  wrote:
>
> 
> The 10 MHz ref supplied to each X310 device is used in a PLL in each
> device to obtain the 10MHz ref used for that device (and for disciplining
> the various LOs on the device). Thus, there is a relative phase "wobble"
> between the 10MHz ref signals used on each device as each PLL continuously
> adjusts to maintain disciplined output.  Over time, this averages out to
> zero. But, instantaneously, it is not. So, my question is: how
> instantaneous is your phase measurement?  If you instead calculate a phase
> averaged over numerous samples, can you get a consistent result? From your
> plot, it looks like this is true.
> Rob
>
> On Wed, May 1, 2024 at 11:04 AM zhou via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
>
> On Wednesday, 1 May 2024 at 15:15:12 BST, Marcus D. Leech <
> patchvonbr...@gmail.com> wrote:
>
>
> On 01/05/2024 10:11, zhou via USRP-users wrote:
>
> Hi Marcus,
>
> Thanks for your response.
>
> "Are you setting up clocking identically for both USRPs?   That is setting
> the reference clock to "external" and the 1PPS source to "external" on both
> devices?   Are you using a single multi_usrp object for all RX channels?"
>
> Yes, I use multi_usrp multi_usrp::make(
> 'addr0=192.168.12.2,second_addr0=192.168.13.2,addr1=192.168.14.2,second_addr1=192.168.15.2,master_clock_rate=184.32e6'
> )
>
> "external" set for both ref and pps:
> usrp->set_clock_source("external")
> usrp->set_time_source("external")
> I think this should automatically set both devices.
>
> "What type of daughtercards are in your X310?"
> UBX
>
> Kind regards.
>
> And, to clarify, this is an Octoclock-G, and not a plain Octoclock ?
>
> It is OctoClock GPSDO, and Internal is used.
>
>
>
>
> On Wednesday, 1 May 2024 at 14:19:44 BST, Marcus D. Leech
>   wrote:
>
>
> On 01/05/2024 08:25, zhou via USRP-users wrote:
>
> Hi All,
>
> I am trying to use 4Rx and 4Tx antennas from two X310 USRPs. I hope the
> received signals have stable phase relationship but they don't seem to be.
> I am wondering why and how to fix it.
>
> I measured the phase using the connection as below:
> [image: Inline image]
> cos(t)+i*sin(t) signal is split into and received on four Rx antennas. Two
> X310s are connected to the same OctoClock for 10MHz Ref and PPS. Tx and Rx
> commands are all timed. The measurement results are as below:
>
>
> The Tx signal is continuous during test. I measured phase every second for
> 20 sec. In the 2nd USRP, the phases are stable on both antennas while it is
> not in the 1st. If I change the Tx signal to the 1st USRP, then the results
> swap - phases become stable in the 1st USRP and unstable in the 2nd.
>
> My first though was that there might be small CFO between USRPs even
> though both are connected to the OctoClock, but CFO should have caused
> linear change. Here, the phase offset is not linear and kind of random
> within 20 second measurement.
>
> What can be the reason? Any suggestion will be appreciated.
>
> Kind regards,
> H.
> Are you setting up clocking 

[USRP-users] Re: Freq synchronization between

[Rob Kossler via USRP-users]

The 10 MHz ref supplied to each X310 device is used in a PLL in each device
to obtain the 10MHz ref used for that device (and for disciplining the
various LOs on the device). Thus, there is a relative phase "wobble"
between the 10MHz ref signals used on each device as each PLL continuously
adjusts to maintain disciplined output.  Over time, this averages out to
zero. But, instantaneously, it is not. So, my question is: how
instantaneous is your phase measurement?  If you instead calculate a phase
averaged over numerous samples, can you get a consistent result? From your
plot, it looks like this is true.
Rob

On Wed, May 1, 2024 at 11:04 AM zhou via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> On Wednesday, 1 May 2024 at 15:15:12 BST, Marcus D. Leech <
> patchvonbr...@gmail.com> wrote:
>
>
> On 01/05/2024 10:11, zhou via USRP-users wrote:
>
> Hi Marcus,
>
> Thanks for your response.
>
> "Are you setting up clocking identically for both USRPs?   That is setting
> the reference clock to "external" and the 1PPS source to "external" on both
> devices?   Are you using a single multi_usrp object for all RX channels?"
>
> Yes, I use multi_usrp multi_usrp::make(
> 'addr0=192.168.12.2,second_addr0=192.168.13.2,addr1=192.168.14.2,second_addr1=192.168.15.2,master_clock_rate=184.32e6'
> )
>
> "external" set for both ref and pps:
> usrp->set_clock_source("external")
> usrp->set_time_source("external")
> I think this should automatically set both devices.
>
> "What type of daughtercards are in your X310?"
> UBX
>
> Kind regards.
>
> And, to clarify, this is an Octoclock-G, and not a plain Octoclock ?
>
> It is OctoClock GPSDO, and Internal is used.
>
>
>
>
> On Wednesday, 1 May 2024 at 14:19:44 BST, Marcus D. Leech
>   wrote:
>
>
> On 01/05/2024 08:25, zhou via USRP-users wrote:
>
> Hi All,
>
> I am trying to use 4Rx and 4Tx antennas from two X310 USRPs. I hope the
> received signals have stable phase relationship but they don't seem to be.
> I am wondering why and how to fix it.
>
> I measured the phase using the connection as below:
> [image: Inline image]
> cos(t)+i*sin(t) signal is split into and received on four Rx antennas. Two
> X310s are connected to the same OctoClock for 10MHz Ref and PPS. Tx and Rx
> commands are all timed. The measurement results are as below:
>
>
> The Tx signal is continuous during test. I measured phase every second for
> 20 sec. In the 2nd USRP, the phases are stable on both antennas while it is
> not in the 1st. If I change the Tx signal to the 1st USRP, then the results
> swap - phases become stable in the 1st USRP and unstable in the 2nd.
>
> My first though was that there might be small CFO between USRPs even
> though both are connected to the OctoClock, but CFO should have caused
> linear change. Here, the phase offset is not linear and kind of random
> within 20 second measurement.
>
> What can be the reason? Any suggestion will be appreciated.
>
> Kind regards,
> H.
> Are you setting up clocking identically for both USRPs?   That is setting
> the reference clock to "external" and the 1PPS source to "external" on both
> devices?   Are you using a single multi_usrp object for all RX channels?
>
> What type of daughtercards are in your X310?
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Unbalanced power among antennas in X410

[Rob Kossler via USRP-users]

The plot is titled "Real". If this is simply the real component of a
complex signal, then it is not possible to know the magnitude. If there is
a phase shift, then the power may have shifted into the "Imag" component.
Instead, plot the abs if you are interested in only power differences among
channels.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Extending duration of high-rate captures with the X410

[Rob Kossler via USRP-users]

I think I am mistaken. If you are only streaming a single channel, the
--multi_streamer option will likely not change a thing. I was assuming you
had multiple channels.
Rob

On Tue, Mar 12, 2024 at 5:40 PM Rob Kossler  wrote:

> Your mount command with tmpfs looks correct. Here is what mine is in my
> /etc/fstab file (with 264GB avail RAM)
> tmpfs  /media/ramfolder/  tmpfs  rw,nosuid,nodev,size=200G   0  0
>
> You might want to try rx_samples_to_file with the --multi_streamer option.
> I expect you will get better performance.  Also, you can take your RAM FS
> size higher from 8G to probably 60G if you want to try bigger recording
> depths.
> Rob
>
> On Tue, Mar 12, 2024 at 5:13 PM Marcus D. Leech 
> wrote:
>
>> On 12/03/2024 16:11, zackk...@utexas.edu wrote:
>>
>> Hey Rob and Marcus,
>>
>> Thanks for the responses! I have a basic understanding of linux, but am
>> not very experienced. I tried the following to create the RAM filesystem:
>>
>> sudo mount -t tmpfs -o size=8G tmpfs /mnt/tmpfs/
>>
>> sudo mount -t ramfs -o size=8G ramfs /mnt/ramfs/
>>
>>
>> And ran the rx_samples_to_file, once with --file /mnt/tmpfs/test.bin, and
>> once with --file /mnt/ramfs/test.bin, both times still getting o’s for
>> overruns.
>>
>> By my calculations, at ~500 M complex samples per second, each complex
>> sample 4 bytes (defaulting to short for I and Q), that means just 1 second
>> of capturing equates to 2 GB of data. My system has 64 GB of RAM. Am I
>> creating the RAM filesystem correctly? Am I using it correctly?
>>
>>
>>
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>> Assuming that you did a "sudo mkdir of /mnt/ramfs" beforehand,  this
>> should work.
>>
>>
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Extending duration of high-rate captures with the X410

[Rob Kossler via USRP-users]

Your mount command with tmpfs looks correct. Here is what mine is in my
/etc/fstab file (with 264GB avail RAM)
tmpfs  /media/ramfolder/  tmpfs  rw,nosuid,nodev,size=200G   0  0

You might want to try rx_samples_to_file with the --multi_streamer option.
I expect you will get better performance.  Also, you can take your RAM FS
size higher from 8G to probably 60G if you want to try bigger recording
depths.
Rob

On Tue, Mar 12, 2024 at 5:13 PM Marcus D. Leech 
wrote:

> On 12/03/2024 16:11, zackk...@utexas.edu wrote:
>
> Hey Rob and Marcus,
>
> Thanks for the responses! I have a basic understanding of linux, but am
> not very experienced. I tried the following to create the RAM filesystem:
>
> sudo mount -t tmpfs -o size=8G tmpfs /mnt/tmpfs/
>
> sudo mount -t ramfs -o size=8G ramfs /mnt/ramfs/
>
>
> And ran the rx_samples_to_file, once with --file /mnt/tmpfs/test.bin, and
> once with --file /mnt/ramfs/test.bin, both times still getting o’s for
> overruns.
>
> By my calculations, at ~500 M complex samples per second, each complex
> sample 4 bytes (defaulting to short for I and Q), that means just 1 second
> of capturing equates to 2 GB of data. My system has 64 GB of RAM. Am I
> creating the RAM filesystem correctly? Am I using it correctly?
>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> Assuming that you did a "sudo mkdir of /mnt/ramfs" beforehand,  this
> should work.
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Extending duration of high-rate captures with the X410

[Rob Kossler via USRP-users]

Hi Zack,
I would not count on equal performance between saving to a RAM file system
versus allocating your own buffers, but I don't know the reason. I think it
is worth a try to configure as large a RAM file system as you can and run
rx_samples_to_file (which will not create large RAM buffers).  Plus, this
is a pretty easy test to run.

I can tell you that long ago I got pretty good performance by writing to
files in RAM (up to a predetermined fixed length) such that after a fixed
number of samples, I closed those files and opened new ones and continued
writing to the new ones.  As a separate process, the closed files were
moved to persistent storage thus free-ing up RAM.  This sounds a lot like
your circular buffer in RAM concept but I was never able to get the
circular buffer architecture working as well.
Rob

On Tue, Mar 12, 2024 at 1:00 PM  wrote:

> Hey Rob,
>
> Saving to dev/null worked just fine, and didn’t even output the “Disk
> write test indicates that an overflow is likely to occur” warning.
>
> In terms of saving to RAM, isn’t this essentially what my custom script
> does? I reserve all my buffers (which increases my RAM usage by a lot) and
> have a separate thread write from these to the filesystem.
>
> Would anything be different if I used a ramdisk? I can try it out.
>
> As for DPDK, I tried in the past to get it working but keep running into
> issues. I will post the output below, but it may warrant a separate post.
>
> When running:
>
> ./rx_samples_to_file --args 
> "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19,use_dpdk=1"
>  --file /dev/null --duration 10 --rate 491.52e6 --freq 1575.42e6
>
> I get:
>
> Creating the usrp device with: 
> addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19,use_dpdk=1...
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
> UHD_4.6.0.HEAD-0-g50fa3baa
>
> EAL: Detected 24 lcore(s)
>
> EAL: Detected 2 NUMA nodes
>
> EAL: Multi-process socket /run/user/1001/dpdk/rte/mp_socket
>
> EAL: Selected IOVA mode 'VA'
>
> EAL: No available hugepages reported in hugepages-1048576kB
>
> EAL: Probing VFIO support...
>
> EAL: VFIO support initialized
>
> EAL: get_seg_fd(): open '/dev/hugepages/rtemap_0' failed: Permission denied
>
> EAL: Couldn't get fd on hugepage file
>
> EAL: get_seg_fd(): open '/dev/hugepages/rtemap_32768' failed: Permission 
> denied
>
> EAL: Couldn't get fd on hugepage file
>
> EAL: error allocating rte services array
>
> EAL: FATAL: rte_service_init() failed
>
> EAL: rte_service_init() failed
>
> [ERROR] [DPDK] Error with EAL initialization
>
> [ERROR] [UHD] Device discovery error: RuntimeError: Error with EAL 
> initialization
>
> EAL: FATAL: already called initialization.
>
> EAL: already called initialization.
>
> [ERROR] [DPDK] Error with EAL initialization
>
> [ERROR] [X300] X300 Network discovery error RuntimeError: Error with EAL 
> initialization
>
> Error: LookupError: KeyError: No devices found for ->
>
> Device Address:
>
> addr: 192.168.10.2
>
> second_addr: 192.168.20.2
>
> mgmt_addr: 192.168.1.19
>
> use_dpdk: 1
>
>
> When I run the same command as the root user, I get:
>
> Creating the usrp device with: 
> addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19,use_dpdk=1...
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
> UHD_4.6.0.HEAD-0-g50fa3baa
>
> EAL: Detected 24 lcore(s)
>
> EAL: Detected 2 NUMA nodes
>
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
>
> EAL: Selected IOVA mode 'VA'
>
> EAL: No available hugepages reported in hugepages-1048576kB
>
> EAL: Probing VFIO support...
>
> EAL: VFIO support initialized
>
> EAL: PCI device :31:00.0 on NUMA socket 0
>
> EAL:   probe driver: 15b3:101d net_mlx5
>
> EAL: PCI device :31:00.1 on NUMA socket 0
>
> EAL:   probe driver: 15b3:101d net_mlx5
>
> [ERROR] [DPDK] Could not find route to destination address 192.168.10.2
>
> [ERROR] [X300] X300 Network discovery error RuntimeError: DPDK: Could not 
> find route to destination address 192.168.10.2
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
> mgmt_addr=192.168.1.19,type=x4xx,product=x410,serial=326E872,name=ni-x4xx-326E872,fpga=CG_400,claimed=False,addr=192.168.10.2,second_addr=192.168.20.2,use_dpdk=1
>
> [WARNING] [MPM.RPCServer] A timeout event occured!
>
> [INFO] [MPM.PeriphManager] init() called with device args 
> `fpga=CG_400,mgmt_addr=192.168.1.19,name=ni-x4xx-326E872,product=x410,second_addr=192.168.20.2,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.
>
> [ERROR] [DPDK] Could not find route to destination address 192.168.10.2
>
> [WARNING] [MPMD::XPORT::UDP] Error during MTU discovery on address 
> 192.168.10.2: RuntimeError: DPDK: Could not find route to destination address 
> 192.168.10.2
>
> [ERROR] [RFNOC::MGMT] EnvironmentError: IOError: Timed out getting recv buff 
> for management transaction
>
> [ERROR] [RFNOC::GRAPH] IO Error during GSM 

[USRP-users] Re: Extending duration of high-rate captures with the X410

[Rob Kossler via USRP-users]

So, if benchmark_rate can run successfully, maybe try rx_samples_to_file
with saving the dev/null or with saving to files in a RAM file system.
This will limit your capture depth to the size of the RAM. If this works,
then it is a challenging issue to save to permanent storage. Perhaps DPDK
will work better at the expense of more complex configuration.

On Tue, Mar 12, 2024 at 11:58 AM  wrote:

> Hello Rob!
>
> I should have mentioned this in my original post but benchmark rate works
> well for me. Specifically, when I run:
>
> ./benchmark_rate --rx_rate 491.52e6 --args 
> "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19" 
> --duration 600
>
> I get
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
> UHD_4.6.0.HEAD-0-g50fa3baa
>
> [00:00:00.000322] Creating the usrp device with: 
> addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19...
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
> mgmt_addr=192.168.1.19,type=x4xx,product=x410,serial=326E872,name=ni-x4xx-326E872,fpga=CG_400,claimed=False,addr=192.168.10.2,second_addr=192.168.20.2
>
> [INFO] [MPM.PeriphManager] init() called with device args 
> `fpga=CG_400,mgmt_addr=192.168.1.19,name=ni-x4xx-326E872,product=x410,second_addr=192.168.20.2,clock_source=internal,time_source=internal,initializing=True'.
>
> Using Device: Single USRP:
>
>   Device: X400-Series Device
>
>   Mboard 0: x410
>
>   RX Channel: 0
>
> RX DSP: n/a
>
> RX Dboard: A
>
> RX Subdev: 0
>
>   RX Channel: 1
>
> RX DSP: n/a
>
> RX Dboard: A
>
> RX Subdev: 1
>
>   RX Channel: 2
>
> RX DSP: n/a
>
> RX Dboard: B
>
> RX Subdev: 0
>
>   RX Channel: 3
>
> RX DSP: n/a
>
> RX Dboard: B
>
> RX Subdev: 1
>
>   TX Channel: 0
>
> TX DSP: n/a
>
> TX Dboard: A
>
> TX Subdev: 0
>
>   TX Channel: 1
>
> TX DSP: n/a
>
> TX Dboard: A
>
> TX Subdev: 1
>
>   TX Channel: 2
>
> TX DSP: n/a
>
> TX Dboard: B
>
> TX Subdev: 0
>
>   TX Channel: 3
>
> TX DSP: n/a
>
> TX Dboard: B
>
> TX Subdev: 1
>
> [00:00:03.511001021] Setting device timestamp to 0...
>
> [00:00:03.512894034] Testing receive rate 491.52 Msps on 1 channels
>
> [00:10:03.513454979] Benchmark complete.
>
> Benchmark rate summary:
>
>   Num received samples: 294911842520
>
>   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!
>
> When I use the example that saves to file:
>
> ./rx_samples_to_file --args
> "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19" --file
> [path] --duration 10 --rate 491.52e6 --freq 1575.42e6
>
>
> I get :
>
> Creating the usrp device with: 
> addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19...
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
> UHD_4.6.0.HEAD-0-g50fa3baa
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
> mgmt_addr=192.168.1.19,type=x4xx,product=x410,serial=326E872,name=ni-x4xx-326E872,fpga=CG_400,claimed=False,addr=192.168.10.2,second_addr=192.168.20.2
>
> [INFO] [MPM.PeriphManager] init() called with device args 
> `fpga=CG_400,mgmt_addr=192.168.1.19,name=ni-x4xx-326E872,product=x410,second_addr=192.168.20.2,clock_source=internal,time_source=internal,initializing=True'.
>
> Using Device: Single USRP:
>
>   Device: X400-Series Device
>
>   Mboard 0: x410
>
>   RX Channel: 0
>
> RX DSP: n/a
>
> RX Dboard: A
>
> RX Subdev: 0
>
>   RX Channel: 1
>
> RX DSP: n/a
>
> RX Dboard: A
>
> RX Subdev: 1
>
>   RX Channel: 2
>
> RX DSP: n/a
>
> RX Dboard: B
>
> RX Subdev: 0
>
>   RX Channel: 3
>
> RX DSP: n/a
>
> RX Dboard: B
>
> RX Subdev: 1
>
>   TX Channel: 0
>
> TX DSP: n/a
>
> TX Dboard: A
>
> TX Subdev: 0
>
>   TX Channel: 1
>
> TX DSP: n/a
>
> TX Dboard: A
>
> TX Subdev: 1
>
>   TX Channel: 2
>
> TX DSP: n/a
>
> TX Dboard: B
>
> TX Subdev: 0
>
>   TX Channel: 3
>
> TX DSP: n/a
>
> TX Dboard: B
>
> TX Subdev: 1
>
> Setting RX Rate: 491.52 Msps...
>
> Actual RX Rate: 491.52 Msps...
>
> Setting RX Freq: 1575.42 MHz...
>
> Setting RX LO Offset: 0.00 MHz...
>
> [WARNING] [MULTI_USRP] No DSP capabilities detected. Combining offset into 
> target frequency of 1575.420MHz
>
> Actual RX Freq: 1575.42 MHz...
>
> Locking LO on channel 0
>
> Waiting for "lo_locked": ++ locked.
>
> Press Ctrl + C to stop streaming...
>
>   Disk write test indicates that an overflow is likely to occur.
>
>   Your write medium must sustain a rate of 1966.080MB/s,
>
>   but write test returned write speed of 184.000MB/s.
>
>   The disk write rate is also affected by system load
>
>   and OS/disk caching capacity.
>
> OGot 

[USRP-users] Re: Extending duration of high-rate captures with the X410

[Rob Kossler via USRP-users]

Hi Zack,
I don't know the answers to your issues, but I'm wondering if you can just
use benchmark_rate rather than your custom code to evaluate performance. If
benchmark_rate can't run at the rate you want, it is unlikely that your
custom code will succeed.
Rob

On Mon, Mar 11, 2024 at 2:35 PM  wrote:

> Hello!
>
> I am having trouble using a USRP X410 to capture some high-rate data. I
> would appreciate any insight or help. Below is a diagram of how our x410 is
> connected to our host device.
>
> *-* *-*
>
> |   | NIC QSFP Port 0 | | QSFP28 Port 1   |   |
>
> |   |ens1f0np0<>---<>   sfp1  |   |
>
> |   |  192.168.20.1   | |  192.168.20.2   |   |
>
> |   |-| |-|   |
>
> | H | NIC QSFP Port 1 | | QSFP28 Port 0   | X |
>
> | O |ens1f1np1<>---<>   sfp0  | 4 |
>
> | S |  192.168.10.1   | |  192.168.10.2   | 1 |
>
> | T |-|  *---*  |-| 0 |
>
> |   | Ethernet Port 1 |  |Router |  |  Ethernet Port  |   |
>
> |   | eno8403 <>-|192.168.1.1|-<>  eth0   |   |
>
> |   |  192.168.1.20   |  |   |  |  192.168.1.19   |   |
>
> *-*  *---*  *-*
>
> When I run $ uhd_find_devices
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
> UHD_4.6.0.HEAD-0-g50fa3baa
>
> --
>
> -- UHD Device 0
>
> --
>
> Device Address:
>
> serial: [serial number]
>
> addr: 192.168.20.2
>
> claimed: False
>
> fpga: CG_400
>
> mgmt_addr: 192.168.1.19
>
> mgmt_addr: 192.168.10.2
>
> mgmt_addr: 192.168.20.2
>
> name: [name]
>
> product: x410
>
> type: x4xx
>
> I am using two images for the FPGA, each of which has different
> capabilities:
>
> - UC_200, which on the wiki lists Port 0 as "unused" and can achieve up to
> 250 Msps per channel.
>
> - CG_400, which lists both ports on the wiki as "100 GbE" and can achieve
> up to 500 Msps per channel.
>
> I am using UHD's C++ API to instruct the x410. My capture process tries to
> call "recv" as soon as possible without waiting to write the previous
> buffer to a file. The psudocode is as follows:
>
> - Initialize "circular" buffer of arrays. Each array is "spb" samples
> long, and there are N such buffers.
>
> - Start a "writing" thread that writes data from a queue to a file.
>
> - Set the number of samples I need (nsamps_requested), set the current
> number of samples to 0 (nsamps),
>
> - set the current buffer index to 0 (buff_idx)
>
> - set up rx_streamer to start 0.1 seconds in the future and issue
> STREAM_MODE_START_CONTINUOUS command.
>
> While (nsamps <= nsamps_requested || not_error)
>
> -Get a pointer to the buffer at buff_idx
>
> -num_rx_samps <- recv(buffer...)
>
> -check metadata returned object
>
> -add the buffer to the queue, increment the buffer index
>
> - stop streaming
>
> When I use the process above, I can get very long captures using the
> UC_200 image, with 250 Msps, and by parsing the args
> "addr=192.168.20.2,mgmt_addr=192.168.1.19" when creating the multiusrp
> pointer.
>
> When I switch to the CG_400 image, I can barely record a few seconds worth
> of data. I parse the args
> "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19". I
> changed the logger level to get a better idea of what might be going on,
> below are some outputs for spb at 5000:
>
> [DEBUG] [RFNOC::MGMT] Established a route from EPID=4 (SW) to EPID=3
>
> [DEBUG] [RFNOC::MGMT] Throttling stream endpoint to 100% (0x0)
>
> [DEBUG] [RFNOC::MGMT] Initiated RX stream setup for EPID=3
>
> [DEBUG] [RFNOC::MGMT] Finished RX stream setup for EPID=3
>
> [DEBUG] [0/Radio#0] spp value 2032 exceeds MTU of 8016! Coercing to 1988
>
> 
>
> [DEBUG] [RxStreamer#0] Received overrun message on port 0
>
> After the last logger message, I catc this in my "check metadata returned
> object" step and stop the loop.
>
> When this happens, I sometimes get 0 samples back, and sometimes get less
> than the samples per buffer I feed the recv command. I also found that
> while waiting for the issued command to take effect, instead of adding
> empty buffers to my queue, I check for ERROR_CODE_TIMEOUT and just continue
> the while loop.
>
> I would imagine if I can handle half the rate at 250 Msps for minutes of
> continuous capture, going to 500 Msps I could get more than a couple
> seconds. Is this because the UC_200 image has 4GiB of DRAM and the CG_400
> doesn't list any on the wiki? Is there something better I can be doing
> about the spb (I tried larger and smaller, with some luck around 5
> spb)? Am I properly configuring the x410 to use both QSFP28 ports for the
> CG_400 image?
>
> Thanks!
>
> Zack
> 

[USRP-users] Re: X310

[Rob Kossler via USRP-users]

The IP address of 192.168.10.2 and the MTU size of 1472 indicate that your
link is a 1Gb link. The max rate this can support is 25MS/s. You will need
to connect at 10Gbe if you want to run at 100MS/s.
Rob

On Wed, Mar 6, 2024 at 2:31 PM White, Joshua J <
jjwh...@riversideresearch.org> wrote:

> The underflows you’re getting mean your host PC isn’t providing samples
> fast enough for the rate the radio is consuming them and it’s underrunning
> the TX buffer. Likely there isn’t enough bandwidth between the host PC and
> the radio to support 100 Msps. There is a pretty good discussion of
> bandwidth and sampling rates here:
>
>
>
> https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates
>
>
>
> Very respectfully,
>
>
>
> *Joshua White*
>
> Precision Timing Systems Engineer
>
> Engineering & Support Solutions Directorate
>
> www.riversideresearch.org
>
> T: 937.986.3153 | F: 937.431.3811
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain proprietary, confidential or
> privileged information or otherwise be protected by law. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please notify the sender and destroy all copies and the
> original message.
>
>
>
> *From:* ygurupra...@umass.edu 
> *Sent:* Wednesday, March 6, 2024 1:56 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [USRP-users] X310
>
>
>
>  *CAUTION:* This email is from outside of Riverside Research. Be careful
> when clicking links or opening attachments unless you know the content is
> safe.
>
> Could some help me if this is working as expected?
>
>
> ./bin/txrx_loopback_to_file --tx-args addr=192.168.10.2 --rx-args
> addr=192.168.10.2 --tx-rate 100e6 --rx-rate 6.5e6 --tx-freq 20e6 --rx-freq
> 18e6
>
> Creating the transmit usrp device with: addr=192.168.10.2...
>
> [INFO] [UHD] linux; GNU C++ version 8.5.0 20210514 (Red Hat 8.5.0-20);
> Boost_106600; UHD_4.2.0.1-0-g321295fb
>
> [INFO] [X300] X300 initialization sequence...
>
> [INFO] [X300] Maximum frame size: 1472 bytes.
>
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 1.101
>
> [INFO] [X300] Radio 1x clock: 200 MHz
>
> [INFO] [0/KeepOneInN#0] Setting default MTU forward policy.
>
> Creating the receive usrp device with: addr=192.168.10.2...
>
> Using TX Device: Single USRP:
>
> Device: X-Series Device
>
> Mboard 0: X310
>
> RX Channel: 0
>
> RX DSP: 0
>
> RX Dboard: A
>
> RX Subdev: BasicRX (0)
>
> RX Channel: 1
>
> RX DSP: 1
>
> RX Dboard: A
>
> RX Subdev: BasicRX (1)
>
> RX Channel: 2
>
> RX DSP: 2
>
> RX Dboard: B
>
> RX Subdev: Unknown (0x) - 0
>
> TX Channel: 0
>
> TX DSP: 0
>
> TX Dboard: A
>
> TX Subdev: BasicTX (0)
>
> TX Channel: 1
>
> TX DSP: 1
>
> TX Dboard: B
>
> TX Subdev: Unknown (0x) - 0
>
> Using RX Device: Single USRP:
>
> Device: X-Series Device
>
> Mboard 0: X310
>
> RX Channel: 0
>
> RX DSP: 0
>
> RX Dboard: A
>
> RX Subdev: BasicRX (0)
>
> RX Channel: 1
>
> RX DSP: 1
>
> RX Dboard: A
>
> RX Subdev: BasicRX (1)
>
> RX Channel: 2
>
> RX DSP: 2
>
> RX Dboard: B
>
> RX Subdev: Unknown (0x) - 0
>
> TX Channel: 0
>
> TX DSP: 0
>
> TX Dboard: A
>
> TX Subdev: BasicTX (0)
>
> TX Channel: 1
>
> TX DSP: 1
>
> TX Dboard: B
>
> TX Subdev: Unknown (0x) - 0
>
> Setting TX Rate: 100.00 Msps...
>
> Actual TX Rate: 100.00 Msps...
>
> Setting RX Rate: 6.50 Msps...
>
> [WARNING] [0/DDC#0] The requested decimation is odd; the user should
> expect passband CIC rolloff.
>
> Select an even decimation to ensure that a halfband filter is enabled.
>
> Decimations factorable by 4 will enable 2 halfbands, those factorable by 8
> will enable 3 halfbands.
>
> decimation = dsp_rate/samp_rate -> 31
>
> [WARNING] [0/DDC#0] The requested decimation is odd; the user should
> expect passband CIC rolloff.
>
> Select an even decimation to ensure that a halfband filter is enabled.
>
> Decimations factorable by 4 will enable 2 halfbands, those factorable by 8
> will enable 3 halfbands.
>
> decimation = dsp_rate/samp_rate -> 31
>
> [WARNING] [MULTI_USRP] Could not set RX rate to 6.500 MHz. Actual rate is
> 6.452 MHz
>
> [WARNING] [0/DDC#0] The requested decimation is odd; the user should
> expect passband CIC rolloff.
>
> Select an even decimation to ensure that a halfband filter is enabled.
>
> Decimations factorable by 4 will enable 2 halfbands, those factorable by 8
> will enable 3 halfbands.
>
> decimation = dsp_rate/samp_rate -> 31
>
> [WARNING] [0/DDC#0] The requested decimation is odd; the user should
> expect passband CIC rolloff.
>
> Select an even decimation to ensure that a halfband filter is enabled.
>
> Decimations factorable by 4 will enable 2 halfbands, those factorable by 8
> will enable 3 halfbands.
>
> decimation = dsp_rate/samp_rate -> 31
>
> [WARNING] [MULTI_USRP] Could not set RX rate to 6.500 MHz. Actual rate is
> 6.452 MHz
>
> [WARNING] [0/DDC#1] The requested decimation is odd; the user should
> expect 

[USRP-users] Re: OFDM signal transmission by x310 presents a peak

[Rob Kossler via USRP-users]

This link

indicates that the antenna ports are to remain unconnected. Since there is
no internal loopback path, I believe that the calibration algorithm
utilizes the "leakage" signal which is apparently strong enough such that
it can be minimized with the appropriate calibration adjustments.
Rob


On Thu, Feb 29, 2024 at 11:16 AM zhou via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Cédric,
>
> It was instructed by Ettus engineer when we started to use USRPs a few
> years ago. This is because there is no internal loopback path in circuit in
> X310. By the way, we are using UBX daughterboard. Maybe this is not
> documented.
>
> Regards,
> Hongwei
>
>
>
> On Thursday, 29 February 2024 at 15:05:37 GMT, Cédric Hannotier via
> USRP-users  wrote:
>
>
> Hi Hongwei,
>
> On 2024-02-26 10:06 +, zhou wrote:
> > For X310 USRPs, you need to loopback connect the antenna ports.
>
> Could you direct me to where you got that info?
> I never encountered it, and I am not able to find it in the Ettus docs.
> Doing proper calibration is important,
> so we should ensure that the Ettus docs give the correct procedure...
>
> Kind regards
>
> --
>
> Cédric Hannotier
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Multiple Streamers

[Rob Kossler via USRP-users]

Hi Zach,
There can definitely be multiple tx streamers (& rx streamers).  Take a
look at the Ettus rx_samples_to_file example which does this with rx
streamers. You are probably doing everything right already.  The
documentation might be just poorly worded such that maybe it should say
that you can only have one streamer per channel.
Rob

On Thu, Feb 22, 2024 at 5:08 PM Rohde, Zach (US 333G) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I have been running tests with multiple TX channels so that each channel
> can run at a different sample rate, using multiple calls to get_tx_stream()
> to generate a unique streamer for each thread. This has been successful
> using the X440 and results in no errors or warnings.
>
>
>
> My question is the documentation
> 
> states: “Note: There can always only be one streamer. When calling
> get_tx_stream() a second time, the first streamer must be destroyed
> beforehand.” Is this true? Why am I not seeing any undefined behavior or
> errors/warnings?
>
>
>
> In the documentation for multi_usrp_rfnoc
> ,
> I noticed a documentation stub that mentioned, “If there is only ever one
> Tx streamer, this will work as expected. For multiple streamers, only the
> last streamer's async messages will make it through.” So, it seems the
> documentation is sort of contradicting one another on whether multiple TX
> streams are allowed.
>
>
>
> Thanks,
>
> Zach
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

[Rob Kossler via USRP-users]

But it should. This is basic functionality that is completely broken. The
commit to fix it is simple.

On Fri, Feb 9, 2024 at 10:06 AM Marcus D. Leech 
wrote:

> On 09/02/2024 09:07, Rob Kossler via USRP-users wrote:
>
> This is fixed in 4.5 and 4.6.  Are you able to switch?
> Rob
>
> I'll add that it's unlikely for the fix to get back-ported to 4.4 at this
> point.
>
>
>
>
> On Fri, Feb 9, 2024 at 5:04 AM  wrote:
>
>> Hi,
>>
>> I am facing the same problem.
>>
>> I am on a Linux machine and hardware is an X300 with a UBX160.
>>
>> When I am above 500 MHz the actual carrier freq becomes about 2000 MHz
>> smaller.
>>
>> I checked it with the uhd example script  tx_waveforms that comes with
>> the uhd install. Below is the output. Note that actual frequency is
>> negative. There is no output at 915 MHz on a spectrum analyzer. Below 500
>> MHz everything is fine.
>>
>> Same happens when using Gnuradio.
>>
>>  Thanks
>>
>> Soren
>>
>>
>> --
>>
>> $ ./tx_waveforms --freq 915e6 --rate 5e6 --gain 0
>>
>> Creating the usrp device with: ...
>> [INFO] [UHD] linux; GNU C++ version 13.1.0; Boost_107400;
>> UHD_4.4.0.0+ds1-4
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Maximum frame size: 1472 bytes.
>> [INFO] [X300] Radio 1x clock: 200 MHz
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X300
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: UBX RX
>> RX Channel: 1
>> RX DSP: 1
>> RX Dboard: B
>> RX Subdev: Unknown (0x) - 0
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: UBX TX
>> TX Channel: 1
>> TX DSP: 1
>> TX Dboard: B
>> TX Subdev: Unknown (0x) - 0
>>
>> Setting TX Rate: 5.00 Msps...
>> Actual TX Rate: 5.00 Msps...
>>
>> Setting TX Freq: 915.00 MHz...
>> Setting TX LO Offset: 0.00 MHz...
>> Actual TX Freq: -1085.02 MHz...
>>
>> Setting TX Gain: 0.00 dB...
>> Actual TX Gain: 0.00 dB...
>>
>> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
>> Setting device timestamp to 0...
>> Checking TX: TXLO: locked ...
>> Press Ctrl + C to stop streaming...
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

[Rob Kossler via USRP-users]

This is fixed in 4.5 and 4.6.  Are you able to switch?
Rob

On Fri, Feb 9, 2024 at 5:04 AM  wrote:

> Hi,
>
> I am facing the same problem.
>
> I am on a Linux machine and hardware is an X300 with a UBX160.
>
> When I am above 500 MHz the actual carrier freq becomes about 2000 MHz
> smaller.
>
> I checked it with the uhd example script  tx_waveforms that comes with the
> uhd install. Below is the output. Note that actual frequency is negative.
> There is no output at 915 MHz on a spectrum analyzer. Below 500 MHz
> everything is fine.
>
> Same happens when using Gnuradio.
>
>  Thanks
>
> Soren
>
>
> --
>
> $ ./tx_waveforms --freq 915e6 --rate 5e6 --gain 0
>
> Creating the usrp device with: ...
> [INFO] [UHD] linux; GNU C++ version 13.1.0; Boost_107400; UHD_4.4.0.0+ds1-4
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X300
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
> RX Channel: 1
> RX DSP: 1
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
> TX Channel: 1
> TX DSP: 1
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
>
> Setting TX Rate: 5.00 Msps...
> Actual TX Rate: 5.00 Msps...
>
> Setting TX Freq: 915.00 MHz...
> Setting TX LO Offset: 0.00 MHz...
> Actual TX Freq: -1085.02 MHz...
>
> Setting TX Gain: 0.00 dB...
> Actual TX Gain: 0.00 dB...
>
> [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
> Setting device timestamp to 0...
> Checking TX: TXLO: locked ...
> Press Ctrl + C to stop streaming...
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Align multi-channel captures with different rx_stremers

[Rob Kossler via USRP-users]

On Tue, Feb 6, 2024 at 5:50 PM  wrote:
>
> It’s an estimated difference using a GPS SDR I have access to, not the 
> timestamps in the metadata.
>
> I just tired choosing different sampling rates, it seems like when I use 
> pairs of sampling rates corresponding to odd divisions of the master clock 
> rate, it works fine. Similarly when I choose even pairs. Choosing a sampling 
> rates corresponding to odd and even though causes a mismatch.

Try checking the timestamps.  Assuming that the metadata timestamps
are different by the measured amount, would that allow you to throw
away samples from one of the streamers in order to align them?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Align multi-channel captures with different rx_stremers

[Rob Kossler via USRP-users]

You mentioned a difference of 732ns. Is this a measured difference or is
this the difference in the timestamps contained in the metadata for the 2
streams?

On Tue, Feb 6, 2024 at 5:23 PM  wrote:

> If I do thing concurrently (same thread, same rx_streamer) would that
> solve the timing issue? For example:
>
> stream_args.channels = { 0, 1};
>
> uhd::rx_streamer::sptr rx_stream = usrp_->get_rx_stream(stream_args);
>
> …
>
> size_t num_rx_samps =
>
> rx_stream->recv(buffs, samps_per_buff_, md, timeout, 
> one_packet);
>
> Where buffs is a collection of receive buffers.
>
> It would become a little awkward with different sampling rates, but would
> this potentially solve the timing issue?
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Getting Dropped packets

[Rob Kossler via USRP-users]

On Wed, Jan 24, 2024 at 2:43 PM Marcus D. Leech  wrote:
>
> On 24/01/2024 13:00, jmalo...@umass.edu wrote:
> >
> > Hello,
> >
> >
> > I currently have an application where I am burst receiving(about 80
> > micro per milli second) with the ettus X410 at the full sample rate
> > across 4 channels. I am getting occasional issues where data is
> > dropped (terminal messages show “D” error). I have been able to get
> > DPDK to work but that does not seem to have resolved the issue. By my
> > calculation, this comes out to a data rate of 5.12*10^9 Gbit/s
> >
> > The current host computer has an i9-13900KS, Nvme, 128 GB of RAM, and
> > I am currently using a Mellanox 100 Gbit QSFP network card
> >
> > I would say in general, I am able to save just under 100% of all the
> > data I request from the x410, however, for our application, it is very
> > critical that we do not lose any data. If I run the default CG_400
> > image with benchmark rate(1 channel only), I do not get dropped data.
> > The only significant difference between my custom host software and
> > benchmark_rate.cpp is I save data to a .dat file(similar to
> > rx_samples_to_file.cpp) .
> >
> > I have looked at the tuning notes here
> > https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD. I have tried
> > DPDK, core isolation/ disabling system interrupts, nice priority,
> > multithreading/uhd::set_thread_priority, but none have seemed to
> > resolve the issue.
> >
> > What I have noticed is that when I get a “D” error, it corresponds to
> > recv() returning a number of samples less than samples per buffer,
> > followed by a return value of 0.
> >
> > My current assumption is that the task of saving data to NVME is
> > creating a critical path that cant be resolved with thread
> > prioritization or multithreading. Or, maybe I am just not doing thread
> > priority or multithreading correctly. Either way, it is strange to me
> > that recv() can return a number of samples less than buffer outside of
> > a stop signal or timeout signal.
> >
> >
> > Any help/suggestion are appreciated,
> >
> > Joe
> >
> >
> That suggests that packets are getting dropped somewhere in the network
> stack -- possibly the network-card interface into
>the kernel.
>
> You have done all the things here:
>
> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
>
>
> Including increasing the number of ring buffers in the network card?
>

Hi Joe,
I noticed that you have 128GB RAM.  If you turn this into a 120GB RAM
drive, is this sufficient memory depth for your needs? If this is
possible, there is a good chance it will solve your issue.

Prior to DPDK, I tried to save to fast SSD and I always had problems
at high rates (X310, etc,  not X410 rates). I was always able to solve
the problem by saving to a RAM drive.  At one point I even wrote a
separate utility to continually monitor and copy files from the RAM
drive to the SSD so that the RAM drive never actually filled.  Even
when I toyed with DPDK (a long time ago), I had much improved behavior
saving to SSD but still not as good as when I saved to RAM drive which
always has given me performance that rivals benchmark_rate.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Getting "S" error when using dpdk and replay block

[Rob Kossler via USRP-users]

Hi Joe,
The "S" errors imply that the receiver of a packet has detected that
incoming packets are out-of-sequence.  Each successive packet is
sequentially numbered so if everything goes well, the receive side should
receive the packets in sequential order.  If you are sending from your host
to the Replay block, I think it means that the SEP on the FPGA has detected
that the packets are out-of order.  I don't know why this would happen.
Can you slow down the transfer (assuming you don't need the DPDK efficiency
on the Tx side)?  It should back-pressure but maybe it's not for some
reason.
Rob

On Thu, Jan 18, 2024 at 1:46 PM  wrote:

> Hello,
>
> I currently have a custom CG_400 image where I utilize the replay block.
> When I run my application without dpdk on, data is successfully written to
> the DRAM and played back. However, if I use the same image and same
> application, but I turn on DPDK, the application stalls while data is being
> recorded to the replay block, and I get a bunch of “S” errors, which I
> assume implies a “system” error. How do I go about using dpdk with the
> replay block.
>
> Thanks
>
> Joe
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Bug/problem aligning PPS to samples

[Rob Kossler via USRP-users]

Hi Eugene,
Are you expecting that the RF output (for Tx case) should be synced to the
PPS "at the RF output connector"?  It is my understanding that the sync
occurs at some place in the FPGA logic for the "radio" block. There will be
delay as this goes through D/A and RF chain.  Same in reverse for Rx.  As
long as you get a consistent delay (for a given sample rate), can you
calibrate and then choose a playout time that syncs the RF pulse to the PPS
pulse?
Rob

On Fri, Jan 12, 2024 at 4:38 PM Eugene Grayver 
wrote:

> Hello,
>
> There appears to be a bug related to alignment of the PPS to samples.  The
> issue applies to both TX and RX and was replicated on N321 and X310 using
> UDH 3.15 and 4.6.  It therefore appears to be an FPGA issue.
>
> *TX experiment*
> 
>
>- USRP is provided with external PPS and 10 MHz
>- The PPS input is split and goes to the USRP and a scope
>- The USRP output goes to a scope
>- USRP outputs a file
>   - First 1000 samples are 1, remaining are zero
>   - File size = sample rate (i.e. repeats every second)
>- Setup the experiment using both:
>   - GR file_source + usrp_sink
>  - Sync to unknown PPS
>  - usrp.set_start_time(5)
>   - Standalone C++ application (based on tx_samples_from_file)
>  - Added code to set_time_unknown_pps(0), then set start time
>  using metadata to 5
>
> Results:
>
>- The USRP output is delayed relative to the PPS as observed on the
>scope
>- The delay is ~1.2 us for X310 and ~100us for N321
>- The delay changes slightly (<1us) depending on the sample rate (e.g.
>10 Msps vs 20 Msps)
>
>
> *RX experiment*
> 
>
>- USRP is provided with external PPS and 10 MHz
>- USRP input is a pulse (generated using technique above) that repeats
>every second
>- Pulse is aligned to PPS, verified using a scope
>   - USRP records samples starting on a second boundary (time_t(5))
>- GR usrp_source + file_sink
>   - standalone C++ application (based on rx_samples_to_file)
>   - Added code to set_time_unknown_pps(0), then set start time using
>  metadata to 5
>   - Recorded samples are analyzed to find the first 'large' value
>
> Results
>
>- Recording appears to start late relative to PPS (only verified on
>N321, delay is ~100 us, same as for the TX delay)
>
>
> *Thoughts*
>
>- I recall (years ago) there was a fix to a similar problem.  The FPGA
>was modified to trigger ADC/DAC samples after the DDC rather than before.
>Did it regress at some point?
>
>
>- The delays are very consistent, indicating that the PPS is in fact
>being used (i.e. it is not random).
>
>
>- We ran some experiments to analyze the stability and accuracy of
>*relative* timing between RX and TX (i.e. turn-around) when the start
>time for TX and RX are specified.  The results are excellent – delay is
>stable and accurate to < 100 ps.
>
>
> This seems like a simple thing to fix in the FPGA – there is no reason for
> the delay to be > 1 sample clock.
>
> Eugene.
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Engineer
> Tel: 310.336.1274
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

No problem.  I think you will be very glad you did.  With this version,
some examples (such as benchmark_rate) can be used with multiple devices
and external synchronization.

Regarding overflows, I can tell you that when using "rx_samples_to_file" or
similar programs to capture the incoming streaming and save to the HDD/SDD,
I have always had MUCH better luck if I configured a RAM file system and
saved to a file in this file system (i.e., saving to RAM). Of course, then
your capture is constrained by the size of your RAM file system, but if you
can live with this limitation, the likelihood of overflow goes way down.
Even with fast SSDs that would seem to have the bandwidth needed to save
continuously, I have still had much more issues than with a RAM file system.
Rob

On Mon, Jan 8, 2024 at 12:11 PM Anabel Almodovar 
wrote:

> Dear Rob,
>
> In the end, I upgraded the OS version with Ubuntu 22.04 and UHD to version
> 4.5.0. Although I get overflows I no longer get the error I had before.
>
> I appreciate your help.
>
> Regards,
> Anabel
>
> El mié, 20 dic 2023 a las 15:55, Rob Kossler () escribió:
>
>> I am not certain, but I believe that the benchmark_rate example in UHD
>> 3.12 does not support "sync-ing" of multiple devices.  The recent versions
>> of benchmark_rate do support this.  In any case, it is not difficult to add
>> if you want (configuring all devices to use external Ref/PPS and then
>> resetting the clocks for all devices at a common PPS). The "sequence"
>> errors below seem consistent with this hypothesis that the devices are not
>> sync-ed.
>>
>> So, it seems that you do not have "performance issues" if you are able to
>> run 4x100 MS/s in the single device case.
>>
>> In your original email, you mentioned that you were running
>> "rx_samples_to_file".  Maybe you could try changing the file to "/dev/null"
>> (I think that is right) in order to simply "throw away" the received
>> samples.  Or, you could just modify the source code to skip the file
>> writing. This might let you know if the file writing is causing havoc.
>> Rob
>>
>> On Wed, Dec 20, 2023 at 6:41 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> When I run the benchmark_rate sometimes work, sometimes no. With 4
>>> channels there is no problem.  This is one of the error:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *rs3_lab@RS3-lab:~/workarea-uhd/uhd/host/examples/build$ sudo
>>> ./benchmark_rate
>>> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9"
>>> --rx_subdev="A:0 A:1 B:0 B:1" --rx_rate 100e6 --ref="external"
>>> --pps="external" --channels="0,1,2,3,4,5,6,7"[INFO] [UHD] linux; GNU C++
>>> version 5.4.0 20160609; Boost_105800;
>>> UHD_3.12.0.HEAD-0-gec786351[00:00:00.16] Creating the usrp device with:
>>> addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9...[INFO]
>>> [X300] X300 initialization sequence...[INFO] [X300] Maximum frame size:
>>> 8000 bytes.[INFO] [X300] Maximum frame size: 8000 bytes.[INFO] [X300]
>>> Maximum frame size: 8000 bytes.[INFO] [X300] Maximum frame size: 8000
>>> bytes.[INFO] [X300] Radio 1x clock: 200 MHz[INFO] [X300] Radio 1x clock:
>>> 200 MHz[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>> 0xF1F0D000)[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1292
>>> MB/s)[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1308 MB/s)[INFO]
>>> [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)[INFO]
>>> [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)[INFO]
>>> [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)[INFO]
>>> [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)[INFO]
>>> [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)[INFO]
>>> [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)[WARNING]
>>> [X300] Cannot update master clock rate! X300 Series does not allow changing
>>> the clock rate during runtime.[INFO] [GPS] No GPSDO found[INFO]
>>> [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)[INFO]
>>> [1/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s)[INFO] [1/DmaFIFO_0] BIST
>>> 

[USRP-users] Re: Benchmarking x410 with Mellanox with DPDK

[Rob Kossler via USRP-users]

Hi Joe,
Perhaps you need a different "mgmt_addr" and "addr"?  I seem to recall that
it was necessary to have a management address that was the typical RJ45 and
then a data streaming address that went to the high speed IO.  My memory is
for the N series USRPs - I have no experiment with the X410.
Rob

On Wed, Dec 20, 2023 at 1:42 PM  wrote:

> Hello,
>
> I am currently attempting to benchmark the x410 with the Mellanox
> ConnectX-5 PCi Card over QSFP with the CG_400 image currently loaded on the
> x410. I am currently using a 13th gen intel i9-13900KS on the host machine.
> I currently have a QSFP cable connected between the Mellanox card and the
> x410
>
> I am following these instructions…
> https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD
>
> However, when I get to the benchmark_rate, I get the following output
>
> ./benchmark_rate --rx_rate 491.52e6 --rx_channels 0 --tx_rate 491.52e6
> --tx_channels 0 --args "addr=192.168.10.2,use_dpdk=1"
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11;
> UHD_4.5.0.main-2-ga7657c80
>
> [WARNING] [PREFS] Loaded config from /root/.uhd. This location is
> considered deprecated, consider moving your config file to /root/.config
> instead.
>
> EAL: Detected 32 lcore(s)
>
> EAL: Detected 1 NUMA nodes
>
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
>
> EAL: Selected IOVA mode 'PA'
>
> EAL: No available hugepages reported in hugepages-1048576kB
>
> EAL: Probing VFIO support...
>
> EAL: VFIO support initialized
>
> EAL: PCI device :06:00.0 on NUMA socket -1
>
> EAL: probe driver: 15b3:1017 net_mlx5
>
> EAL: PCI device :06:00.1 on NUMA socket -1
>
> EAL: probe driver: 15b3:1017 net_mlx5
>
> [ERROR] [DPDK] Could not find route to destination address 192.168.10.2
>
> [ERROR] [X300] X300 Network discovery error RuntimeError: DPDK: Could not
> find route to destination address 192.168.10.2
>
> [00:00:00.000215] Creating the usrp device with:
> addr=192.168.10.2,use_dpdk=1...
>
> [ERROR] [DPDK] Could not find route to destination address 192.168.10.2
>
> [ERROR] [X300] X300 Network discovery error RuntimeError: DPDK: Could not
> find route to destination address 192.168.10.2
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=x4xx,product=x410,serial=328AACC,name=ni-x4xx-328AACC,fpga=CG_400,claimed=False,addr=192.168.10.2,use_dpdk=1
>
> [ERROR] [DPDK] Could not find route to destination address 192.168.10.2
>
> [WARNING] [MPMD::XPORT::UDP] Error during MTU discovery on address
> 192.168.10.2: RuntimeError: DPDK: Could not find route to destination
> address 192.168.10.2
>
> [ERROR] [MPMD::MB_IFACE] No CHDR connection available!
>
> [INFO] [MPM.PeriphManager] init() called with device args
> `fpga=CG_400,mgmt_addr=192.168.10.2,name=ni-x4xx-328AACC,product=x410,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.
>
> Error: RuntimeError: No CHDR connection available!
>
> I am having a difficult time parsing these errors at the moment. Should I
> move my config file? Does the “x300 network” refer to an ettus device(I
> have no x3xx connected) or something else? Any suggestions is greatly
> appreciated.
>
> Thanks,
>
> Joe
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

I am not certain, but I believe that the benchmark_rate example in UHD 3.12
does not support "sync-ing" of multiple devices.  The recent versions of
benchmark_rate do support this.  In any case, it is not difficult to add if
you want (configuring all devices to use external Ref/PPS and then
resetting the clocks for all devices at a common PPS). The "sequence"
errors below seem consistent with this hypothesis that the devices are not
sync-ed.

So, it seems that you do not have "performance issues" if you are able to
run 4x100 MS/s in the single device case.

In your original email, you mentioned that you were running
"rx_samples_to_file".  Maybe you could try changing the file to "/dev/null"
(I think that is right) in order to simply "throw away" the received
samples.  Or, you could just modify the source code to skip the file
writing. This might let you know if the file writing is causing havoc.
Rob

On Wed, Dec 20, 2023 at 6:41 AM Anabel Almodovar 
wrote:

> When I run the benchmark_rate sometimes work, sometimes no. With 4
> channels there is no problem.  This is one of the error:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *rs3_lab@RS3-lab:~/workarea-uhd/uhd/host/examples/build$ sudo
> ./benchmark_rate
> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9"
> --rx_subdev="A:0 A:1 B:0 B:1" --rx_rate 100e6 --ref="external"
> --pps="external" --channels="0,1,2,3,4,5,6,7"[INFO] [UHD] linux; GNU C++
> version 5.4.0 20160609; Boost_105800;
> UHD_3.12.0.HEAD-0-gec786351[00:00:00.16] Creating the usrp device with:
> addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9...[INFO]
> [X300] X300 initialization sequence...[INFO] [X300] Maximum frame size:
> 8000 bytes.[INFO] [X300] Maximum frame size: 8000 bytes.[INFO] [X300]
> Maximum frame size: 8000 bytes.[INFO] [X300] Maximum frame size: 8000
> bytes.[INFO] [X300] Radio 1x clock: 200 MHz[INFO] [X300] Radio 1x clock:
> 200 MHz[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1292
> MB/s)[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1308 MB/s)[INFO]
> [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)[INFO]
> [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)[INFO]
> [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)[INFO]
> [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)[INFO]
> [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)[INFO]
> [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)[WARNING]
> [X300] Cannot update master clock rate! X300 Series does not allow changing
> the clock rate during runtime.[INFO] [GPS] No GPSDO found[INFO]
> [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)[INFO]
> [1/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s)[INFO] [1/DmaFIFO_0] BIST
> passed (Throughput: 1315 MB/s)[INFO] [1/Radio_0] Initializing block control
> (NOC ID: 0x12AD1001)[INFO] [1/Radio_1] Initializing block control
> (NOC ID: 0x12AD1001)[INFO] [1/DDC_0] Initializing block control
> (NOC ID: 0xDDC0)[INFO] [1/DDC_1] Initializing block control
> (NOC ID: 0xDDC0)[INFO] [1/DUC_0] Initializing block control
> (NOC ID: 0xD0C0)[INFO] [1/DUC_1] Initializing block control
> (NOC ID: 0xD0C0)[WARNING] [X300] Cannot update master clock
> rate! X300 Series does not allow changing the clock rate during
> runtime.[WARNING] [X300 RADIO] Requesting invalid sampling rate from
> device: 200 MHz. Actual rate is: 100 MHz.[WARNING] [X300 RADIO] Requesting
> invalid sampling rate from device: 200 MHz. Actual rate is: 100
> MHz.[WARNING] [X300 RADIO] Requesting invalid sampling rate from device:
> 200 MHz. Actual rate is: 100 MHz.[WARNING] [X300 RADIO] Requesting invalid
> sampling rate from device: 200 MHz. Actual rate is: 100 MHz.Using Device:
> Multi USRP:  Device: X-Series Device  Mboard 0: X310  Mboard 1: X310  RX
> Channel: 0RX DSP: 0RX Dboard: ARX Subdev: TwinRX RX0  RX
> Channel: 1RX DSP: 1RX Dboard: ARX Subdev: TwinRX RX1  RX
> Channel: 2RX DSP: 0RX Dboard: BRX Subdev: TwinRX RX0  RX
> Channel: 3RX DSP: 1RX Dboard: BRX Subdev: TwinRX RX1  RX
> Channel: 4RX DSP: 0RX Dboard: ARX Subdev: TwinRX RX0  RX
> Channel: 5RX DSP: 1RX Dboard: ARX Subdev: TwinRX RX1  RX
> Channel: 6RX DSP: 0RX Dboard: BRX Subdev: TwinRX RX0  RX
> Channel: 7RX DSP: 1RX Dboard: BRX Subdev: 

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

[Rob Kossler via USRP-users]

OK. So, the error you get with "uhd_image_loader" is caused by a "bad
build" that occurs if the option DRAM=1 is not included when using the
Replay block. I do not know why that the build itself does not fail, but
that is the case.  Thus, you still don't have a valid FPGA build for the
E310 with the Replay block.

For the YML file that I sent, the compatibility with UHD version should be
fixable with minimal changes. Attached is a new file which updates the name
of the radio block. Give this a try. If it doesn't work, see if you can
notice anything obvious that is preventing it from running.
Rob

On Tue, Dec 19, 2023 at 5:07 AM  wrote:

> Dear Rob,
>
> You are right, when I try to run this command “rfnoc_image_builder -y
> ./e310_rfnoc_image_core.yml”, *it fails*. *I also tried to use your given
> YML file*, it was not successful because of the different UHD version.
> The only command which worked for me is “rfnoc_image_builder -y
> ./e310_rfnoc_image_core.yml -t E310_SG3 --fpga-dir ~/uhd/fpga/”.
>
> Moreover I noticed that the bit file from the build folder is the actual
> file which I have to use. But I get error which I discussed earlier.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>


e310_replay_image_core.yml
Description: Binary data
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

[Rob Kossler via USRP-users]

Hi Muhammad,
Originally, you had some build errors such that the design "didn't fit" on
the FPGA.  How did you fix these?  From previous experience, I discovered
that it was necessary to use the option DRAM=1 when building the E31x with
the Replay block.  I see that in your YML, this option is included in the
"default target" but I am wondering if it was not used on your specific
build because you specified the option "-t E310_SG3".  Perhaps if you
rebuild without specifying the target option it will use the default which
will include DRAM=1.

But, even if you successfully attempt the build with the DRAM=1 option,
there is a reasonable chance that the build will fail because the design
may be too big for the FPGA. In this case, you may want to build with
"static linking" as in the YML file that I previously sent.
Rob


On Mon, Dec 18, 2023 at 1:13 PM  wrote:

> Dear Rob,
>
>
> I have following bit files generated at the same time.
>
>1.
>
>named “usrp_e310_sg3_fpga.bit”. this file is in build folder
>2.
>
>named “e31x.bit”. which is in “build-E310_SG3”
>
> build-E310_SG3 folder and build folder, both are in e31x folder.
>
>
> I tried to run both these files and get same error.
>
> the commands are. 1. uhd_image_loader --args type=e3xx,adr=192.168.10.2
> --fpga-path=/home/grcusrp/uhd/fpga/usrp3/top/e31x/build-E310_SG3/e31x.bit
>
>
>
>1.
>
>uhd_image_loader --args type=e3xx,adr=192.168.10.2
>
> --fpga-path=/home/grcusrp/uhd/fpga/usrp3/top/e31x/build/usrp_e310_sg3_fpga.bit
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

[Rob Kossler via USRP-users]

Hi,
Can you attach the YML file you are using to build the image?  Also, I
notice that you are trying to load a file out of the
"../top/e31x/build-E310_SG3/" folder rather than the "../top/e31x/build/"
folder. At the conclusion of the build, the outputs are copied into the
"build" folder. I doubt this matters, but you might try using the one in
the "build" folder (and maybe also take a look at file system time stamps
on the files in each folder to see if they are the same).
Rob

On Mon, Dec 18, 2023 at 11:59 AM  wrote:

> Hi All,
>
>
> I am trying to run this command “uhd_image_loader --args
> type=e3xx,adr=192.168.10.2
> --fpga-path=/home/grcusrp/uhd/fpga/usrp3/top/e31x/build-E310_SG3/e31x.bit”
>
>
> But I get error which is “Error: RuntimeError: Failure to create
> rfnoc_graph”.
>
> the whole output is “[INFO] [UHD] linux; GNU C++ version 9.4.0;
> Boost_107100; UHD_4.4.0.HEAD-0-g5fac246b
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=e3xx,product=e310_sg3,serial=31370FC,name=ni-e31x-31370FC,fpga=n/a,claimed=False,addr=192.168.10.2,skip_init=1
>
> [INFO] [MPMD] Claimed device without full initialization.
>
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
>
> [INFO] [MPM.PeriphManager] Installing component `fpga'
>
> [INFO] [MPM.PeriphManager] Installing component `dts'
>
> [INFO] [MPMD IMAGE LOADER] Update component function succeeded.
>
> [INFO] [MPM.RPCServer] Resetting peripheral manager.
>
> [WARNING] [MPM.PeriphManager] Skipping HW/SW compatibility check!
>
> [INFO] [MPM.PeriphManager] Device serial number: 31370FC
>
> [WARNING] [MPM.PeriphManager] Found more EEPROM paths than daughterboards.
> Ignoring some of them.
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=e3xx,product=e310_sg3,serial=31370FC,name=ni-e31x-31370FC,fpga=n/a,claimed=False,addr=192.168.10.2,adr=192.168.10.2,find_all=1
>
> [WARNING] [MPM.PeriphManager] Cannot run deinit(), device was never fully
> initialized!
>
> [INFO] [MPM.PeriphManager] init() called with device args
> `adr=192.168.10.2,find_all=1,fpga=n/a,mgmt_addr=192.168.10.2,name=ni-e31x-31370FC,product=e310_sg3'.
>
> [WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!
>
> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
>
> [INFO] [0/Radio#0] CODEC loopback test passed
>
> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
>
> [INFO] [0/Radio#0] CODEC loopback test passed
>
> [ERROR] [RFNOC::GRAPH] Error during initialization of block 0/Replay#0!
>
> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
> RfnocError: OpTimeout: Control operation timed out waiting for ACK
>
> Error: RuntimeError: Failure to create rfnoc_graph.”
>
>
> I am trying to build an fpga image with RFNoC. I have YML file which
> includes replay block which I copied to the folder (uhd/fpga/usrp3/top/e31x)
>
> I have executed this command “rfnoc_image_builder -y
> ./e310_rfnoc_image_core.yml -t E310_SG3 --fpga-dir ~/uhd/fpga/”.
>
>
> After this command I got no errors but warnings. result is
>
> Warnings: 1073
>
> Critical Warnings: 125
>
> Errors: 0
>
> make[1]: Leaving directory '/home/grcusrp/uhd/fpga/usrp3/top/e31x'
>
> Exporting bitstream file...
>
> Exporting build report...
>
> Build DONE ... E310_SG3”
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

How about if you use an unmodified "benchmark_rate"?

On Mon, Dec 18, 2023 at 11:43 AM Anabel Almodovar <
anabel.almodo...@gmail.com> wrote:

> Even with a single card I still get the same error.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Creating the usrp device with:
> addr0=192.168.60.2,second_addr0=192.168.50.2,recv_buff_size=9...Creating
> the subdevice with: A:0 A:1 B:0 B:1...Using Device: Single USRP:  Device:
> X-Series Device  Mboard 0: X310  RX Channel: 0RX DSP: 0RX Dboard:
> ARX Subdev: TwinRX RX0  RX Channel: 1RX DSP: 1RX Dboard: A
> RX Subdev: TwinRX RX1  RX Channel: 2RX DSP: 0RX Dboard: BRX
> Subdev: TwinRX RX0  RX Channel: 3RX DSP: 1RX Dboard: BRX
> Subdev: TwinRX RX1  TX Channel: 0TX DSP: 0TX Dboard: ATX
> Subdev: Unknown (0x) - 0  TX Channel: 1TX DSP: 0TX Dboard: B
> TX Subdev: Unknown (0x) - 0Número de canales detectados: 4Número de
> tarjetas detectadas: 1Actual RX Rate: 50.00 Msps...Actual Acquisition
> Time to: 0.00 Seconds.Actual RX Freq: 800.00 MHz...Actual RX Gain:
> 5.00 dB...Actual RX Bandwidth: 50.00 MHz...Setting LO
> source...[INFO] [MULTI_USRP] 1) catch time transition at pps edge[INFO]
> [MULTI_USRP] 2) set times next pps (synchronously)Press Ctrl + C to
> stop streaming...STAR SAMPLING ...D[ERROR] [STREAMER] The receive packet
> handler failed to time-align packets. 1002 received packets were processed
> by the handler. However, a timestamp match could not be determined.D[ERROR]
> [STREAMER] The receive packet handler failed to time-align packets. 1002
> received packets were processed by the handler. However, a timestamp match
> could not be determined.^CReceived 15208 samples in 6.703929
> seconds29.8325 MspsDone!*
>
>
> El lun, 18 dic 2023 a las 17:13, Rob Kossler () escribió:
>
>> Several comments:
>>
>>- It seems like multiple things are going on.  You mentioned the
>>original "failed to time align" error and below you mentioned 'O' and 'D'.
>>   - The time-align error I did not expect had anything to do with
>>   "performance". This seemed to me that the first packet arriving from 
>> device
>>   1 had a different time stamp than the first packet arriving from 
>> device 2.
>>   Now, I'm not so sure
>>   - But, the 'O' and 'D' are often related to "performance".
>>   Overflow 'O' occurs when the 'Radio' block has A/D samples that it 
>> needs to
>>   put in a FIFO but the FIFO is full because it is not being emptied fast
>>   enough (presumably by the host PC).  A dropped packet (or sequence 
>> error)
>>   'D' occurs when the host PC detects that the incoming packets are not 
>> in
>>   sequential order. This can occur if the host PC Ethernet handling 
>> becomes
>>   overwhelmed and simply discards a set of incoming packets for a time
>>   period. Both 'O' and 'D' can imply that the host PC is not keeping up 
>> with
>>   incoming data
>>- In any case, you may want to simplify the problem by dropping from
>>two devices to one device.  See if you can eliminate some or all of these
>>problems when using only 4 channels.
>>- If you drop to one device, you can use benchmark_rate to test
>>performance.  If you do not use "second_addr", you should be able to get
>>4x50 MS/s.  If you use "second_addr", you should be able to get 4x100 
>> MS/s.
>>- Regarding your needed changes to "rx_samples_to_file", I guess I
>>was thinking about the latest version which supports multiple channels.
>>Perhaps UHD 3.12 has a version of this example that only supports a single
>>channel.  You could compare your version to the latest version (say, UHD
>>4.6) to see the improvements to this example.
>>
>>
>> On Mon, Dec 18, 2023 at 7:44 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> Hi Rob,
>>>
>>> Thanks for the suggestions. I have tried deleting the LO sharing, and
>>> nothing changes. Then removing the second addr, and that leads me to get
>>> 'Ds' in addition to the error already mentioned, as it is not able to
>>> handle that much information. Although I don't quite understand the
>>> difference between 'O' and 'D'.
>>>
>>> From what I understand the program is set up for a single channel, so I
>>> need to modify it to get more than one.
>>>
>>> Thank you in advance.
>>>
>>> Regards,
>>> Anabel
>>>
>>> El vie, 15 dic 2023 a las 15:39, Rob Kossler ()
>>> escribió:
>>>
 Hmmm. I'm not sure. Here are a few comments:

- Try running without "second_addr".  I realize that you will need
it for full rate (4 x 100MS/s for each X310), but you could run at 50 
 MS/s
without second_addr
- Try running without shared LO. I don't think you would need to
physically change any sharing cables.
- I am curious why you needed to modify the streamer, 

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

Several comments:

   - It seems like multiple things are going on.  You mentioned the
   original "failed to time align" error and below you mentioned 'O' and 'D'.
  - The time-align error I did not expect had anything to do with
  "performance". This seemed to me that the first packet arriving
from device
  1 had a different time stamp than the first packet arriving from
device 2.
  Now, I'm not so sure
  - But, the 'O' and 'D' are often related to "performance".  Overflow
  'O' occurs when the 'Radio' block has A/D samples that it needs
to put in a
  FIFO but the FIFO is full because it is not being emptied fast enough
  (presumably by the host PC).  A dropped packet (or sequence error) 'D'
  occurs when the host PC detects that the incoming packets are not in
  sequential order. This can occur if the host PC Ethernet handling becomes
  overwhelmed and simply discards a set of incoming packets for a time
  period. Both 'O' and 'D' can imply that the host PC is not
keeping up with
  incoming data
   - In any case, you may want to simplify the problem by dropping from two
   devices to one device.  See if you can eliminate some or all of these
   problems when using only 4 channels.
   - If you drop to one device, you can use benchmark_rate to test
   performance.  If you do not use "second_addr", you should be able to get
   4x50 MS/s.  If you use "second_addr", you should be able to get 4x100 MS/s.
   - Regarding your needed changes to "rx_samples_to_file", I guess I was
   thinking about the latest version which supports multiple channels. Perhaps
   UHD 3.12 has a version of this example that only supports a single
   channel.  You could compare your version to the latest version (say, UHD
   4.6) to see the improvements to this example.


On Mon, Dec 18, 2023 at 7:44 AM Anabel Almodovar 
wrote:

> Hi Rob,
>
> Thanks for the suggestions. I have tried deleting the LO sharing, and
> nothing changes. Then removing the second addr, and that leads me to get
> 'Ds' in addition to the error already mentioned, as it is not able to
> handle that much information. Although I don't quite understand the
> difference between 'O' and 'D'.
>
> From what I understand the program is set up for a single channel, so I
> need to modify it to get more than one.
>
> Thank you in advance.
>
> Regards,
> Anabel
>
> El vie, 15 dic 2023 a las 15:39, Rob Kossler () escribió:
>
>> Hmmm. I'm not sure. Here are a few comments:
>>
>>- Try running without "second_addr".  I realize that you will need it
>>for full rate (4 x 100MS/s for each X310), but you could run at 50 MS/s
>>without second_addr
>>- Try running without shared LO. I don't think you would need to
>>physically change any sharing cables.
>>- I am curious why you needed to modify the streamer, pointer buffer
>>and file writing.  I would expect that this would scale with the number of
>>channels such that you didn't need to modify any code in this area
>>- If you were using a more recent UHD, I would recommend switching to
>>the example benchmark_rate which natively supports external PPS and
>>multiple devices.  I noticed that even the most recent rx_samples_to_file
>>does not support external PPS (without modifying the code)
>>- I know you mentioned you were unable to upgrade because of
>>compatibility constraints.  But, even if you cannot upgrade the OS, would
>>you be able to install a new UHD - perhaps in a local folder that did not
>>interfere with the system-wide UHD 3.12 installation.  I typically have
>>multiple UHD versions on my system and switch among them by "sourcing" a
>>given setup file as needed.
>>
>>
>> On Fri, Dec 15, 2023 at 12:52 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> Dear Rob,
>>>
>>> Yes, I use an external clock configuration.
>>>
>>> *std::this_thread::sleep_for( std::chrono::milliseconds(int64_t(1000 *
>>> setup_time) );*
>>>
>>>
>>>
>>> *usrp->set_clock_source("external", uhd::usrp::multi_usrp::ALL_MBOARDS);
>>>usrp->set_time_source("external",
>>> uhd::usrp::multi_usrp::ALL_MBOARDS);usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));std::this_thread::sleep_for(std::chrono::seconds(1));*
>>>
>>> I have only modified the code to get 8 channels and LO sharing. I want
>>> to get a continuous acquisition setup without losing samples. But I am
>>> starting with something basic at the moment. Any suggestions are welcome.
>>> So I've modified the streamer, the pointer buffer, and added writing files.
>>>
>>> my line is
>>> *$sudo ./rx_samples_to_file_v1
>>> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9"
>>> --subdev="A:0 A:1 B:0 B:1" --channel="0,1,2,3,4,5,6,7" --freq 800e6 --rate
>>> 25e6 --bw 25e6 --gain 70 *
>>>
>>> Regards,
>>>
>>> *Anabel*
>>>
>>>
>>>
>>> El jue, 14 dic 2023 a las 18:25, Rob Kossler ()
>>> escribió:

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

Hmmm. I'm not sure. Here are a few comments:

   - Try running without "second_addr".  I realize that you will need it
   for full rate (4 x 100MS/s for each X310), but you could run at 50 MS/s
   without second_addr
   - Try running without shared LO. I don't think you would need to
   physically change any sharing cables.
   - I am curious why you needed to modify the streamer, pointer buffer and
   file writing.  I would expect that this would scale with the number of
   channels such that you didn't need to modify any code in this area
   - If you were using a more recent UHD, I would recommend switching to
   the example benchmark_rate which natively supports external PPS and
   multiple devices.  I noticed that even the most recent rx_samples_to_file
   does not support external PPS (without modifying the code)
   - I know you mentioned you were unable to upgrade because of
   compatibility constraints.  But, even if you cannot upgrade the OS, would
   you be able to install a new UHD - perhaps in a local folder that did not
   interfere with the system-wide UHD 3.12 installation.  I typically have
   multiple UHD versions on my system and switch among them by "sourcing" a
   given setup file as needed.


On Fri, Dec 15, 2023 at 12:52 AM Anabel Almodovar <
anabel.almodo...@gmail.com> wrote:

> Dear Rob,
>
> Yes, I use an external clock configuration.
>
> *std::this_thread::sleep_for( std::chrono::milliseconds(int64_t(1000 *
> setup_time) );*
>
>
>
> *usrp->set_clock_source("external", uhd::usrp::multi_usrp::ALL_MBOARDS);
>  usrp->set_time_source("external",
> uhd::usrp::multi_usrp::ALL_MBOARDS);usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));std::this_thread::sleep_for(std::chrono::seconds(1));*
>
> I have only modified the code to get 8 channels and LO sharing. I want to
> get a continuous acquisition setup without losing samples. But I am
> starting with something basic at the moment. Any suggestions are welcome.
> So I've modified the streamer, the pointer buffer, and added writing files.
>
> my line is
> *$sudo ./rx_samples_to_file_v1
> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9"
> --subdev="A:0 A:1 B:0 B:1" --channel="0,1,2,3,4,5,6,7" --freq 800e6 --rate
> 25e6 --bw 25e6 --gain 70 *
>
> Regards,
>
> *Anabel*
>
>
>
> El jue, 14 dic 2023 a las 18:25, Rob Kossler () escribió:
>
>> Hi Anabel,
>> In my opinion, the error you are experiencing has nothing to do with
>> streaming performance settings (such as "performance" governor, network
>> descriptors, MTU size, etc). The issue seems to be that the two X310
>> devices do not have synchronized clocks. In addition to the physical
>> synchronization using OctoClock, you must also configure each device to use
>> external synchronization and you must tell each device to reset its FPGA
>> clock count at a common PPS. The typical sequence is: (1) wait for a PPS to
>> occur (by querying either device), (2) tell each device to reset its FPGA
>> clock at the subsequent PPS (this step must complete before the next PPS
>> arrives).
>>
>> You mentioned that you are using rx_samples_to_file. Did you modify it in
>> any way?  What is your exact command line with all parameters?
>> Rob
>>
>> On Thu, Dec 14, 2023 at 10:29 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> Dear Rob
>>>
>>> Thank you for your answer.
>>> I make use of the CDA-2990 octoclock as a source of synchronization
>>> between both USRPs, in addition to local oscillator sharing. I use dual
>>> 10GigEth connections and a MTU of 9000 to connect the USRPs to the PC.
>>>
>>> Due to various compatibility issues I am unable to upgrade the system.
>>>
>>> When I work with a sample rate of 10MSps I don't get problems but when I
>>> increase to 25MSps I start to get the error. I need them working with
>>> 100MSps. I have tried changing the CPU governor to "performance" to get the
>>> maximum working frequency (*sudo cpupower frequency-set --governor
>>> performance*), as well as changing the number of network interface
>>> descriptors to maximum (*sudo ethtool -G  tx  rx *),
>>> or increasing the dirty memory buffer (*sudo sysctl -w
>>> vm.dirty_ratio=80; sudo sysctl -w vm.dirty_background_ratio=50*), but I
>>> still get the same problem.
>>>
>>> Regards,
>>> Anabel
>>>
>>> El jue, 14 dic 2023 a las 15:38, Rob Kossler ()
>>> escribió:
>>>
 Hi Anabel,
 How are you sync-ing the clocks on the two units? Do you have an
 external PPS source and are you configuring both devices to use this
 external source?

 Finally, do you have the ability to upgrade your OS and your UHD
 versions? There aren't many user's that are using UHD 3.12 so if you have
 issues, it will be hard to get support.
 Rob

 On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar <
 anabel.almodo...@gmail.com> wrote:

> Dear all,
>
> I am trying to make an acquisition with two X310 

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

Hi Anabel,
In my opinion, the error you are experiencing has nothing to do with
streaming performance settings (such as "performance" governor, network
descriptors, MTU size, etc). The issue seems to be that the two X310
devices do not have synchronized clocks. In addition to the physical
synchronization using OctoClock, you must also configure each device to use
external synchronization and you must tell each device to reset its FPGA
clock count at a common PPS. The typical sequence is: (1) wait for a PPS to
occur (by querying either device), (2) tell each device to reset its FPGA
clock at the subsequent PPS (this step must complete before the next PPS
arrives).

You mentioned that you are using rx_samples_to_file. Did you modify it in
any way?  What is your exact command line with all parameters?
Rob

On Thu, Dec 14, 2023 at 10:29 AM Anabel Almodovar <
anabel.almodo...@gmail.com> wrote:

> Dear Rob
>
> Thank you for your answer.
> I make use of the CDA-2990 octoclock as a source of synchronization
> between both USRPs, in addition to local oscillator sharing. I use dual
> 10GigEth connections and a MTU of 9000 to connect the USRPs to the PC.
>
> Due to various compatibility issues I am unable to upgrade the system.
>
> When I work with a sample rate of 10MSps I don't get problems but when I
> increase to 25MSps I start to get the error. I need them working with
> 100MSps. I have tried changing the CPU governor to "performance" to get the
> maximum working frequency (*sudo cpupower frequency-set --governor
> performance*), as well as changing the number of network interface
> descriptors to maximum (*sudo ethtool -G  tx  rx *),
> or increasing the dirty memory buffer (*sudo sysctl -w vm.dirty_ratio=80;
> sudo sysctl -w vm.dirty_background_ratio=50*), but I still get the same
> problem.
>
> Regards,
> Anabel
>
> El jue, 14 dic 2023 a las 15:38, Rob Kossler () escribió:
>
>> Hi Anabel,
>> How are you sync-ing the clocks on the two units? Do you have an external
>> PPS source and are you configuring both devices to use this external source?
>>
>> Finally, do you have the ability to upgrade your OS and your UHD
>> versions? There aren't many user's that are using UHD 3.12 so if you have
>> issues, it will be hard to get support.
>> Rob
>>
>> On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> I am trying to make an acquisition with two X310 equipped with two
>>> TwinRx. I am using Ubuntu 16.04 LTS 64-bit and UHD 3.12. My PC contains
>>> 128GB RAM and an Intel® Xeon(R) Silver 4114 CPU @ 2.20GHz × 40 and a 4TB
>>> SSD. I have modified the example rx_samples_to_file.cpp code to get 8
>>> channels and I get the following error:
>>>
>>> *D*
>>> *[ERROR] [STREAMER] The receive packet handler failed to time-align
>>> packets. 1002 received packets were processed by the handler. However, a
>>> timestamp match could not be determined.*
>>> *Timeout while streaming*
>>>
>>> *[ERROR] [X300] 192.168.60.2 : x300 fw
>>> communication failure #1*
>>> *EnvironmentError: IOError: x300 fw poke32 - reply timed out*
>>> *[ERROR] [UHD] An unexpected exception was caught in a task loop.The
>>> task loop will now exit, things may not work.AssertionError: reply.sequence
>>> == request.sequence*
>>> *  in virtual void
>>> x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, uint32_t)*
>>> *  at
>>> /home/rs3_lab/workarea-uhd/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:135*
>>>
>>> I don't know how to solve the Timeout problem, I have tried to start the
>>> acquisition 1.1 sg in time. But it didn't work.
>>>
>>>
>>> *stream_cmd.stream_now = false;stream_cmd.time_spec =
>>> usrp->get_time_last_pps(0)+1.1;*
>>>
>>> What is the problem and how can I fix it?
>>>
>>> Regards,
>>> Anabel
>>>
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: streamer error X310

[Rob Kossler via USRP-users]

Hi Anabel,
How are you sync-ing the clocks on the two units? Do you have an external
PPS source and are you configuring both devices to use this external source?

Finally, do you have the ability to upgrade your OS and your UHD versions?
There aren't many user's that are using UHD 3.12 so if you have issues, it
will be hard to get support.
Rob

On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar 
wrote:

> Dear all,
>
> I am trying to make an acquisition with two X310 equipped with two TwinRx.
> I am using Ubuntu 16.04 LTS 64-bit and UHD 3.12. My PC contains 128GB RAM
> and an Intel® Xeon(R) Silver 4114 CPU @ 2.20GHz × 40 and a 4TB SSD. I have
> modified the example rx_samples_to_file.cpp code to get 8 channels and I
> get the following error:
>
> *D*
> *[ERROR] [STREAMER] The receive packet handler failed to time-align
> packets. 1002 received packets were processed by the handler. However, a
> timestamp match could not be determined.*
> *Timeout while streaming*
>
> *[ERROR] [X300] 192.168.60.2 : x300 fw communication
> failure #1*
> *EnvironmentError: IOError: x300 fw poke32 - reply timed out*
> *[ERROR] [UHD] An unexpected exception was caught in a task loop.The task
> loop will now exit, things may not work.AssertionError: reply.sequence ==
> request.sequence*
> *  in virtual void
> x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, uint32_t)*
> *  at
> /home/rs3_lab/workarea-uhd/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:135*
>
> I don't know how to solve the Timeout problem, I have tried to start the
> acquisition 1.1 sg in time. But it didn't work.
>
>
> *stream_cmd.stream_now = false;stream_cmd.time_spec =
> usrp->get_time_last_pps(0)+1.1;*
>
> What is the problem and how can I fix it?
>
> Regards,
> Anabel
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Read user registers with RFNoC

[Rob Kossler via USRP-users]

Take a look at the block controller for the UHD example "gain" block found
here
.
Note how this block doesn't even bother with creating a property. Instead
there is simply a set and get function which pokes or peeks an FPGA
register.  But, I don't know how to configure gnuradio so that it can call
this custom function.

On Wed, Dec 13, 2023 at 11:12 AM  wrote:

> Hi Rob,
>
> Do you mean instead of doing it across the register_property as the
> set_int_property does, directly call the peek function?
>
> Now I have this in the controller:
>
> register_property(&_test_reg, [this]() {
>
> int test_reg = this->regs().peek32(REG_TEST_ADDR);
>
> this->_test_reg.set(test_reg);
>
> });
>
> Do you suggest changing it to something like this? (taken from
> uhd/host/lib/rfnoc/ddc_block_control.cpp)
>
>
> double get_freq(const size_t chan) const
>
> {
>
> return _freq.at(chan).get();
>
> }
>
>
> “_freq” seems to be also a property_t class as “_test_reg” is. What’s the
> difference of doing it that way?
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Read user registers with RFNoC

[Rob Kossler via USRP-users]

Yes, I think that moving out of gnuradio - at least temporarily - is a good
idea. Once you have the block working directly with UHD, it will make the
transition to gnuradio easier.

That said, I did take a quick glance at gnuradio and noticed that the
rfnoc_ddc class has a function "set_freq" and I noticed similar functions
on other rfnoc block classes.  This must mean that it is possible to
declare & define & utilize a custom function for a specific rfnoc block in
gnuradio.  Thus, perhaps you could define a "get_register" function for
your rfnoc block that simply peeks your register.

Finally, the access error you got using set_int_property is a UHD generated
error in "property.hpp" (not generated  by gnuradio).  It might imply that
you are accessing the UHD property before it is initialized. See this page
 for a
description of UHD properties in general as well as the "is_valid" function
which can be used to determine if the property has been initialized.  Of
course, if you abandon using properties, this is irrelevant.

On Wed, Dec 13, 2023 at 5:43 AM  wrote:

> Hi Rob,
>
> Thanks for the clarification. I tried to set the test_reg value by calling
> the set_int_property with a random value from the python script but I got
> this error:
>
> Traceback (most recent call last):
>
> File "registro_gain.py", line 360, in 
>
> main()
>
> File "registro_gain.py", line 338, in main
>
> tb.start()
>
> File "/usr/local/lib/python3/dist-packages/gnuradio/gr/top_block.py", line
> 111, in start
>
> top_block_start_unlocked(self._impl, max_noutput_items)
>
> File "/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py",
> line 4832, in top_block_start_unlocked
>
> return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
>
> RuntimeError: RuntimeError: AccessError: Attempting to write to property
> `test_reg' without access privileges!
>
> I thought that occurred because I hadn’t defined the set_int_property
> function inside my block controller. So I included the method and now I
> have the following error:
>
> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
> RuntimeError: Attempting to double-register property: test_reg[USER:0]
>
> I don’t know any other mechanism to change that signal in GNURadio so I
> will try to translate my graph to use the uhd API directly
>
>
> Kind Regards,
>
> Maria
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

[Rob Kossler via USRP-users]

Wade,
With current versions of the replay block supporting a FIFO mode, is there
any reason why Ettus does not include a statically linked Replay block as
part of the default image for the E310?
Rob

On Tue, Dec 12, 2023 at 2:18 PM Rob Kossler  wrote:

> A while back, I built an E310 image using "static" linking. This allowed
> me to include a 2 channel replay block with a 2 channel radio.  The yml may
> require an update or two to work with the current UHD version, but see if
> you can build an image with static links.  Keep in mind that with static
> links you will be forced to use the replay block since you will not be able
> to dynamically bypass it.
> Rob
>
>
> On Tue, Dec 12, 2023 at 1:55 PM  wrote:
>
>> Could you please tell me how can solve this issue? As I am using GNU
>> radio, when I increase sample rate beyond 2MS/s it misses samples. So,
>> Ettus suggested me to use RFNoC replay Block. They also provided me with
>> YAML file. I have two E313 USRPs and I have to use them for outdoor channel
>> modelling. Could you please help me with that?
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

[Rob Kossler via USRP-users]

A while back, I built an E310 image using "static" linking. This allowed me
to include a 2 channel replay block with a 2 channel radio.  The yml may
require an update or two to work with the current UHD version, but see if
you can build an image with static links.  Keep in mind that with static
links you will be forced to use the replay block since you will not be able
to dynamically bypass it.
Rob


On Tue, Dec 12, 2023 at 1:55 PM  wrote:

> Could you please tell me how can solve this issue? As I am using GNU
> radio, when I increase sample rate beyond 2MS/s it misses samples. So,
> Ettus suggested me to use RFNoC replay Block. They also provided me with
> YAML file. I have two E313 USRPs and I have to use them for outdoor channel
> modelling. Could you please help me with that?
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>


e310_replay_image_core.yml
Description: Binary data
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Read user registers with RFNoC

[Rob Kossler via USRP-users]

Hi Maria,
The UHD "register_property" callback function (in this case a lambda
function that calls peek) only gets executed when the "dirty" property gets
marked "clean". Otherwise, if you query the property when it is already
considered "clean" by UHD, it simply returns the current property value
(without executing this "peek"). So, my workaround is to force UHD to know
that the property is "dirty" by setting it to something different than the
current value.  This is admittedly a hack. If gnuradio offers another
mechanism for calling custom RFNoC block functions (different from using
properties as you have done), this may be the most straightforward solution.
Rob

On Tue, Dec 12, 2023 at 11:55 AM  wrote:

> Hi Rob,
>
> Thanks for your answer.
>
> I’m not 100% sure but what I think is that the get_int_property function
> in python/gnuradio calls the peek function in c++/UHD as I have to write
> that on my block controller:
>
>
> register_property(&_test_reg, this
>  {
>
> int test_reg = this->regs().peek32(REG_TEST_ADDR);
> this->_test_reg.set(test_reg);})
>
> But as you said, probably do it through the get_int_property does not
> update the value.
>
> I will try the workaround you suggest and see.
>
> Kind regards,
>
> Maria
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Read user registers with RFNoC

[Rob Kossler via USRP-users]

Hi Maria,
I don't know the exact problem, but I want to mention that UHD "properties"
can behave in unexpected ways. In my opinion, they are not well suited to
providing a changing property value if UHD is unaware that a change has
occurred. The UHD "get" function of the property does not execute unless
UHD thinks that the property is stale (dirty).  If UHD thinks that the
property is not stale, it just returns the previous value.  I think that
you can tell UHD that the property is "always dirty", but then this
will cause UHD to read it frequently.  I have not found a way to tell UHD
to execute my "get" property function only when I query the property.

Since I do not use gnuradio, I don't know if using "properties" is the only
way available to you.  By using UHD directly, I can just call "peek" or
whatever function I create whenever I want to read my FPGA register.  If
this is possible from gnuradio, this may be your answer.

Otherwise, I have found a workaround by calling the "set" property function
(with a bogus value that is ignored) which can be used to cause the "peek"
to execute and update the property value. You just need to make sure that
your bogus value is not equal to the current property value or else UHD
will think it doesn't need to execute anything.

Rob


On Tue, Dec 12, 2023 at 9:59 AM Marcus D. Leech 
wrote:

> On 12/12/2023 09:41, mamuk...@gmail.com wrote:
>
> Hi Marcus,
>
> Thanks for your answer.
> So, there shouldn’t be any problem on the UHD side with the reading, is a
> gnuradio thing, right?
> From what I see on the Python code generated for the Function Probe, it
> calls the “get_int_property” register function, which seems the one that is
> used for the register reading in UHD, but I will cross-post the question in
> discuss-gnuradio so they can help me clarify.
>
> Kind Regards,
>
> Maria
>
> I didn't immediately see anything, but I'm not an RFNOC expert.  I
> suggested the diagnostics within your flow-graph just to
>make sure that it is actually getting called.  Just put a diagnostic
> print inside your "get_int_property" function.
>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC: RX & TX triggering for RFNoC block only flowgraph

[Rob Kossler via USRP-users]

Hi Xianglong,
The thread you provided is pretty old.  On recent UHD versions (including
4.4), it is possible to work directly without the splitstream block (i.e.,
Radio-Rx => custom block => Radio-Tx).  You may need to handle time stamps
- if your Radio-Rx is inserting time stamps, they will by definition arrive
"Late" to the Radio-Tx if your custom block does not adjust them.  You also
might need to define your RFNoC graph with one edge as a "back edge" or
something like that so that the RFNoC graph does not loop.

You may find it easier to get this working outside of gnuradio - perhaps
using the rfnoc_radio_loopback example

or a modification of this for your custom block.
Rob

On Sun, Dec 3, 2023 at 12:24 PM Xianglong Wang 
wrote:

> Dear All,
>
> I am using UHD 4.4 and GNURadio 3.10 and I am trying to set up an RX-TX
> passthrough flow graph as discussed in this thread (
> https://lists.ettus.com/empathy/thread/MJKCCJEVNJKJOIRORPWDI6Z5WZNHSR3B?hash=MJKCCJEVNJKJOIRORPWDI6Z5WZNHSR3B#MJKCCJEVNJKJOIRORPWDI6Z5WZNHSR3B
> ).
>
>  However, my flow graph is not working either, and when I add the split
> streamer as said in the thread, only the RX works, but the TX does not. How
> can I get both RX and TX to work with such a flow graph? Thanks in advance.
>
> Kind regards,
> Xianglong
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

[Rob Kossler via USRP-users]

Slight update.  When the tune result reports the actual frequency as 450
MHz for a requested frequency of 2450 MHz, the 450 MHz represents an LO at
360 MHz and a digital IF of 90 MHz. Not sure why but that is what is
happening.  The digital IF is truly at 90 MHz. The LO is not at 360 MHz but
at the requested 2450 MHz.  Thus, when I checked for the signal yesterday,
it was not at the requested frequency only because of the digital IF. If I
set the digital IF to 0, then the signal shows up at 2450 MHz (but still
reporting that it is at 360 MHz).

On Tue, Nov 14, 2023 at 10:45 AM Marcus D. Leech 
wrote:

> On 13/11/2023 22:29, Rob Kossler via USRP-users wrote:
>
> Hi,
> I am having an issue with successfully tuning the frequency for the Tx
> side of an X310/UBX and it appears to me that a bug was introduced in UHD
> 4.4 (I haven't checked more recent versions, but I expect that they are
> also affected).  The issue is that when you request a frequency such as
> 2450 MHz, the tune result returns with an actual frequency around 450 MHz,
> and there does not appear to be an RF signal at the requested frequency.
>
> I submitted an issue with Ettus' issue tracker. But, given the severity of
> this issue, I wanted to check with other users to find out if anyone is
> using the X310/UBX with UHD 4.4 or above and having success with Tx
> tuning.  If so, then it seems I am wrong.  Can anyone confirm one way or
> the other?
> Thanks.
> Rob
>
> I haven't tried this myself.  There may be others in the support org. who
> can try to reproduce and I've rattled their cage.
>   If this is real (and it hasn't been fixed in subsequent releases) it's
> bad.
>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] X310/UBX Tx tuning issue introduced UHD 4.4?

[Rob Kossler via USRP-users]

Hi,
I am having an issue with successfully tuning the frequency for the Tx side
of an X310/UBX and it appears to me that a bug was introduced in UHD 4.4 (I
haven't checked more recent versions, but I expect that they are also
affected).  The issue is that when you request a frequency such as 2450
MHz, the tune result returns with an actual frequency around 450 MHz, and
there does not appear to be an RF signal at the requested frequency.

I submitted an issue with Ettus' issue tracker. But, given the severity of
this issue, I wanted to check with other users to find out if anyone is
using the X310/UBX with UHD 4.4 or above and having success with Tx
tuning.  If so, then it seems I am wrong.  Can anyone confirm one way or
the other?
Thanks.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC Loopback with stream from host

[Rob Kossler via USRP-users]

 the multiply - perhaps the tx_streamer data is not flowing for some
> reason?  If so, this would cause the Overflows.
>
>
>
>
> [2]
> https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/python/uhd/bindings/rfnoc_rx_streamer_python.cc
> [3]
> https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/grc/uhd_rfnoc_rx_streamer.block.yml
>
>
>
>
> On Tue, Oct 17, 2023 at 9:20 AM Philipp Niedermayer 
> wrote:
>
>> Dear Marcus and Rob,
>>
>> The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter.  But
>> I'm not sure how this works when you're using RFNoC from within Gnu Radio.
>>
>> @Marcus: I think for RFNoC it is the RX-Streamer that issues the start
>> command. The C++ implementation [1] has a method to set the start time, but
>> it is neither exposed via the Python bindings [2], nor to GNU Radio [3].
>> Would it be possible to update the bindings?
>>
>> Delaying the Rx Radio start time should be relatively easy to do. While I
>> don't know how to do this from gnuradio, I do it all the time using UHD
>> from C++.  Perhaps you will have to modify the GRC generated python to do
>> it rather than do it from GRC - not really sure.
>>
>> @Rob: What methods are you using to delay the start time? The same as the
>> RX-Streamer [1] uses internally?
>> I tried calling the RX-streamers "start" and "stop" methods, since these
>> are accessible from python. Stopping works, but when re-starting it gives
>> me  (see below).
>>
>> Best
>> Philipp
>>
>> [1]
>> https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/lib/rfnoc_rx_streamer_impl.cc#L83-L93
>> [2]
>> https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/python/uhd/bindings/rfnoc_rx_streamer_python.cc
>> [3]
>> https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/grc/uhd_rfnoc_rx_streamer.block.yml
>>
>>
>> *** MESSAGE DEBUG PRINT 
>> ((rate_now . 1.99964e+06) (rate_avg . 1.99964e+06))
>> 
>> Stopping stream
>> rfnoc_rx_streamer :debug: UHD recv() call timed out.
>> *** MESSAGE DEBUG PRINT ****
>> ((rate_now . 666323) (rate_avg . 1.79964e+06))
>> 
>> rfnoc_rx_streamer :debug: UHD recv() call timed out.
>> rfnoc_rx_streamer :debug: UHD recv() call timed out.
>> Starting stream
>> rfnoc_rx_streamer :debug: Sending start stream command...
>> 
>> >>> Done
>>
>>
>>
>> --
>> *From:* Marcus D. Leech [mailto:patchvonbr...@gmail.com
>> ]
>> *Date:* Monday, October 16, 2023 at 23:41 UTC+2
>> *Subject:* [USRP-users] Re: RFNoC Loopback with stream from host
>>
>> On 16/10/2023 17:31, Rob Kossler via USRP-users wrote:
>>
>> Hi Philipp,
>> 1. Delaying the Rx Radio start time should be relatively easy to do.
>> While I don't know how to do this from gnuradio, I do it all the time using
>> UHD from C++.  Perhaps you will have to modify the GRC generated python to
>> do it rather than do it from GRC - not really sure.
>>
>> The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter.  But
>> I'm not sure how this works when you're using RFNoC
>>   from within Gnu Radio.
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC Loopback with stream from host

[Rob Kossler via USRP-users]

w . 1.99964e+06) (rate_avg . 1.99964e+06))
> 
> Stopping stream
> rfnoc_rx_streamer :debug: UHD recv() call timed out.
> *** MESSAGE DEBUG PRINT 
> ((rate_now . 666323) (rate_avg . 1.79964e+06))
> 
> rfnoc_rx_streamer :debug: UHD recv() call timed out.
> rfnoc_rx_streamer :debug: UHD recv() call timed out.
> Starting stream
> rfnoc_rx_streamer :debug: Sending start stream command...
> OOOOOOOOOOOOOOOO
> >>> Done
>
>
>
> --
> *From:* Marcus D. Leech [mailto:patchvonbr...@gmail.com
> ]
> *Date:* Monday, October 16, 2023 at 23:41 UTC+2
> *Subject:* [USRP-users] Re: RFNoC Loopback with stream from host
>
> On 16/10/2023 17:31, Rob Kossler via USRP-users wrote:
>
> Hi Philipp,
> 1. Delaying the Rx Radio start time should be relatively easy to do. While
> I don't know how to do this from gnuradio, I do it all the time using UHD
> from C++.  Perhaps you will have to modify the GRC generated python to do
> it rather than do it from GRC - not really sure.
>
> The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter.  But
> I'm not sure how this works when you're using RFNoC
>   from within Gnu Radio.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC Loopback with stream from host

[Rob Kossler via USRP-users]

Hi Philipp,
1. Delaying the Rx Radio start time should be relatively easy to do. While
I don't know how to do this from gnuradio, I do it all the time using UHD
from C++.  Perhaps you will have to modify the GRC generated python to do
it rather than do it from GRC - not really sure.
2. Flushing the queue should be possible with your current graph. If you
Stop the Rx radio, shouldn't the samples all flush through the Tx Radio?
3. I have written a custom "repeater" RFNoC block that adjusts the
timestamp by a fixed offset - exactly as you describe and for the same
purpose.  I was able to reduce latency to about 50us (if I
recall correctly) when I included DDC/DUC but I could go as low as 10us if
I implemented Rx_Radio -> FIFO -> repeater -> Tx_Radio (no DDC/DUC).  But,
I never tried your case of having Lates initially and then trying to catch
up by discarding Lates. In my case, there are no Lates even at the
beginning.

One additional note: you may need or want additional FIFO in your path (of
course, I don't really know how much FIFO is implemented in your custom
blocks already). I think that I used the DRAM FIFO so that I could choose a
very long repeater delay.
Rob

On Mon, Oct 16, 2023 at 5:42 AM Philipp Niedermayer 
wrote:

> Dear all,
>
> we are trying to realize an RFNoC loopback flow graph, where data from the
> host is streamed into, such as in this picture:
> The RFNoC Pulse Counter [1], RFNoC Multiply (based on the Gain example)
> [2] and RFNoC Modify Timestamp (to prevent "Late package" error) [3] are
> custom blocks, see link to sources below if required.
>
> We observed that, when starting the flow graph, the CPU has not yet
> provided sufficient samples via the Tx Streamer and there are a few
> underruns happening. This is not surprising considering that GNU Radio has
> to start the block threads etc. all of which is much slower than RFNoC
> starting to stream data.
> As a result, there is a significant delay of about 50 ms between RX and TX
> on the USRP X310 I am testing with in the Lab.
> If we remove the Tx Streamer (and Multiply block) from the flowgraph, then
> the delay is much lower: 100 µs.
>
> I think the reason is, that the TX Radio transmits samples as they come in
> (since the timestamps are removed, otherwise it would drop them due to
> "Late package"), but since both ends, RX and TX have a fixed 200MHz rate,
> and the TX will never "skip" samples, the number of samples-in-flow can
> only increase when an underrun happens as the host does not provide enough
> samples initially, but it can never decrease again. The fact that the delay
> is so much smaller without the stream from the host supports this
> understanding.
>
> I have a few Ideas how this could eventually be mitigated, but I am not
> sure how to implement them, and am looking for some suggestions (or
> alternative approaches):
>
>1. Delay the "start stream command" which starts the RFNoC data flow
>until the host is ready to provide the sampling rate
>--> Is this possible? If yes, how could it be done?
>2. Flush all the block FIFOs shortly after starting the flow graph,
>maybe with a block near the end of the DSP that consumes and drops packages
>for a while.
>--> This could potentially reduce the number of samples-in-flow which
>have aggregated initially back to a "normal" small value
>3. Instead of removing the timestamps, add a fixed offset that covers
>the latency (and makes it deterministic).
>--> The Idea was, that the TX Radio will drop late packages, skipping
>to the next package with a correct timestamp, and thus maintaining a
>constant and deterministic latency between RX and TX.
>--> I did try this one, but unfortunately the TX continuously spills
>L's to the console and does not seam to skip to the next valid package,
>even with a very long offset of 100ms (Is this expected behaviour?). I
>found "underflow_policy" block arg, and according to [4] that should drop
>packages, but the Radio seams to not know such a property?
>
> We would be happy for any suggestion on the matter (please keep
> r.si...@gsi.de in CC)
>
> Kind regards
> Philipp Niedermayer
>
> [1]
> https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_discriminating_pulse_counter/rfnoc_block_discriminating_pulse_counter.v
> [2]
> https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_multiply/rfnoc_block_multiply.v#L219
> [3]
> https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_timestamp_mod/rfnoc_block_timestamp_mod.v#L265-266
> [4] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
>
> UHD: 4.4.0.0 (build from source)
> GNU Radio: 3.10.7.0 (build from source)
> USRP: X310
>
> Philipp Niedermayer
> Phone / Telefon: +49 6159 71 3567
> 

[USRP-users] Re: X310 Appears Laggy Using UHD 4.5

[Rob Kossler via USRP-users]

One more thing.  One difference between 3.15 and 4.xx might be the length
of FIFOs on the FPGA for buffering Tx data arriving from the host.  If the
4.xx buffers are smaller, then it may be more likely for a "glitch" to
occur if your host is a bit "bursty" when providing the samples.  If this
is true, then perhaps you could build a custom X310 image with larger
buffers.


On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler  wrote:

> Hi Anna,
> I do not have a response to your direct question regarding performance.
> However, I have a suggestion that may make the performance irrelevant.
> The  X310 image comes with a Replay block that accesses the DRAM chip for
> storage.  Given that you are sending a repeatable waveform, you should have
> plenty of room to store this ahead of time and playout from the Replay
> block. This is exactly how I do all of my radar testing. While it will take
> some effort to make your application play nice with the Replay block, it
> will be worth it because you will never fight "Late" or "Underrun" again.
>  (Note that there may be a RAM I/O bottleneck if trying to play both
> channels simultaneously from the Replay block at 200 MS/s, but one channel
> will be no problem).
> Rob
>
> On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome 
> wrote:
>
>> Hello,
>>
>> We are developing a radar application built on the Ettus SDR platforms.
>> Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and
>> a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to
>> take advantage of recent power calibration utilities and other features not
>> present in UHD 3.15, so I am now trying to run our code on an X310 with the
>> most recent UHD 4.5 release.
>>
>> When running our code on the X310 with UHD 4.5 I get warnings for both
>> radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): 
>> *[WARNING]
>> [0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses
>> timed commands to transmit and receive samples from a frequency-swept pulse
>> at a consistent interval (pulse repetition frequency). Our application
>> requires a high PRF and we can tolerate some late command errors, but need
>> to log them for post-processing. Using UHD 4.5, the behavior is not as
>> expected in that something seems to be hanging. At some point during the
>> process—I think once we first hit a late command error—the timing becomes
>> very off from what it should be, and eventually, samples stop being
>> transmitted or received and the application just hangs. Sometimes when
>> killing the application, I get this warning: *[WARNING]
>> [RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
>> 0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen
>> when running the application with UHD 3.15.
>>
>> I have tried running the benchmark_rate example with the same host
>> computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high
>> sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout:
>> Control operation timed out waiting for ACK, which stops the test before
>> it begins running. Lower sample rates in UHD 4.5 run, but produce more
>> errors (including sequence errors) than the same set up running UHD 3.15.
>>
>> I have tried refreshing the FPGA image for UHD 4.5 with no change in
>> behavior. The behavior is replicable using multiple host computers (Mac and
>> Ubuntu). If anyone has suggestions on debugging steps, or potential reasons
>> why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well
>> with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect
>> it may have something to do with the command queue and how it evolves after
>> getting behind.
>>
>> Thanks,
>> Anna Broome
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310 Appears Laggy Using UHD 4.5

[Rob Kossler via USRP-users]

Hi Anna,
I do not have a response to your direct question regarding performance.
However, I have a suggestion that may make the performance irrelevant.
The  X310 image comes with a Replay block that accesses the DRAM chip for
storage.  Given that you are sending a repeatable waveform, you should have
plenty of room to store this ahead of time and playout from the Replay
block. This is exactly how I do all of my radar testing. While it will take
some effort to make your application play nice with the Replay block, it
will be worth it because you will never fight "Late" or "Underrun" again.
 (Note that there may be a RAM I/O bottleneck if trying to play both
channels simultaneously from the Replay block at 200 MS/s, but one channel
will be no problem).
Rob

On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome 
wrote:

> Hello,
>
> We are developing a radar application built on the Ettus SDR platforms.
> Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and
> a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to
> take advantage of recent power calibration utilities and other features not
> present in UHD 3.15, so I am now trying to run our code on an X310 with the
> most recent UHD 4.5 release.
>
> When running our code on the X310 with UHD 4.5 I get warnings for both
> radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): 
> *[WARNING]
> [0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses
> timed commands to transmit and receive samples from a frequency-swept pulse
> at a consistent interval (pulse repetition frequency). Our application
> requires a high PRF and we can tolerate some late command errors, but need
> to log them for post-processing. Using UHD 4.5, the behavior is not as
> expected in that something seems to be hanging. At some point during the
> process—I think once we first hit a late command error—the timing becomes
> very off from what it should be, and eventually, samples stop being
> transmitted or received and the application just hangs. Sometimes when
> killing the application, I get this warning: *[WARNING]
> [RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
> 0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen
> when running the application with UHD 3.15.
>
> I have tried running the benchmark_rate example with the same host
> computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high
> sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout:
> Control operation timed out waiting for ACK, which stops the test before
> it begins running. Lower sample rates in UHD 4.5 run, but produce more
> errors (including sequence errors) than the same set up running UHD 3.15.
>
> I have tried refreshing the FPGA image for UHD 4.5 with no change in
> behavior. The behavior is replicable using multiple host computers (Mac and
> Ubuntu). If anyone has suggestions on debugging steps, or potential reasons
> why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well
> with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect
> it may have something to do with the command queue and how it evolves after
> getting behind.
>
> Thanks,
> Anna Broome
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: 10Gb Eth to X310 via PCIe Card Expansion Systems

[Rob Kossler via USRP-users]

On Wed, Sep 27, 2023 at 5:47 PM Marcus D. Leech 
wrote:

> On 27/09/2023 05:15, Olo via USRP-users wrote:
>
> Hello,
> I want to connect X310 with my laptop through 10Gb eth connection and I
> want to ask:
>
>1. If *Intel* *X710* (Dual 10Gb card) with *Sonnttech Echo Express SE
>I* (PCIe Card Expansion Systems) (
>https://www.sonnettech.com/product/echo-express-se1-tb3/overview.html)
>will work (or if you have any experience with it).
>2. Which card do you recommend me to use? (In documentation for 10G
>eth connection (https://files.ettus.com/manual/page_usrp_x3x0.html) it
>is recommended to use *Intel* *X520-DA2* card but you only sell on
>your website *X710-DA2 card* ).
>
>
> Thank you for your answear.
> Olo
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> There are a large number of Intel X520-DA1 and DA2 cards available on
> Amazon--with SFP interfaces.  ANY of those should work.
>   I picked one up a couple of years ago and it worked out of the box.
> Might have been a 10GTek card, but I can't precisely recall.
>

I have successfully used several Intel 10Gbe (and even a Mellanox 25Gbe)
NICs with a Sonnet Echo Express SEL (half height, half length) chassis.
Even though the Intel cards such as the X520-DA2 and XL710 are not listed
on the compatibility list, they seem to work fine as far as I can tell. One
limiting factor is the number of lanes.  Thunderbolt 3 is Gen3x4 (4
lanes).  Some Intel cards (e.g., X520-DA2) are Gen2x8.  Thus, this will
connect to your laptop as Gen2x4 with the corresponding data rate limits
 (16Gbps).
If you are using only a single 10Gbe link, this is not an issue.  So, you
may want to opt for a NIC with Gen3 capability.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: TX Streamer Send Time

[Rob Kossler via USRP-users]

On Mon, Sep 25, 2023 at 9:26 AM Marcus D. Leech 
wrote:

> On 25/09/2023 08:57, Devin Kelly wrote:
>
> Hello,
>
> I have an application where I’m sending many short bursts to a USRP B210
> using uhd::tx_streamer.send() (link below) and I occasionally set the PPS
> time to 0 using set_time_last_pps.
>
> Sometimes I set the PPS time to 0 when there’s still a burst in the USRPs
> queue.  When I do this the burst is transmitted much later than I want.
>
> Is there a way to clear the queue on the USRP or UHD?  That is, if I send
> a TX burst in the distant future can I cancel it before it gets
> transmitted?  Can I clear everything in the TX queue?
>
> I’ve read on this list that calling the stream destructor will do this, is
> that right? I’ve tried this without success.
>
> Thanks!
> Devin
>
> This is an unusual scenario -- what is the reason for constantly resetting
> the timer to zero?   This is not the kind of scenario that
>   was contemplated in the architecture.  I don't think there's a "flush
> pending things in the queue" operation possible--although
>   I admit it might be useful.
>

Like Marcus, I don't know of a way to flush the stream.  But, I do want to
add my two cents of the utility of such a capability.

In many cases, samples get "stuck" in RFNoC blocks.  There are a variety of
reasons such as the timing reason that is the cause of this post, badly
written custom RFNoC blocks (my specialty), and blocks such as FFT that can
get a partial vector of samples in the queue.  In any case, it is not
uncommon to need to power cycle the device for the simple reason of
clearing samples out of the queue of one block or another.  It seems that
there could be an "agreed upon RFNoC standard for 'clear'" or something
similar such that a block would be expected to clear its queues (in a
similar manner to the way in which an RFNoC block is supposed to respect
the 'reset' signal).
Rob

>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Toggling a panel GPIO at a specific time (via RFNoC or otherwise)

[Rob Kossler via USRP-users]

Yes, I believe you will need to ensure monotonically increasing times in
the Radio command queue.  Since we have a multi-threaded application, we
cheated and simply inserted a "delay" in the thread that sets the GPIO
pulse in order to ensure that the command entered the queue after all of
the streaming commands.
Rob

On Thu, Sep 21, 2023 at 5:06 PM David Raeman 
wrote:

> Hi Rob,
>
> Thanks for the pointer, I hadn’t considered trying set_gpio_attr() with a
> command time. I will experiment with this approach..
>
>
>
> My only minor hesitation is that my software also does other interactions
> with the radio during transmission (specifically, updating registers in
> other RFNoC blocks), and it’s unclear to me whether those pokes could get
> blocked in a queue behind a timed command. Assuming so, I might be able to
> sequence interactions to avoid that case.
>
>
>
> Thanks again,
>
> -David
>
>
>
>
>
> *From:* Rob Kossler 
> *Sent:* Thursday, September 21, 2023 4:26 PM
> *To:* David Raeman 
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Toggling a panel GPIO at a specific time (via
> RFNoC or otherwise)
>
>
>
> Hi David,
>
> It may be the case that this functionality already exists in the radio
> block such that you don't need a custom block.  The function
> radio_control->set_gpio_attr() respects the command time.  Here is a
> portion of one of my applications that outputs a gpio pulse after a
> specified delay relative to the streaming 'start_time'.  Would this work
> for your case?
>
> Rob
>
>
>
>   uhd::time_spec_t gpio_on = start_time + gpio_start;
>   this->set_command_time(gpio_on, gpio_mb);
>   this->set_gpio_attr(gpio_pulse_bank, "OUT", -1, gpio_mask, gpio_mb);
>   this->set_command_time(gpio_on + gpio_duration, gpio_mb);
>   this->set_gpio_attr(gpio_pulse_bank, "OUT", 0, gpio_mask, gpio_mb);
>   this->clear_command_time(gpio_mb);
>
>
>
> On Thu, Sep 21, 2023 at 4:01 PM David Raeman <
> da...@synopticengineering.com> wrote:
>
> Hello,
>
>
>
> I'm looking for advice on toggling an E320 GPIO pin at a specific
> uhd::time_spec_t. My use case is a UHD application that starts a long
> transmit burst at a known timespec, then later toggles a pin at a time
> corresponding to the Nth sample being transmitted. The pin controls an
> external RF switch. I recognize there will be some amount of group delay
> through the RFIC and internal analog components – my goal is just to be
> roughly synchronous with samples clocked out of the radio block.
>
>
>
> As a first pass, I have a custom RFNoC block that counts valid samples
> from the start of burst and toggles the pin after the Nth sample (where N
> is provided in a user register). This is a poor solution because there is
> deep buffering downstream in the radio block, so my block sees “sample N"
> and toggles the pin several thousand sample-periods before it's
> transmitted. It isn’t a fixed lag that can be added as a constant –
> consider that if N is small and “sample N” is observed when the FIFO is
> initially being filled, the toggle would occur while the corresponding
> sample is sitting in the back-pressured FIFO waiting for the transmit start
> time.
>
>
>
> Since this is synchronous manipulation of external state, and not just
> samples, I don’t believe it will be sufficient to use CHDR header
> timestamps – the block would also need to know current radio_time, and I’m
> not sure how to get that in an RFNoC block..
>
>
>
> Just wondering if I might be overlooking some simpler approach, or any
> advice on how to plumb this into a custom RFNoC block.
>
>
>
> Thank you,
>
> -David
>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Toggling a panel GPIO at a specific time (via RFNoC or otherwise)

[Rob Kossler via USRP-users]

Hi David,
It may be the case that this functionality already exists in the radio
block such that you don't need a custom block.  The function
radio_control->set_gpio_attr() respects the command time.  Here is a
portion of one of my applications that outputs a gpio pulse after a
specified delay relative to the streaming 'start_time'.  Would this work
for your case?
Rob

  uhd::time_spec_t gpio_on = start_time + gpio_start;
  this->set_command_time(gpio_on, gpio_mb);
  this->set_gpio_attr(gpio_pulse_bank, "OUT", -1, gpio_mask, gpio_mb);
  this->set_command_time(gpio_on + gpio_duration, gpio_mb);
  this->set_gpio_attr(gpio_pulse_bank, "OUT", 0, gpio_mask, gpio_mb);
  this->clear_command_time(gpio_mb);

On Thu, Sep 21, 2023 at 4:01 PM David Raeman 
wrote:

> Hello,
>
>
>
> I'm looking for advice on toggling an E320 GPIO pin at a specific
> uhd::time_spec_t. My use case is a UHD application that starts a long
> transmit burst at a known timespec, then later toggles a pin at a time
> corresponding to the Nth sample being transmitted. The pin controls an
> external RF switch. I recognize there will be some amount of group delay
> through the RFIC and internal analog components – my goal is just to be
> roughly synchronous with samples clocked out of the radio block.
>
>
>
> As a first pass, I have a custom RFNoC block that counts valid samples
> from the start of burst and toggles the pin after the Nth sample (where N
> is provided in a user register). This is a poor solution because there is
> deep buffering downstream in the radio block, so my block sees “sample N"
> and toggles the pin several thousand sample-periods before it's
> transmitted. It isn’t a fixed lag that can be added as a constant –
> consider that if N is small and “sample N” is observed when the FIFO is
> initially being filled, the toggle would occur while the corresponding
> sample is sitting in the back-pressured FIFO waiting for the transmit start
> time.
>
>
>
> Since this is synchronous manipulation of external state, and not just
> samples, I don’t believe it will be sufficient to use CHDR header
> timestamps – the block would also need to know current radio_time, and I’m
> not sure how to get that in an RFNoC block..
>
>
>
> Just wondering if I might be overlooking some simpler approach, or any
> advice on how to plumb this into a custom RFNoC block.
>
>
>
> Thank you,
>
> -David
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC: strange behavior of FFT block

[Rob Kossler via USRP-users]

Hi Luca,
I installed the latest from UHD-4.4 (as of last week).
Rob

On Mon, Sep 18, 2023 at 4:11 AM Bachmaier, Luca <
luca.bachma...@iis.fraunhofer.de> wrote:

> Hi Rob,
>
>
>
> thank you very much for putting effort into finding this bug. Since you’re
> talking about recompiling UHD I’m going to assume you installed UHD from
> source. Which exact version did you build and install? I remember running
> into problems I couldn’t solve when installing the branches UHD-4.3 und
> UHD-4.4 from source.
>
>
>
> Regards
>
> Luca
>
>
>
> *Von:* Rob Kossler 
> *Gesendet:* Donnerstag, 14. September 2023 23:41
> *An:* Marcus D. Leech 
> *Cc:* Bachmaier, Luca ;
> usrp-users@lists.ettus.com; Nieland, Michael <
> michael.niel...@iis.fraunhofer.de>
> *Betreff:* Re: AW: [USRP-users] Re: RFNoC: strange behavior of FFT block
>
>
>
> Hi Luca,
>
> The problem with FFT lengths > 256 is an Ettus bug in
> "rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp").  The
> following snippet from the atomic_item_size property resolver shows the
> issue.  The problem is that "spp" has units of "samples" whereas
> "ais.get()" has units of bytes.  If you modify this code to use "spp*4" and
> recompile UHD, you can run with fft length 1024.
>
> Rob
>
>
>
> if (spp < ais.get()) {
> throw uhd::value_error("samples per package must not
> be smaller than atomic item size");
> }
>
>
>
>
> On Tue, Sep 12, 2023 at 9:55 AM Marcus D. Leech 
> wrote:
>
> On 12/09/2023 07:35, Bachmaier, Luca wrote:
>
> Hi Rob,
>
>
>
> your tip about “rfnox_rx_to_file” is great, I’ve been searching for
> examples for the UHD Python/C++ API for a while now anyway. Unfortunately
> it seems like the error is not due to GNU Radio. Even when trying to create
> a simple “Radio -> FFT -> RX Streamer” chain by calling `./rfnoc_rx_to_file
> --spp=1024 --block-id FFT --block-props length=512` the flowgraph can’t
> even start, I get the same error about the atomic item size. Looking at the
> output, everything should be set correctly:
>
>  […] Requesting samples per packet of: 1024
>
> Actual samples per packet = 1024
>
> […] Setting block properties to: length=512
>
> Error: ValueError: samples per package must not be smaller than atomic
> item size
>
>
>
> Additionally, I’m very much interesting in how you created your own FFT IP
> in Xilinx and separated the parameters. I would be happy to get some
> information from you.
>
> Have you tried spp=fft_length?   I think the last time I did this (years
> ago), that was the requirement...
>
>
>
>
>
> *Von:* Rob Kossler  
> *Gesendet:* Montag, 11. September 2023 16:54
> *An:* Bachmaier, Luca 
> 
> *Cc:* Marcus D. Leech  ;
> usrp-users@lists.ettus.com; Nieland, Michael
>  
> *Betreff:* Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
>
>
>
> Hi Luca,
>
> I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
> is the latest that I have used), but I have successfully used FFT lengths
> up to 4096.  In order to do this, I had to create my own Xilinx FFT IP and
> I also had to separate the concepts of streaming packet length from the FFT
> length.  If you want to do this, I can provide additional info.  However,
> using the "stock" FFT block provided by Ettus, I believe that you should be
> able to stream with FFT length up to 1024 using the N310.
>
>
>
> You mentioned in a previous post that your SPP is 2048.  I think that this
> is an invalid SPP for the radio because of the need for the radio to insert
> "packet header" bytes which reduces the max num samples per packet to
> <=2000 (or about that).  So, my suggestion is to use SPP=1024.
>
>
>
> Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
> will allow you to specify an arbitrary block - in this case the FFT block -
> to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
> rx_streamer".  This eliminates gnuradio from the equation. This example
> will capture samples to a file that you can then plot to see the results.
> You could run this example initially without the FFT block (rx_radio => DDC
> => rx_streamer) and make sure it is working as you expect.  Then you could
> try again with the FFT block inserted.
>
>
>
> Rob
>
>
>
> On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
> luca.bachma...@iis.fraunhofer.de> wrote:
>
> Hi Rob,
>
>
>
> thanks for your reply. What I originally wanted to bring across with my
> message was that I cannot run the flowgraph with fft_sizes larger than 256,
> no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
> the fft_size to  just 512, I also get the error about the atomic item size
> mentioned below. I keep wondering why that is.
>
>
> Regards
>
> Luca
>
>
>
> *Von:* Rob Kossler 
> *Gesendet:* Mittwoch, 6. September 2023 21:29
> *An:* Marcus D. Leech 
> *Cc:* Bachmaier, Luca ;
> usrp-users@lists.ettus.com; Nieland, Michael <
> michael.niel...@iis.fraunhofer.de>
> *Betreff:* Re: 

[USRP-users] Re: RFNoC: strange behavior of FFT block

[Rob Kossler via USRP-users]

On Thu, Sep 14, 2023 at 5:43 PM Marcus D. Leech 
wrote:

> On 14/09/2023 17:40, Rob Kossler wrote:
>
> Hi Luca,
> The problem with FFT lengths > 256 is an Ettus bug in
> "rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp").  The
> following snippet from the atomic_item_size property resolver shows the
> issue.  The problem is that "spp" has units of "samples" whereas
> "ais.get()" has units of bytes.  If you modify this code to use "spp*4" and
> recompile UHD, you can run with fft length 1024.
> Rob
>
> if (spp < ais.get()) {
> throw uhd::value_error("samples per package must not
> be smaller than atomic item size");
> }
>
>
> This must be a relatively-recent bug, because I clearly remember using FFT
> > 256 a few years back.
>
> Thanks so much for finding this, Rob.   Did you file a bug?I'll try to
> point R at it.
>

I didn't file a bug. This bug is recent because the concept of "atomic item
size" is relatively recent.  The concept has the nice feature that it
automatically coerces the radio packet length to be an integer multiple of
the FFT length (or whatever blocks are in the RFNoC block chain). Thus, it
is not even necessary to explicitly set the radio SPP because it will be
set automatically by the RFNoC property resolution process. Although the
code seems to work fine to do this, the bug is just the improper throw-ing
of an exception because of the "byte vs sample" unit issue.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC: strange behavior of FFT block

[Rob Kossler via USRP-users]

Hi Luca,
The problem with FFT lengths > 256 is an Ettus bug in
"rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp").  The
following snippet from the atomic_item_size property resolver shows the
issue.  The problem is that "spp" has units of "samples" whereas
"ais.get()" has units of bytes.  If you modify this code to use "spp*4" and
recompile UHD, you can run with fft length 1024.
Rob

if (spp < ais.get()) {
throw uhd::value_error("samples per package must not be
smaller than atomic item size");
}


On Tue, Sep 12, 2023 at 9:55 AM Marcus D. Leech 
wrote:

> On 12/09/2023 07:35, Bachmaier, Luca wrote:
>
> Hi Rob,
>
>
>
> your tip about “rfnox_rx_to_file” is great, I’ve been searching for
> examples for the UHD Python/C++ API for a while now anyway. Unfortunately
> it seems like the error is not due to GNU Radio. Even when trying to create
> a simple “Radio -> FFT -> RX Streamer” chain by calling `./rfnoc_rx_to_file
> --spp=1024 --block-id FFT --block-props length=512` the flowgraph can’t
> even start, I get the same error about the atomic item size. Looking at the
> output, everything should be set correctly:
>
>  […] Requesting samples per packet of: 1024
>
> Actual samples per packet = 1024
>
> […] Setting block properties to: length=512
>
> Error: ValueError: samples per package must not be smaller than atomic
> item size
>
>
>
> Additionally, I’m very much interesting in how you created your own FFT IP
> in Xilinx and separated the parameters. I would be happy to get some
> information from you.
>
> Have you tried spp=fft_length?   I think the last time I did this (years
> ago), that was the requirement...
>
>
>
>
> *Von:* Rob Kossler  
> *Gesendet:* Montag, 11. September 2023 16:54
> *An:* Bachmaier, Luca 
> 
> *Cc:* Marcus D. Leech  ;
> usrp-users@lists.ettus.com; Nieland, Michael
>  
> *Betreff:* Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
>
>
>
> Hi Luca,
>
> I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
> is the latest that I have used), but I have successfully used FFT lengths
> up to 4096.  In order to do this, I had to create my own Xilinx FFT IP and
> I also had to separate the concepts of streaming packet length from the FFT
> length.  If you want to do this, I can provide additional info.  However,
> using the "stock" FFT block provided by Ettus, I believe that you should be
> able to stream with FFT length up to 1024 using the N310.
>
>
>
> You mentioned in a previous post that your SPP is 2048.  I think that this
> is an invalid SPP for the radio because of the need for the radio to insert
> "packet header" bytes which reduces the max num samples per packet to
> <=2000 (or about that).  So, my suggestion is to use SPP=1024.
>
>
>
> Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
> will allow you to specify an arbitrary block - in this case the FFT block -
> to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
> rx_streamer".  This eliminates gnuradio from the equation. This example
> will capture samples to a file that you can then plot to see the results.
> You could run this example initially without the FFT block (rx_radio => DDC
> => rx_streamer) and make sure it is working as you expect.  Then you could
> try again with the FFT block inserted.
>
>
>
> Rob
>
>
>
> On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
> luca.bachma...@iis.fraunhofer.de> wrote:
>
> Hi Rob,
>
>
>
> thanks for your reply. What I originally wanted to bring across with my
> message was that I cannot run the flowgraph with fft_sizes larger than 256,
> no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
> the fft_size to  just 512, I also get the error about the atomic item size
> mentioned below. I keep wondering why that is.
>
>
> Regards
>
> Luca
>
>
>
> *Von:* Rob Kossler 
> *Gesendet:* Mittwoch, 6. September 2023 21:29
> *An:* Marcus D. Leech 
> *Cc:* Bachmaier, Luca ;
> usrp-users@lists.ettus.com; Nieland, Michael <
> michael.niel...@iis.fraunhofer.de>
> *Betreff:* Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
>
>
>
> Hi Luca,
>
> A couple of things.  The largest FFT size might be limited to 1024 - even
> with MTU=9000.  I think that the maximum packet length is often 2000 or
> 2048 such that when you add a few header bytes, you can no longer achieve
> an FFT packet of 2048.
>
>
>
> Additionally, if you look in fft_block_control.cpp, you will see that
> there is a constant that limits the max size to 1024. This also matches the
> parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
> Xilinx IP file that is implemented.  You can change these in order to build
> different sizes, but these are the defaults.
>
>
>
> If you search the mailing archive, you may find discussion of this topic
> and the need to divorce the concepts of 'fft length' and 'packet length' in
> order to achieve FFT lengths 

[USRP-users] Re: RFNoC: strange behavior of FFT block

[Rob Kossler via USRP-users]

Hi Luca,
I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
is the latest that I have used), but I have successfully used FFT lengths
up to 4096.  In order to do this, I had to create my own Xilinx FFT IP and
I also had to separate the concepts of streaming packet length from the FFT
length.  If you want to do this, I can provide additional info.  However,
using the "stock" FFT block provided by Ettus, I believe that you should be
able to stream with FFT length up to 1024 using the N310.

You mentioned in a previous post that your SPP is 2048.  I think that this
is an invalid SPP for the radio because of the need for the radio to insert
"packet header" bytes which reduces the max num samples per packet to
<=2000 (or about that).  So, my suggestion is to use SPP=1024.

Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
will allow you to specify an arbitrary block - in this case the FFT block -
to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
rx_streamer".  This eliminates gnuradio from the equation. This example
will capture samples to a file that you can then plot to see the results.
You could run this example initially without the FFT block (rx_radio => DDC
=> rx_streamer) and make sure it is working as you expect.  Then you could
try again with the FFT block inserted.

Rob

On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
luca.bachma...@iis.fraunhofer.de> wrote:

> Hi Rob,
>
>
>
> thanks for your reply. What I originally wanted to bring across with my
> message was that I cannot run the flowgraph with fft_sizes larger than 256,
> no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
> the fft_size to  just 512, I also get the error about the atomic item size
> mentioned below. I keep wondering why that is.
>
>
> Regards
>
> Luca
>
>
>
> *Von:* Rob Kossler 
> *Gesendet:* Mittwoch, 6. September 2023 21:29
> *An:* Marcus D. Leech 
> *Cc:* Bachmaier, Luca ;
> usrp-users@lists.ettus.com; Nieland, Michael <
> michael.niel...@iis.fraunhofer.de>
> *Betreff:* Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
>
>
>
> Hi Luca,
>
> A couple of things.  The largest FFT size might be limited to 1024 - even
> with MTU=9000.  I think that the maximum packet length is often 2000 or
> 2048 such that when you add a few header bytes, you can no longer achieve
> an FFT packet of 2048.
>
>
>
> Additionally, if you look in fft_block_control.cpp, you will see that
> there is a constant that limits the max size to 1024. This also matches the
> parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
> Xilinx IP file that is implemented.  You can change these in order to build
> different sizes, but these are the defaults.
>
>
>
> If you search the mailing archive, you may find discussion of this topic
> and the need to divorce the concepts of 'fft length' and 'packet length' in
> order to achieve FFT lengths greater than 1024.
>
> Rob
>
>
>
>
>
> On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech 
> wrote:
>
> On 05/09/2023 04:38, Bachmaier, Luca wrote:
>
> Hello Marcus,
>
>
>
> Thank you for your detailed explanation. I was able to fix the problem
> now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
> (installed from source). With the newer version the FFT block now correctly
> displays a noise floor.
>
>
>
> So far so good, the FFT resolution is still low as I cannot set the size
> higher than 256 (Error “samples per package must not be smaller than atomic
> item size”). As far as I understood, the size should be able to go as high
> as 2048 when using 10Gbit streaming.
>
> My current configuration should enable that:
>
> -  MTU on my interface is set to 9000
>
> -  Parameter spp of RFNoC RX Radio is set to 2048
>
> -  Current FPGA image is of XG type
>
>
>
> In case it’s helpful, here’s the relevant output of `ip a` of my devices:
>
> Host:
>
>  4: enp9s0f1np1:  mtu 9000
> qdisc mq state UP group default qlen 1000
>
> link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
>
> inet 192.168.10.3/24 scope global enp9s0f1np1
>
>valid_lft forever preferred_lft forever
>
>
>
> USRP:
>
>  3: sfp0:  mtu 9000 qdisc
> pfifo_fast qlen 1000
>
> link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
>
> inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
>
>valid_lft forever preferred_lft forever
>
>
>
> I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
> Args" parameter.
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNoC: strange behavior of FFT block

[Rob Kossler via USRP-users]

Hi Luca,
A couple of things.  The largest FFT size might be limited to 1024 - even
with MTU=9000.  I think that the maximum packet length is often 2000 or
2048 such that when you add a few header bytes, you can no longer achieve
an FFT packet of 2048.

Additionally, if you look in fft_block_control.cpp, you will see that there
is a constant that limits the max size to 1024. This also matches the
parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
Xilinx IP file that is implemented.  You can change these in order to build
different sizes, but these are the defaults.

If you search the mailing archive, you may find discussion of this topic
and the need to divorce the concepts of 'fft length' and 'packet length' in
order to achieve FFT lengths greater than 1024.
Rob


On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech 
wrote:

> On 05/09/2023 04:38, Bachmaier, Luca wrote:
>
> Hello Marcus,
>
>
>
> Thank you for your detailed explanation. I was able to fix the problem
> now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
> (installed from source). With the newer version the FFT block now correctly
> displays a noise floor.
>
>
>
> So far so good, the FFT resolution is still low as I cannot set the size
> higher than 256 (Error “samples per package must not be smaller than atomic
> item size”). As far as I understood, the size should be able to go as high
> as 2048 when using 10Gbit streaming.
>
> My current configuration should enable that:
>
> -  MTU on my interface is set to 9000
>
> -  Parameter spp of RFNoC RX Radio is set to 2048
>
> -  Current FPGA image is of XG type
>
>
>
> In case it’s helpful, here’s the relevant output of `ip a` of my devices:
>
> Host:
>
>  4: enp9s0f1np1:  mtu 9000
> qdisc mq state UP group default qlen 1000
>
> link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
>
> inet 192.168.10.3/24 scope global enp9s0f1np1
>
>valid_lft forever preferred_lft forever
>
>
>
> USRP:
>
>  3: sfp0:  mtu 9000 qdisc
> pfifo_fast qlen 1000
>
> link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
>
> inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
>
>valid_lft forever preferred_lft forever
>
> I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
> Args" parameter.
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: VCO can not operate for high sample rate

[Rob Kossler via USRP-users]

Oh, I forgot to mention. With the existing Replay block, you should be able
to load your FMCW waveform in device memory and play it out continuously.
I don't know if the X410 has Replay memory bandwidth limitations that would
restrict your ultimate FMCW bandwidth.  But, you might want to try it out
using "rfnoc_replay_samples_from_file" which can play out any arbitrary
waveform (including FMCW if you create it).  If this generates a signal
that works for you, then you only need to figure out how to control it from
gnuradio.
Rob

On Thu, Aug 24, 2023 at 10:03 AM Rob Kossler  wrote:

> I think that you could implement this transmit waveform in a custom RFNoC
> block such that you would never have any issue with underruns.  Although I
> don't use gnuradio myself, I believe that you could control your block
> easily from gnuradio.  And, although this requires some FPGA programming,
> this would likely be a straightforward FPGA implementation.
> Rob
>
> On Wed, Aug 9, 2023 at 11:54 PM  wrote:
>
>> Hi,
>>
>> TX/RX benchmark works well even up to 245.76MHz of sample rate with my
>> USRPX410 (on 10GbE link).
>>
>> While USRPX410 receiver channel handle high sample rates even far more
>> than 100Msps (245.76MHz), I am not able to transmit high sample rate
>> triangular FMCW waveform with USRPX410 in GNU Radio (by employing VCO to
>> generate chirp signal). It seems VCO (and VCO complex) are not able to
>> generate FMCW signal in high sample rate more than 50Msps, and It issue
>> several underrun errors. Is there any solution to overcome it.
>>
>> Or without using VCO, what are the other solutions to transmit triangular
>> FMCW waveform through GNU Radio and USRPX410? Thank you.
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: UHD4 segmentation fault on creating rx_streamer

[Rob Kossler via USRP-users]

Hi Andrew,
I see what you mean regarding the documentation comment about one streamer
only.  But, this doesn't make sense to me. I wonder if the documentation is
in error. I always use multiple rx and tx streamers.  However, I don't
often destroy and recreate them on the fly.  Anyway, it was my
understanding that the true restriction is that you can only have one
rx_streamer (or tx_streamer) for a given channel when using a multi_usrp
object.  So, if you have a 4 channel device you should be able to have one
rx_streamer using channels 0,1 and another using channels 2,3.
Rob


On Wed, Aug 23, 2023 at 10:17 AM Andrew Fountain via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Brian,
>
> Thanks for the input. Yeah making the rx_streamers at the beginning and
> keeping them around resolves the issue in that test program -- no
> segfaults after 1 Rx iterations total from the two threads. Makes
> sense; if the issue is happening in rx_streamer creation, then we should do
> that as little as possible. We'd just have to re-create the streamers when
> we re-tune or some such.
>
> I was perusing the docs and it also seems like there is also a more
> fundamental misunderstanding on my end. It looks like there can always only
> be one RX streamer at a time per multi_usrp object as per this little note
> in the docs:
> https://files.ettus.com/manual/classuhd_1_1device.html#a0a9e36f353dcce36b4dd8d394c8813e3
>  unless
> I misunderstand. Curses! That seems to indicate that I am relying on
> undefined behavior in either case, even though everything seems to now work
> as expected.
> Ideally the UHD would have complained that I was doing that! Ah well.
>
> Time to re-architecture some stuff! 
>
> Thank you,
> Andrew Fountain
> Black River Systems Co., Inc.
> 162 Genesee Street
> Utica, NY 13502
>
>
> --
> *From:* Brian Padalino 
> *Sent:* Tuesday, August 22, 2023 4:22 PM
> *To:* Andrew Fountain 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Re: UHD4 segmentation fault on creating
> rx_streamer
>
> You don't often get email from bpadal...@gmail.com. Learn why this is
> important 
> On Tue, Aug 22, 2023 at 4:16 PM Andrew Fountain via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Here is the output of that program with a debug build of UHD v4.4.0.0 . It
> seems to point out this line
> https://github.com/EttusResearch/uhd/blob/UHD-4.4/host/lib/rfnoc/rfnoc_graph.cpp#L393
> 
>
> It doesn't seem to be some weird threading issue related to getting
> multiple rx_streamers at the same time; adding a lock around that access to
> that get_rx_stream function still yields segmentation faults at the same
> point in get_rx_stream.
>
>
> Are you sure?
>
> Can you move the streamer creation to be outside of the for loop and just
> iterate on the stream args, issue command, and recv()?
>
> Brian
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: VCO can not operate for high sample rate

[Rob Kossler via USRP-users]

I think that you could implement this transmit waveform in a custom RFNoC
block such that you would never have any issue with underruns.  Although I
don't use gnuradio myself, I believe that you could control your block
easily from gnuradio.  And, although this requires some FPGA programming,
this would likely be a straightforward FPGA implementation.
Rob

On Wed, Aug 9, 2023 at 11:54 PM  wrote:

> Hi,
>
> TX/RX benchmark works well even up to 245.76MHz of sample rate with my
> USRPX410 (on 10GbE link).
>
> While USRPX410 receiver channel handle high sample rates even far more
> than 100Msps (245.76MHz), I am not able to transmit high sample rate
> triangular FMCW waveform with USRPX410 in GNU Radio (by employing VCO to
> generate chirp signal). It seems VCO (and VCO complex) are not able to
> generate FMCW signal in high sample rate more than 50Msps, and It issue
> several underrun errors. Is there any solution to overcome it.
>
> Or without using VCO, what are the other solutions to transmit triangular
> FMCW waveform through GNU Radio and USRPX410? Thank you.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: [EXT] Re: N310 correct choice for coherent 4 channel RX w/ 1 TX ?

[Rob Kossler via USRP-users]

Hi David,
You seem to already know the essentials based on the previous comments.

I have used each of the following USRPs in various 4-channel
coherent experiments. I'll mention a couple of comments about each.

   - The X310/UBX can be phase calibrated, but it can't operate with a
   shared LO
   - The X310/TwinRx can also be phase calibrated and it can operate with a
   shared LO, but there is no transmit channel
   - The N310 can be phase calibrated and can operate with an external
   shared LO but with the 180 deg ambiguity you mentioned.  However each
   "pair" of Rx or Tx share the same circuitry so they inherently share the
   same ambiguity. Thus, if channel 0 is +180 on this calibration, then
   channel 1 will also be +180.  The N310 can used shared LO as you mentioned
   with the 5GHz startup calibration but it does not operate above 4 GHz (ext
   LO at 8 GHz)
   - The N321 can share LO among all Tx and Rx channels (I have implemented
   16x16). In this configuration, it is easy to get the same phase calibration
   every time since the LO is shared. This is a great choice if you can
   tolerate the additional expense, size, and weight of two devices.

Depending on "just how coherent" you need to be affects whether you
want/need "shared LO".  If the LO is not shared, then each LO disciplines
to a common reference signal. This can provide a consistent average phase
offset among channels (as in the X310/UBX), but the instantaneous phase of
a given channel can deviate based on its individual phase locked loop
(PLL). All of the PLLs will keep the relative phase/frequency within a
tolerance, but it is not the same as a shared LO for which slight
deviations will be identical on every channel.
Rob


On Wed, Jul 26, 2023 at 5:30 PM Marcus D. Leech 
wrote:

> On 26/07/2023 17:17, David J Li wrote:
>
> Thanks for the suggestion, Marcus. The N320 and N321 are only both 2 TX/RX
> devices as far as I can tell, so to satisfy 4 RX, 1 TX it looks like I
> would need 2 devices. Do you happen to know if there is any official
> documentation on using the external LO for the N310 hidden somewhere on the
> Ettus wiki? The 5 GHz external LO initial input requirement doesn’t seem to
> be documented anywhere as far as I can tell.
>
> It is the case that there are some app-notes needed for the N310,
> including the "5GHz Lore" -- this requirement comes, from
>   what I understand, from the AD9371 data-sheet.
>
> There are folks on this list who have used the external LO on N310
> successfully, including (I believe, please correct me if I'm
>   wrong) Rob Kossler.
>
>
>
>
> *From:* Marcus D. Leech 
> 
> *Sent:* Wednesday, July 26, 2023 4:51 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [EXT] [USRP-users] Re: N310 correct choice for coherent 4
> channel RX w/ 1 TX ?
>
>
>
>
>
> ZjQcmQRYFpfptBannerEnd
>
> On 26/07/2023 16:47, David J Li wrote:
>
> Hi all,
>
>
>
> I’m currently using a USRP N310 for an application that requires coherent
> 4 channel RX w/ the ability to TX on 1 channel as well. In the past, I’ve
> used USRP X310s to do 4 channel coherent RX and found the calibration
> process for that to be relatively straight forward using the TwinRX cards.
> It was simply phase aligned input signals into each RX port and computing
> the constant phase offset between channels and just adjusting for that
> factor in my processing digitally.
>
>
>
> My understanding is that this is more complicated w/ the N310. The
> procedure as I understand is that during initialization the N310 external
> LO needs to be set at 5 GHz. After initialization, the external LO can be
> set to 2 times the desired center freq, but that there is still a 180 deg
> ambiguity between channels which would need to be figured out via
> calibration w/ a phase aligned input signal. Is this correct? Is there some
> way to shorten or optimize this procedure?
>
> The phase ambiguity arises from the 2XLO mixing in the RFIC chips, and
> there's no way around it.
>
> You might look at the N320/N321 family for multi-channel coherent TX/RX
> applications.
>
>
>
>
> Second question would be if the process is simpler on different USRP
> models akin to how the X310 w/ TwinRX cards work where you just need to
> compute some calibration values once at powerup and afterwards those values
> hold pretty true for a long time as long as your gain/center freq don’t
> change. Having the requirement of being able to TX on at least 1 channel
> prevents me from using an X310 w/ TwinRX cards.
>
>
>
> Thanks,
>
> -David
>
>
>
> ___
>
> USRP-users mailing list -- usrp-users@lists.ettus.com
>
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- 

[USRP-users] Re: LO carrier phase difference

[Rob Kossler via USRP-users]

On Thu, Jun 29, 2023 at 11:09 AM Marcus D. Leech
 wrote:
>
> On 29/06/2023 09:36, zhou via USRP-users wrote:
> I am using X310 USRPs. I did a loopback test with this USRP, that is, Tx was 
> connected to Rx (with a 20dB attenuator between them). This is for checking 
> the channel status.
> In my test, Tx is free running without stop, and Rx is occasional. Both 
> transmission and capture are time-based, that is, signals are transmitted at 
> specified time, and capture starts at specified time.
>
> Master clock rate: 184.32MHz
> Sampling rate: 184.32MHz
>
> Using the captured signals, I can calculate the channel coefficient. A few 
> captures were made.
>
> I expected constant channel because it was cable connection and it was in the 
> same USRP, but I found that the constellations of the pilot signals rotated 
> when comparing different captures. I think this can be caused by the phase 
> difference between Tx LO and Rx LO, but not sure.
>
> Questions:
> 1. are there independent LOs for Tx and Rx in a USRP?
>
> Yes.   In fact, in any realistic on-the-air scenario, your RX and TX will 
> never be phase aligned, or even phase-coherent.

Although there are separate LOs, they are both disciplined to the 10
MHz reference. If they are set using timed commands, they can provide
repeatable phase (at least for some daughterboards like UBX and SBX).
In radar applications, phase coherent Rx/Tx is common.

>
> 2. Is the Rx LO on and off in test, that is, it starts when capture starts 
> and stops when capture is completed? So, the LO phase offset between Tx and 
> Rx is random?
>
> I would expect the RX LO phase to random with respect to the TX every time 
> you start/stop the RX.

In the description above, you mentioned free-running Tx but you also
mentioned timed transmission and capture. If you are using timed Tx
and Rx along with the timed tuning commands, I would expect a
consistent phase offset (depending again on daughterboard).  If you
have free running Tx, then I would expect it to be random.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: TwinRx in coherent setup

[Rob Kossler via USRP-users]

Is there a chance that the issue is caused by the timed commands occurring
prior to the "set_rx_rate" command (as indicated in the code provided in
the issue tracker)?  I don't know how the DDC responds to timed commands
prior to knowing its output rate.
Rob

On Mon, Jun 26, 2023 at 11:22 AM Marcus D. Leech 
wrote:

> On 26/06/2023 11:12, Carlo Venier wrote:
>
> Good evening to everybody,
>
> I am trying to use an X300 with two TwinRX in a coherent setup.
> After synchronization, in the case of fixed frequency operation (no
> re-tuning) the phase differences among the channels are constant and
> they remain constant over time.
> However, if I re-tune the TwinRx on the exact same frequency, I expect
> that the phase differences remain the same, but it does not happen. How
> is it possible?
>
> The LO settings are the following:
>
> multi_usrp->set_rx_lo_export_enabled(true,
> uhd::usrp::multi_usrp::ALL_LOS, 0);
> multi_usrp->set_rx_lo_source("internal", uhd::usrp::multi_usrp::ALL_LOS,
> 0);
> multi_usrp->set_rx_lo_source("companion",
> uhd::usrp::multi_usrp::ALL_LOS, 1);
> multi_usrp->set_rx_lo_source("external", uhd::usrp::multi_usrp::ALL_LOS,
> 2);
> multi_usrp->set_rx_lo_source("external", uhd::usrp::multi_usrp::ALL_LOS,
> 3);
>
> Moreover, by using the timed command before tuning all the channels
> (code snippet at "https://files.ettus.com/manual/page_sync.html;, "Align
> LOs in the front-end"), I get into the issue at
> ("https://github.com/EttusResearch/uhd/issues/606;) and the X300 is not
> usable until a power-cycle.
> I get the same issues when using both the uhd3.15.0.0 and the uhd4.4.0.0.
>
> Hopefully this bug will get fixed.
>
> I think that without timed-tuning, even though you're sharing LOs, the DDC
> phase-accumulators will be
>   "ticking over" between the individual (untimed) tuning commands.  So
> there will be unpredictable phase
>   between all the channels.
>
>
> Should I expect the same phase differences when I re-tune to the exact
> same frequency or is it okay for the phase differences to change and I
> am missing something?
> Do you have any suggestion on how to solve the issue?
>
> Thanks,
>
> Best regards,
> Carlo Venier
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310 Dual 200 Msps Streaming

[Rob Kossler via USRP-users]

My own experience is that 200 S/s on two channels is very difficult to
achieve from the host. Separate streamers may help, but you will likely
need to move to DPDK to get the best performance. I have not tried DPDK
recently, but when I tried it a few years ago, the performance was
excellent, but it was not easy to get it working properly (and there were
some negative side effects that I never solved).  The "skip_ddc" and
"skip_duc" do not have any effect on FPGA images that are "statically
linked" between the Radio and DDC/DUC (which is likely all UHD 4 images).


On Tue, Jun 13, 2023 at 12:40 PM Marcus D. Leech 
wrote:

> On 12/06/2023 22:03, Aaron Smith wrote:
> > Hello All,
> >
> > I am trying to transmit on two UBX-160 daughterboards  within a single
> > X310 at 200 Msps using UHD 4.1.0.5-3.
> >
> > I am experiencing periodic underflows, and I have already applied all
> > of the tips in the "USRP Host Performance Tuning Tips and Tricks"
> > application note, with the exception of using DPDK.
> >
> > I have a few questions about UHD streaming and what can be done to
> > improve performance.
> >
> > 1. My current implementation uses a single tx_streamer for both
> > channels, and uses multiple threads to populate the buffers sent to
> > the X310. Would the performance be better if I used two separate
> > streamers, one for each channel, in separate threads?
> I don't think there's a closed-form answer to this.  Because it would
> depend on your particular system, application, etc.   I'd
>just do the experiment and see...
>
> >
> > 2. I have seen some claims that DPDK is not as useful with UHD 4, is
> > this true?
> I don't use DPDK myself, so I don't know if that's true or not.
>
> >
> > 3. With UHD 4, would it help to set the skip_duc and skip_ddc flags
> > with full rate streaming?
> Again, the answer here is susceptible to experiment...
>
> >
> > 4. Are underflows only created within the send() function? Or can the
> > timing of calls to send() cause underflows, especially when the burst
> > flags are used? For example, suppose I set the start of burst flag to
> > true for a single buffer containing 1 second of data, and then I
> > toggle the start of burst flag to false for subsequent buffers and
> > continuously call send() on 1 second buffers for 10 minutes. On the
> > last second I set end of burst flag to true. The idea is to create a
> > 10 minute long "burst." If I call send late on one of the one second
> > buffers in the middle of the "burst" will UHD report underflows? My
> > thinking is the X310 should think it is in the middle of a burst, and
> > will expect data, but send() has not been called, so there is no data
> > for the radio to read from the host, creating underflows. Perhaps I am
> > also misunderstanding the purpose of the burst flags, as they are not
> > well documented.
> >
> > Thanks for the help!
> > Armon
> >
> Underflows occur when the radio hardware underflows its FIFO, which in
> turn means the host isn't providing samples at
>the desired rate--the radio has no idea what your "send()" boundaries
> are, just that it isn't getting samples when it needs
>them.The data in the "send()" has to percolate through UHD,
> through the kernel IP stack (or DPDK stack) and its buffers, and
>then the hardware buffers.  Any information about exactly when you
> called "send()" is pretty invisible by the time it reaches
>the radio.
>
> The "burst" architecture is really intended for applications like TDD or
> half-duplex, where you need to let the radio know to
>not expect any more TX samples, so it can do things like switch
> antennas, etc.
>
>
> >
> >
> > ___
> > USRP-users mailing list -- usrp-users@lists.ettus.com
> > To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO Distribution

[Rob Kossler via USRP-users]

Hi Michael,
One calibration procedure could be that you simply add a digital phase
offset to your 2nd Tx channel until your oscilloscope traces line up to
your satisfaction.  It would be nice if the default FPGA image included a
simple Rx & Tx complex scalar for this exact purpose (inside the DDC &
DUC), but that does not exist (yet).  If you are using gnuradio, it should
be easy to insert a complex scalar multiplication that would allow you to
adjust the samples streaming to just one channel.  In any case, if the
signal on the oscilloscope lines up well over your desired bandwidth, then
you can declare "mission accomplished".  On the other hand, if your signal
lines up at one end of your frequency bandwidth but then diverges at the
other end, it likely means a delay mismatch that you could potentially
"calibrate" by adding an appropriate length of cable to one path (in cable,
1 ns delay is about 8 inches).
Rob

On Tue, Jun 13, 2023 at 1:51 PM Michael Toussaint 
wrote:

> Hi Marcus,
>
> Yes, the cables are identical, we also experimented with Phase stable test
> cables but did not see any improvement. We understand there will be some
> residual phase errors, but the RF coming out with a 2.64ns delta or ~135
> degree phase shift @ 144MHz seems like more than that. Is that level of
> offset to be expected, if so is there a procedure to calibrate that out to
> align the RF?
>
> Understand that the phase drift measurements are the change over time. Do
> you know if Measured Performance results, from
> https://kb.ettus.com/USRP_N320/N321_LO_Distribution, where generated on
> Rx channels (e.g. by injecting a tone to a N321 and a N320 and measuring
> the phase difference of the IQ over time) or on Tx channels (e.g. N321 and
> N320 transmitting a tone and using some type of test equipment to
> measure the phase offset of the RF over time) or is there some other way?
> I'd just like to repeat the process to see if I can repeat the results or
> see if there is something I am doing wrong.
>
> Thanks,
>
> Michael Toussaint
>
>
> On Thu, Jun 8, 2023 at 6:53 PM Marcus D. Leech 
> wrote:
>
>> On 08/06/2023 21:41, Michael Toussaint wrote:
>>
>> Hi Rob,
>>
>> Yes, 0.57 degrees is definitely within my measurement error. But,
>> shouldn't the N321 synchronize the phase of the LO's too?
>>
>> If you're sharing LOs, there's no "synchronizing the LOs".  A single LO
>> is shared through a switching matrix to each of the
>>   relevant mixers.  There'll be some residual phase-error, since
>> effective path-length will never be precisely matched--even
>>   with careful board layout, internal temperature differentials and batch
>> differences in electronic components in the switching
>>   matrix, and even the mixers involved, will yield (usually small) mutual
>> phase errors.
>>
>> Presumably the length of your LO-sharing cables are all the same, of the
>> same type, and from the same manufacturer
>>   (and, preferrably, from the same cable batch).
>>
>>
>>
>>
>> Is there documentation available of how to repeat the results in the
>> "Measured Performance" section of
>> https://kb.ettus.com/USRP_N320/N321_LO_Distribution (e.g. code examples
>> and or test setup to measure the phase drift)? It shows less than 0.1
>> degree of phase error, I'd like to just repeat that test to confirm
>> everything is working correctly, and see what might be causing the deltas.
>>
>> Note that phase-drift measurements measure the *change* in relative phase
>> between channels over time.  Not, I think, the
>>   absolute phase-offset between channels.  In a shared-LO setup (ignoring
>> any bugs or mis-configurations of the DUCs, etc), the
>>   absolute phase-offset between channels is repeatable and (largely)
>> static.  Dominated by physical processes like temperature
>>   drift and (worse) differential temperature drift in analog components
>> like cables, circuit-board traces, component temperatures,
>>   etc.
>>
>>
>>
>> Thanks,
>>
>> Michael
>>
>>
>> On Wed, Jun 7, 2023 at 12:22 PM Rob Kossler  wrote:
>>
>>> Hi Michael,
>>> I don't have any ideas for reducing a time delay offset. But, I still
>>> wonder if the problem could actually be just a phase offset.
>>>
>>> With a relative delay of 2.5ns and a bandwidth of 4 MHz, the amount of
>>> phase variation you would see is 0.57 degrees.  That is not easy to see.
>>> On the other hand, if your bandwidth increased to 200 MHz, you would see
>>> phase variation of 28.6 degrees (if the delay offset is 2.5 ns).
>>> Rob
>>>
>>>
>>> On Tue, Jun 6, 2023 at 9:38 PM Michael Toussaint <
>>> mtoussa...@chaosinc.com> wrote:
>>>
 Hi Rob,

 The signal is actually sweeping over 4MHz, but is just super zoomed
 into a small piece to show the time delta so it looks CW. The time
 difference appears to be the same (within my ability to measure) across the
 band so I am assuming it is a time delay offset.

 Any suggestions on how to reduce this time delay offset?

 Thanks,

 

[USRP-users] Re: x410 TX issues

[Rob Kossler via USRP-users]

Hi Joe,
It sounds like your custom image is compatible with the Ettus example
"rfnoc_replay_samples_from_file".  Have you tried this with your custom
image (as opposed to your custom software)?
Rob

On Wed, Jun 7, 2023 at 10:23 AM  wrote:

> Hello,
>
> I did run the default image and everything worked fine. I pasted my YML
> file below. Currently, the software I wrote builds a graph between the
> replay block and the radio block, I don’t want anything else. I do have a
> custom block, but I do not need it for transmit. I tested it on the default
> image(even though what I wrote does not call for a DUC) and it still worked
> fine.
>
>
> # General parameters
>
> # -
>
> schema: rfnoc_imagebuilder_args # Identifier for the schema used to
> validate this file
>
> copyright: >- # Copyright information used in file headers
>
> Ettus Research, A National Instruments Brand
>
> license: >- # License information used in file headers
>
> SPDX-License-Identifier: LGPL-3.0-or-later
>
> version: '1.0' # File version
>
> chdr_width: 64 # Bit width of the CHDR bus for this image
>
> device: 'x410' # USRP type
>
> image_core_name: 'x410_200_Trigger' # Name to use for the RFNoC Image Core
> files
>
> default_target: 'X410_X4_200' # Default make target
>
> # A list of all stream endpoints in design
>
> # 
>
> stream_endpoints:
>
> ep0: # Stream endpoint name
>
> ctrl: True # Endpoint passes control traffic
>
> data: True # Endpoint passes data traffic
>
> buff_size_bytes: 262144 # Ingress buffer size for data
>
> ep1:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 262144
>
> ep2:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 262144
>
> ep3:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 262144
>
> ep4:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 32768
>
> ep5:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 32768
>
> ep6:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 32768
>
> ep7:
>
> ctrl: False
>
> data: True
>
> buff_size_bytes: 32768
>
> # A list of all NoC blocks in design
>
> # --
>
> noc_blocks:
>
> radio0:
>
> block_desc: 'radio.yml'
>
> parameters:
>
> NUM_PORTS: 2
>
> NIPC: RADIO_NIPC
>
> radio1:
>
> block_desc: 'radio.yml'
>
> parameters:
>
> NUM_PORTS: 2
>
> NIPC: RADIO_NIPC
>
> replay0:
>
> block_desc: 'replay.yml'
>
> parameters:
>
> NUM_PORTS: 2
>
> MEM_DATA_W: 128
>
> MEM_ADDR_W: 32
>
> trigger0:
>
> block_desc: 'trigger.yml'
>
> parameters:
>
> NUM_PORTS: 1
>
> trigger1:
>
> block_desc: 'trigger.yml'
>
> parameters:
>
> NUM_PORTS: 1
>
> # A list of all static connections in design
>
> # --
>
> # Format: A list of connection maps (list of key-value pairs) with the
> following keys
>
> # - srcblk = Source block to connect
>
> # - srcport = Port on the source block to connect
>
> # - dstblk = Destination block to connect
>
> # - dstport = Port on the destination block to connect
>
> connections:
>
> #
>
> # RF A:0 TX
>
> - { srcblk: ep0, srcport: out0, dstblk: radio0, dstport: in_0 }
>
> # RF A:0 RX
>
> - { srcblk: radio0, srcport: out_0, dstblk: ep0, dstport: in0 }
>
> # RF A:1 TX
>
> - { srcblk: ep1, srcport: out0, dstblk: radio0, dstport: in_1 }
>
> # RF A:1 RX
>
> - { srcblk: radio0, srcport: out_1, dstblk: ep1, dstport: in0 }
>
> #
>
> # RF B:0 TX
>
> - { srcblk: ep2, srcport: out0, dstblk: radio1, dstport: in_0 }
>
> # RF B:0 RX
>
> - { srcblk: radio1, srcport: out_0, dstblk: ep2, dstport: in0 }
>
> # RF B:1 TX
>
> - { srcblk: ep3, srcport: out0, dstblk: radio1, dstport: in_1 }
>
> # RF B:1 RX
>
> - { srcblk: radio1, srcport: out_1, dstblk: ep3, dstport: in0 }
>
> #
>
> # Replay Connections
>
> - { srcblk: ep4, srcport: out0, dstblk: replay0, dstport: in_0 }
>
> - { srcblk: replay0, srcport: out_0, dstblk: ep4, dstport: in0 }
>
> - { srcblk: ep5, srcport: out0, dstblk: replay0, dstport: in_1 }
>
> - { srcblk: replay0, srcport: out_1, dstblk: ep5, dstport: in0 }
>
> #
>
> #trigger Connections
>
> - { srcblk: ep6, srcport: out0, dstblk: trigger0, dstport: in_0 }
>
> - { srcblk: trigger0, srcport: out_0, dstblk: ep6, dstport: in0 }
>
> - { srcblk: ep7, srcport: out0, dstblk: trigger1, dstport: in_0 }
>
> - { srcblk: trigger1, srcport: out_0, dstblk: ep7, dstport: in0 }
>
> # BSP Connections
>
> - { srcblk: radio0, srcport: ctrlport, dstblk: _device_, dstport:
> ctrlport_radio0 }
>
> - { srcblk: radio1, srcport: ctrlport, dstblk: _device_, dstport:
> ctrlport_radio1 }
>
> - { srcblk: _device_, srcport: radio0, dstblk: radio0, dstport: radio }
>
> - { srcblk: _device_, srcport: radio1, dstblk: radio1, dstport: radio }
>
> - { srcblk: _device_, srcport: time, dstblk: radio0, dstport: time }
>
> - { srcblk: _device_, srcport: time, dstblk: radio1, dstport: time }
>
> - { srcblk: replay0, srcport: axi_ram, dstblk: _device_, dstport: dram }
>
> # A list of all clock domain connections in design
>
> # 

[USRP-users] Re: N321 LO Distribution

[Rob Kossler via USRP-users]

Hi Michael,
I don't have any ideas for reducing a time delay offset. But, I still
wonder if the problem could actually be just a phase offset.

With a relative delay of 2.5ns and a bandwidth of 4 MHz, the amount of
phase variation you would see is 0.57 degrees.  That is not easy to see.
On the other hand, if your bandwidth increased to 200 MHz, you would see
phase variation of 28.6 degrees (if the delay offset is 2.5 ns).
Rob


On Tue, Jun 6, 2023 at 9:38 PM Michael Toussaint 
wrote:

> Hi Rob,
>
> The signal is actually sweeping over 4MHz, but is just super zoomed into a
> small piece to show the time delta so it looks CW. The time difference
> appears to be the same (within my ability to measure) across the band so I
> am assuming it is a time delay offset.
>
> Any suggestions on how to reduce this time delay offset?
>
> Thanks,
>
> Michael Toussaint
>
>
> On Mon, Jun 5, 2023 at 8:51 PM Rob Kossler  wrote:
>
>> Hi Michael,
>> Either a delay offset OR a phase offset will show itself as a relative
>> phase.  In order to distinguish between a delay offset and a phase offset,
>> your signal must have appreciable bandwidth.  It appears that your signal
>> is CW.  It is entirely possible that your delay offset is zero.  Does this
>> make sense?
>> Rob
>>
>> On Mon, Jun 5, 2023 at 5:32 PM Michael Toussaint 
>> wrote:
>>
>>> Could you share how you're setting up LO sharing in your code, as well
>>> as how you're setting the system clock on the N321?
>>>
>>> The functions "configure_channels" and "set_lo_hw_exports" are used to
>>> set up the LO sharing.
>>>
>>> The functions "sync_sources" and "sync_all_devices" are used to set up
>>> the system clock on the N321.
>>>
>>> How do you measure the relative delay?
>>>
>>> We are measuring the offset of the LO's by just measuring the phase
>>> difference of the RF coming out of the Ettus with an Oscilloscope (picture
>>> attached as
>>> Scope_Trace_SingleStream_LO.png
>>>
>>> ).
>>> Yellow is Channel 1, Green is Channel 2; using a single streamer we still
>>> appear to have a 2.64ns delta or ~135 degree phase shift.
>>>
>>> Thanks Marcus and Rob for your assistance.
>>>
>>> Michael Toussaint
>>>
>>> def sync_sources(usrp):
>>> logging.info('Setting Sync Sources')
>>>
>>> usrp.set_sync_source(clock_source = 'gpsdo',
>>>  time_source = 'gpsdo')
>>>
>>> def sync_all_devices(hw_info):
>>> logging.info('Syncing All Devices')
>>>
>>> mb_with_gps_locked = -1
>>>
>>> while 1:
>>> time.sleep(1.0)
>>>
>>> all_ref_locked = True
>>>
>>> for board in range(hw_info.usrp.get_num_mboards()):
>>> all_ref_locked = all_ref_locked and \
>>> hw_info.usrp.get_mboard_sensor('ref_locked',
>>>board).to_bool()
>>>
>>> if (mb_with_gps_locked == -1) and \
>>> hw_info.usrp.get_mboard_sensor('gps_locked',
>>>board).to_bool():
>>> mb_with_gps_locked = board
>>>
>>> if all_ref_locked:
>>> logging.info('All Devices are REF locked')
>>> break
>>>
>>> logging.info('GPS Locked on MB #%d', mb_with_gps_locked)
>>>
>>> time.sleep(1.0)
>>> hw_info.usrp.set_time_next_pps(
>>> uhd.types.TimeSpec(
>>> hw_info.usrp.get_mboard_sensor('gps_time',
>>>mb_with_gps_locked).to_int() +
>>>1.0)
>>> )
>>> time.sleep(1.0)
>>>
>>>
>>> def configure_channels(usrp, rf_type, hw_info):
>>> rf_channel_index = None
>>> set_rf_rate = None
>>> set_rf_freq = None
>>> set_rf_gain = None
>>> set_rf_lo_source = None
>>> get_rf_lo_source = None
>>> get_rf_lo_freq = None
>>> get_rf_lo_freq_range = None
>>>
>>> if (rf_type == 'rx'):
>>> if (len(hw_info.rx_channel_index) > 0):
>>> rf_channel_index = hw_info.rx_channel_index
>>> set_rf_rate = usrp.set_rx_rate
>>> set_rf_freq = usrp.set_rx_freq
>>> set_rf_gain = usrp.set_rx_gain
>>> set_rf_lo_source = usrp.set_rx_lo_source
>>> get_rf_lo_source = usrp.get_rx_lo_source
>>> get_rf_lo_freq = usrp.get_rx_lo_freq
>>> get_rf_lo_freq_range = usrp.get_rx_lo_freq_range
>>> else:
>>> return
>>> elif (rf_type == 'tx'):
>>> if (len(hw_info.tx_channel_index) > 0):
>>> rf_channel_index = hw_info.tx_channel_index
>>> set_rf_rate = usrp.set_tx_rate
>>> set_rf_freq = usrp.set_tx_freq
>>> set_rf_gain = usrp.set_tx_gain
>>> set_rf_lo_source = usrp.set_tx_lo_source
>>> get_rf_lo_source = usrp.get_tx_lo_source
>>> get_rf_lo_freq = usrp.get_tx_lo_freq
>>> 

[USRP-users] Re: N321 LO Distribution

[Rob Kossler via USRP-users]

Hi Michael,
Either a delay offset OR a phase offset will show itself as a relative
phase.  In order to distinguish between a delay offset and a phase offset,
your signal must have appreciable bandwidth.  It appears that your signal
is CW.  It is entirely possible that your delay offset is zero.  Does this
make sense?
Rob

On Mon, Jun 5, 2023 at 5:32 PM Michael Toussaint 
wrote:

> Could you share how you're setting up LO sharing in your code, as well as
> how you're setting the system clock on the N321?
>
> The functions "configure_channels" and "set_lo_hw_exports" are used to
> set up the LO sharing.
>
> The functions "sync_sources" and "sync_all_devices" are used to set up
> the system clock on the N321.
>
> How do you measure the relative delay?
>
> We are measuring the offset of the LO's by just measuring the phase
> difference of the RF coming out of the Ettus with an Oscilloscope (picture
> attached as
> Scope_Trace_SingleStream_LO.png
>
> ).
> Yellow is Channel 1, Green is Channel 2; using a single streamer we still
> appear to have a 2.64ns delta or ~135 degree phase shift.
>
> Thanks Marcus and Rob for your assistance.
>
> Michael Toussaint
>
> def sync_sources(usrp):
> logging.info('Setting Sync Sources')
>
> usrp.set_sync_source(clock_source = 'gpsdo',
>  time_source = 'gpsdo')
>
> def sync_all_devices(hw_info):
> logging.info('Syncing All Devices')
>
> mb_with_gps_locked = -1
>
> while 1:
> time.sleep(1.0)
>
> all_ref_locked = True
>
> for board in range(hw_info.usrp.get_num_mboards()):
> all_ref_locked = all_ref_locked and \
> hw_info.usrp.get_mboard_sensor('ref_locked',
>board).to_bool()
>
> if (mb_with_gps_locked == -1) and \
> hw_info.usrp.get_mboard_sensor('gps_locked',
>board).to_bool():
> mb_with_gps_locked = board
>
> if all_ref_locked:
> logging.info('All Devices are REF locked')
> break
>
> logging.info('GPS Locked on MB #%d', mb_with_gps_locked)
>
> time.sleep(1.0)
> hw_info.usrp.set_time_next_pps(
> uhd.types.TimeSpec(
> hw_info.usrp.get_mboard_sensor('gps_time',
>mb_with_gps_locked).to_int() +
>1.0)
> )
> time.sleep(1.0)
>
>
> def configure_channels(usrp, rf_type, hw_info):
> rf_channel_index = None
> set_rf_rate = None
> set_rf_freq = None
> set_rf_gain = None
> set_rf_lo_source = None
> get_rf_lo_source = None
> get_rf_lo_freq = None
> get_rf_lo_freq_range = None
>
> if (rf_type == 'rx'):
> if (len(hw_info.rx_channel_index) > 0):
> rf_channel_index = hw_info.rx_channel_index
> set_rf_rate = usrp.set_rx_rate
> set_rf_freq = usrp.set_rx_freq
> set_rf_gain = usrp.set_rx_gain
> set_rf_lo_source = usrp.set_rx_lo_source
> get_rf_lo_source = usrp.get_rx_lo_source
> get_rf_lo_freq = usrp.get_rx_lo_freq
> get_rf_lo_freq_range = usrp.get_rx_lo_freq_range
> else:
> return
> elif (rf_type == 'tx'):
> if (len(hw_info.tx_channel_index) > 0):
> rf_channel_index = hw_info.tx_channel_index
> set_rf_rate = usrp.set_tx_rate
> set_rf_freq = usrp.set_tx_freq
> set_rf_gain = usrp.set_tx_gain
> set_rf_lo_source = usrp.set_tx_lo_source
> get_rf_lo_source = usrp.get_tx_lo_source
> get_rf_lo_freq = usrp.get_tx_lo_freq
> get_rf_lo_freq_range = usrp.get_tx_lo_freq_range
> else:
> return
>
> logging.info('Configuring %s Channels', rf_type.upper())
>
> for rf_ch_name, rf_ch_index in rf_channel_index.items():
> logging.info('Configuring %s channel %s (channel #%d)',
>  rf_type.upper(), rf_ch_name, rf_ch_index)
>
> ch_def = hw_info.channel_def[rf_ch_name]
>
> # LO Channel Setup
> current_lo_name = 'unknown'
> current_lo_src = 'unknown'
>
> if ch_def.lo_inputs is not None:
> logging.info('  Setting %s LO for Channel %s (#%d)',
>  rf_type.upper(), rf_ch_name, rf_ch_index)
>
> set_rf_lo_source(ch_def.lo_inputs.source,
>  ch_def.lo_inputs.name,
>  rf_ch_index)
> current_lo_name = ch_def.lo_inputs.name
>
> logging.info('(#%d) Requested %s LO name %s, src %s',
>  rf_ch_index,
>  rf_type.upper(),
>  ch_def.lo_inputs.name,
>  ch_def.lo_inputs.source)
> 

[USRP-users] Re: N321 LO Distribution

[Rob Kossler via USRP-users]

On Thu, May 25, 2023 at 3:54 AM Michael Toussaint
 wrote:
>
> Used a single streamer and saw the delay slightly improve to between 2.5 - 3 
> ns.
>
> Any other suggestions to improve the delay to match the results from the 
> knowledge base, https://kb.ettus.com/USRP_N320/N321_LO_Distribution?

How do you measure the relative delay?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N320 - GPIO ATR output to TX output delay

[Rob Kossler via USRP-users]

I may be off-base here, but I thought that the GPIO control occurred from
the Radio block such that a DUC group delay would not be the place to look.
I am wondering if the GPIO control does not use timed commands.  Instead of
the automatic setting of the Tx GPIO, we have used custom GPIO with timed
commands to pulse a GPIO bit as a trigger at the same time as we begin the
radios.  But, I have not checked the relative timing between my GPIO pulse
and the RF because I was only interested in repeatability rather than
knowing the precise relative timing.


On Thu, May 25, 2023 at 4:55 AM Leon Wabeke  wrote:

> Hi
>
>
>
> We have also used a “measure in the lab approach”, together with zero
> padding before and after and have at times seen these need to be adjusted
> after a UHD upgrade.
>
>
>
> We have also in some cases taken the GPIO strobe via another FPGA to
> adjust the strobe by adding an extra configurable delays on rising and
> falling edges. It is just annoying to use an external function to do this
> and it would in my opinion be a very useful feature if such configurable
> delays were part of the basic built-in GPIO functionality at least in terms
> of the “automatic strobe state machine”, thus not requiring another FPGA or
> having to try to integrate custom logic inside the UHD firmware, which
> might need to be reintegrated on subsequent updates.
>
>
>
> Thanks
>
> Leon
>
>
>
> *From: *Marcus D. Leech 
> *Date: *Wednesday, 24 May 2023 at 23:14
> *To: *usrp-users@lists.ettus.com 
> *Subject: *[USRP-users] Re: N320 - GPIO ATR output to TX output delay
>
> [The e-mail server of the sender could not be verified (SPF Record)]
>
> On 24/05/2023 16:22, m...@chaosinc.com wrote:
>
> Thanks. Two follow up questions:
>
>1. For a given sample rate, is there a way to deterministically
>calculate the group delay?
>
> Look at the filter code in the version of the FPGA image that you're
> using, determine which filter bits and
>   pieces are "in circuit" when you select your sample-rate, and calculate
> the group delay from that.
>
>   Many folks who have run into the same problem have used a "measure it in
> the lab" approach, and done
>   that for new releases of the FPGA code--the R team does occasionally
> make changes to the filter
>   parameters and "doctrine" in order to optimize for certain types of
> applications.  This may well
>   de-optimize for others.  SDRs are general-purpose devices, which means
> that there will be cases where they
>   aren't "out of the factory" optimized for any *particular* application.
>
> The approach some have take is to pad at one end or the other (or both) to
> account for these delays, which comprise
>   a deterministic-but-version-dependent component, and an analog component
> that is less deterministic, but at much
>   smaller times scales.
>
>
>
>
>1. Why do I not see the same delay at the back end of the transmission
>(i.e. after the GPIO goes low)?
>
> My suspicion is that part of what you're seeing is an analog switching
> effect, and things like turn-on/turn-off
>   times are not perfectly symmetric.
>
> This issue (lack of tight synchronization between ATR signals and actual
> waveforms appearing at the antenna) has been
>   an issue in digital comms since I got involved in the 1980s, albeit, in
> the 1980s, the time-scales were much larger.
>   You simply had to account for these effects for every new radio your
> application encountered.   In the DSP age, the
>   effects are at much smaller time-scales, but so are the data rates.
>
>
>
>
>
> ___
>
> USRP-users mailing list -- usrp-users@lists.ettus.com
>
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO Distribution

[Rob Kossler via USRP-users]

On Tue, May 16, 2023 at 8:35 PM Marcus D. Leech  wrote:
>
> On 16/05/2023 20:31, Michael Toussaint wrote:
> > Hi,
> >
> > I am testing the LO synching on a single N321 using the 2 Tx channels
> > on the N321.
> >
> > I have followed the LO setup steps from the knowledge base,
> > https://kb.ettus.com/USRP_N320/N321_LO_Distribution, to distribute the
> > LO. (Sample Python code used for setup below)
> >
> > I am using separate streamers for each Tx channel and noticing a delay
> > between the 2 channels executing.
> Yeah, using separate streamers, the code doesn't attempt synchronization
> across two streamers.  You'll need a single
>two-channel streamer--that's the "synchronization paradigm" that has
> been in UHD for over a decade...

Separate streamers shouldn't be a problem. I use them regularly in
synchronized mode.  If both streamers have the same time spec, the
radio should start them both in sync. That said, it won't hurt to test
with a single streamer.

> > The Tx channels do not appear to be synchronized, we're measuring
> > anywhere from 0.5ns to 4ns of delay across the channels.

The master clock cycle on the N321 is between 4 and 5 ns.  This is
also the D/A (and A/D) clock cycle.  When you are seeing a relative
delay of 0.5ns this is about one tenth of a D/A sample interval.  Or,
from another perspective, this represents a difference of about 4
inches of cable length (if the relative delay had an analog cause).
So, the channels are definitely synchronized to some degree - I don't
have a guess at why the synchronization is not tighter.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Manage multiple Tx streamers

[Rob Kossler via USRP-users]

By the way, the rx_samples_to_file.cpp example has a "multi_streamer"
command line option and the example has associated functionality to
implement separate streamers in the Rx direction. But, I don't think the tx
examples have this option although it should be roughly analogous to the Rx
case.
Rob

On Fri, May 12, 2023 at 12:03 PM Rob Kossler  wrote:

> Hi David,
> You need to create two streamers - one with a channel list of {0} and the
> other with a channel list of {1}.  Let me know if you have any questions.
> Rob
>
> On Fri, May 12, 2023 at 11:52 AM  wrote:
>
>> Hi everyone,
>>
>> I need to develop a system which streams independent samples at different
>> moments to the differents channels (channel 0 and channel 1) of an USRP
>> X310.
>>
>> To achieve that, I use the example codes available in the documentation
>> which look like the following :
>>
>> // 1. Create the stream args object and initialize the data formats to
>> fc32 and sc16:
>> uhd::stream_args_t stream_args("fc32", "sc16");
>> // 2. Set the channel list, we want 2 streamers coming from channels 0
>> and 1, in that order
>> stream_args.channels = {0, 1};
>> // Now use these args to create a tx streamer (We assume that usrp is a
>> valid uhd::usrp::multi_usrp)
>> uhd::tx_streamer::sptr tx_stream = usrp->get_tx_stream(stream_args);
>> // Now, any calls to rx_stream must provide a vector of 2 buffers, one
>> per channel.
>> // Ex: tx_stream->send(buffs, 1024, md); (assuming buffs is a vector of 2
>> buffers)
>>
>> Then, I have created 2 threads, each thread will call the
>> “tx_stream->send” function at different moments to stream samples through
>> its corresponding channel (thread0 ==> channel0 and thread1 ==> channel1).
>>
>> My question is : how can I call the “tx_stream->send” function in each
>> thread to send samples through only 1 of the channels ? Is there any other
>> better method to achieve that ?
>>
>> Thank you very much for your support.
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Manage multiple Tx streamers

[Rob Kossler via USRP-users]

Hi David,
You need to create two streamers - one with a channel list of {0} and the
other with a channel list of {1}.  Let me know if you have any questions.
Rob

On Fri, May 12, 2023 at 11:52 AM  wrote:

> Hi everyone,
>
> I need to develop a system which streams independent samples at different
> moments to the differents channels (channel 0 and channel 1) of an USRP
> X310.
>
> To achieve that, I use the example codes available in the documentation
> which look like the following :
>
> // 1. Create the stream args object and initialize the data formats to
> fc32 and sc16:
> uhd::stream_args_t stream_args("fc32", "sc16");
> // 2. Set the channel list, we want 2 streamers coming from channels 0 and
> 1, in that order
> stream_args.channels = {0, 1};
> // Now use these args to create a tx streamer (We assume that usrp is a
> valid uhd::usrp::multi_usrp)
> uhd::tx_streamer::sptr tx_stream = usrp->get_tx_stream(stream_args);
> // Now, any calls to rx_stream must provide a vector of 2 buffers, one per
> channel.
> // Ex: tx_stream->send(buffs, 1024, md); (assuming buffs is a vector of 2
> buffers)
>
> Then, I have created 2 threads, each thread will call the
> “tx_stream->send” function at different moments to stream samples through
> its corresponding channel (thread0 ==> channel0 and thread1 ==> channel1).
>
> My question is : how can I call the “tx_stream->send” function in each
> thread to send samples through only 1 of the channels ? Is there any other
> better method to achieve that ?
>
> Thank you very much for your support.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNOC Block Not found

[Rob Kossler via USRP-users]

Hi Joe,
It sounds like you wrote a block controller.  If not then this will need to
be done.  If so, then it is likely UHD is just not loading your block
controller (assuming it is compiled OOT).  If you set UHD_MODULE_PATH env
var to point to your dynamic library, then UHD will find it (but you will
want only this file in that folder because it will try to load every file
as a library).  Or, you can link to your library when you link your custom
app. Let me know if this doesn't make sense.
Rob

On Wed, May 3, 2023 at 4:23 PM Brian Padalino  wrote:

> Mistype:
>
>   uhd_usrp_probe --interactive-reg-iface 0/Block#0
>
> ... also assuming 0/Block#0 and 0/Block#1 are the same and your own custom
> blocks.
>
> Unsure if this assumption is correct.
>
> Brian
>
> On Wed, May 3, 2023 at 4:21 PM Brian Padalino  wrote:
>
>> Try doing:
>>
>>   uhd_usrp_probe --interactive-ref-iface 0/Block#0
>>
>> And inside there, try:
>>
>>   peek32 0
>>
>> What does it print out?  Does it match your NOC_ID in your controller?
>>
>> Brian
>>
>> On Wed, May 3, 2023 at 4:03 PM  wrote:
>>
>>> This is the output of uhd_usrp_probe
>>>
>>>
>>> /
>>>
>>> | Device: N300-Series Device
>>>
>>> | _
>>>
>>> | /
>>>
>>> | | Mboard: ni-n3xx-3255102
>>>
>>> | | dboard_0_pid: 338
>>>
>>> | | dboard_0_serial: 3252A17
>>>
>>> | | dboard_1_pid: 338
>>>
>>> | | dboard_1_serial: 3252A18
>>>
>>> | | eeprom_version: 3
>>>
>>> | | fs_version: 20230131233809
>>>
>>> | | mender_artifact: v4.4.0.0_n3xx
>>>
>>> | | mpm_sw_version: 4.4.0.0-g5fac246b
>>>
>>> | | pid: 16962
>>>
>>> | | product: n320
>>>
>>> | | rev: 10
>>>
>>> | | rpc_connection: remote
>>>
>>> | | serial: 3255102
>>>
>>> | | type: n3xx
>>>
>>> | | MPM Version: 4.4
>>>
>>> | | FPGA Version: 8.1
>>>
>>> | | FPGA git hash: 5fac246.dirty
>>>
>>> | | RFNoC capable: Yes
>>>
>>> | |
>>>
>>> | | Time sources: internal, external, gpsdo, sfp0
>>>
>>> | | Clock sources: external, internal, gpsdo
>>>
>>> | | Sensors: ref_locked, gps_locked, temp, fan, gps_gpgga, gps_sky,
>>> gps_time, gps_tpv
>>>
>>> | _
>>>
>>> | /
>>>
>>> | | RFNoC blocks on this device:
>>>
>>> | |
>>>
>>> | | * 0/Block#0
>>>
>>> | | * 0/Block#1
>>>
>>> | | * 0/Radio#0
>>>
>>> | | * 0/Radio#1
>>>
>>> | | * 0/Replay#0
>>>
>>> | 
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Using PPS/TrigIn to collect bursts of samples in C++ UHD

[Rob Kossler via USRP-users]

Hi Joe,
I don't think it's possible (without some FPGA mods) to start
receiver sampling on the pulse rising edge.  However, the following
alternate methods are possible.

   - Connect your trigger signal to PPS input. Use continuous recording
   where your c++ just throws away all samples except the ones you want. Use
   the "get_time_last_pps" function in conjunction with the rx metadata time
   tag to know which samples to keep / discard
   - If your experiment allowed you to change the synchronization concept
   such that the N321 was the device generating the sync pulse (rather than
   receiving it), it is pretty straightforward to output a GPIO pulse at the
   same time the Rx starts
   - Connect your trigger signal to PPS input.  Poll "get_time_last_pps"
   until it changes.  Initiate a "future" rx collection with enough latency to
   account for the software-in-the-loop (e.g., 1 ms?).  This would cause the
   Rx to start with an exact latency relative to the PPS rising edge, but it
   would require a hefty latency (such as 1 ms) to account for the
   non-deterministic software commands.

And, it should be possible to make FPGA mods to do exactly what you want.
But, that would require your block to access the GPIO which I have never
done and so I don't know the details.  The bullets above can be done
without mods.
Rob

On Fri, Apr 28, 2023 at 12:12 PM  wrote:

> Hello,
>
>
> I have an application where I collect timed bursts of samples every period
> of time for an amount of time. For example, Every millisecond, collect
> samples for 100 microseconds.
>
> I’ve used GPIO and other synchronization methods successfully before, but
> I am wondering if its possible using the PPS on the ettus n321, where a
> square wave with period 1 ms is passed rather than 1 second, then using
> timed commands in C++ to carry out the burst collection on every rising
> edge of the square wave.
>
>
> Thanks
>
> Joe
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: configuring X410 USRP to work with higher sampling frequency/band width

[Rob Kossler via USRP-users]

On Tue, Apr 25, 2023 at 12:34 PM Marcus D. Leech
 wrote:
>
> On 25/04/2023 12:30, James Schatzman wrote:
> > I don't know if this is new information but we have observed some
> > additional behaviors:
> >
> > 1) The radio reports dropped UDP packets. Why is it dropping them?
> How are you determining this?  For streaming, the Linux in the Zynq is
> entirely out of the picture.

My understanding is that dropped packets in UHD mean that the
receiving entity received consecutive packets that did not have
consecutive indices.  So, if the FPGA detected such a condition, it
would send an appropriate error message back to UHD which would
produce the "D" or "S".  For Underruns, it would be the Radio block
that sends the error message back to UHD.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Trouble recieving data from antenna

[Rob Kossler via USRP-users]

Could there be an issue with packet lengths?  Does the "spp" from the radio
need to match the "N" from the keep_one_in_N? I'm not sure one way or the
other or whether the answer depends on the setting of "packet_mode /
sample_mode".

Which device are you using?
Rob

On Wed, Apr 19, 2023 at 4:16 PM  wrote:

> I have noticed after further troubleshooting that my antenna light
> actually appears to blink periodically. And I also seem to be getting
> overflow errors, even though my data rate is quite small(~5e6 samples per
> second, 32bits/sample, over ethernet).
>
> When I use the same data rate with the default image, I get a solid green
> light on the antenna, and no overflow message in the metadata.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Trouble recieving data from antenna

[Rob Kossler via USRP-users]

Hi Joe,
One thought is that the Rx Radio may never be getting the command to start
streaming.  Normally, this occurs by calling
rx_streamer->issue_stream_cmd() which propagates from the rx_streamer block
controller to the DDC block controller and ultimately to the Rx Radio block
controller.  If your custom block is in between and if your custom block
controller does not properly propagate this command, it will never arrive
at the Rx Radio.  But, this may not make sense in your case because I would
expect you would be receiving no data at all.

Another thought regarding troubleshooting of custom blocks is that if it is
possible to "dynamically link" your block using streaming end points for
the FPGA build, then you can configure a troubleshooting graph that is
essentially tx_streamer->your_custom_block->rx_streamer so that you can
verify that your block is behaving correctly.

How are you talking to your custom image?  C++/UHD?  gnuradio?

Rob

On Tue, Apr 18, 2023 at 5:06 PM  wrote:

> Hello,
>
> I have currently using my own custom RFNOC image. It appears that samples
> are being collected from the ADC, however, when I connect an input through
> the antenna, my data samples to not change at all. It seems the data I
> receive corresponds to when I change the frequency on my local oscillators
> however.
>
> Ive tested collecting data with the default images, and noticed that the
> light turns on next to the antenna on those images, versus on my own image,
> no light is turned on.
>
> I am wondering if anyone else has experienced a similar issue and how they
> troubleshooted it.
>
> Thanks,
>
> Joe
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

[Rob Kossler via USRP-users]

Jim,
One more thought.  One way to buffer data on the host side is to use OS
pipes.  We have used this successfully for continuous receive streaming.
In /etc/sysctl.conf we set some options such as "fs.pipe-max-size" and
"fs.pipe-user-pages-soft" and had separate applications - one filling the
pipe and the other consuming the data.  Of course, you could also create
some type of buffer directly in your application (perhaps even gnuradio has
a way to buffer the data read from the SSD file before sending to the N310).
Rob

On Fri, Apr 14, 2023 at 10:30 AM Rob Kossler  wrote:

>
>> One of the things that puzzles me is that 12.5Msps just isn't that high a
>> streaming rate, in fact it's totally supported over
>>   a *1* GBit interface.
>>
>> At 12.5Msps, that buffer fills(drains) in about 2.5ms.   There's plenty
>> of buffering on the host to buffer application scheduling
>>   issues, so I don't know where these underruns would be coming from.
>>
>> I don't really know what the OS does in terms of "transmit" buffering
> (I'm slightly more confident on the OS behavior for the receive packets). I
> can say that avoiding "U" has always been harder for me than avoiding "O".
> My concern is that the OS is not doing much of any buffering on the Tx side
> (perhaps none) such that if things pause for the 2.5ms you mentioned, then
> "U" occurs.
>
> But, one more comment about incorporating the DRAM fifo: I noticed that
> Ettus has a BIST image that uses this FIFO for the N310 (see here
> ).
> So, this would be a great example to use for creating a custom image.
> Rob
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

[Rob Kossler via USRP-users]

>
>
> One of the things that puzzles me is that 12.5Msps just isn't that high a
> streaming rate, in fact it's totally supported over
>   a *1* GBit interface.
>
> At 12.5Msps, that buffer fills(drains) in about 2.5ms.   There's plenty of
> buffering on the host to buffer application scheduling
>   issues, so I don't know where these underruns would be coming from.
>
> I don't really know what the OS does in terms of "transmit" buffering (I'm
slightly more confident on the OS behavior for the receive packets). I can
say that avoiding "U" has always been harder for me than avoiding "O".  My
concern is that the OS is not doing much of any buffering on the Tx side
(perhaps none) such that if things pause for the 2.5ms you mentioned, then
"U" occurs.

But, one more comment about incorporating the DRAM fifo: I noticed that
Ettus has a BIST image that uses this FIFO for the N310 (see here
).
So, this would be a great example to use for creating a custom image.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

[Rob Kossler via USRP-users]

Jim, Marcus,
I *believe* that "skip_dram=1" will have no effect on the N310 because it
does not use DRAM in the stock image (or even populate the dram-fifo RFNoC
block). The definition of the stock RFNoC graph for the N310 is here

.

Most of the "buffering" for the N310 transmit path is in the buff_size of
the streaming end points attached to the DUC (32768 samples) along with a
small amount of buffering at the DUC (defined here
)
and at the Radio (perhaps here
)
. The easiest way to increase buffering is to increase the buff_size of the
end points ep0 through ep3.  But, it is possible that doing so will cause
the build to fail. I don't know if Ettus max-ed these out or not. But, if
the build fails, another option is to get rid of the Replay block (and
associated end points) and the DDC (if you don't need it) to free up
resources.  Then you might be able to increase the end point buff_sizes.

But, if you want to use the DRAM as a FIFO (which will provide much larger
FIFOs), you should be able to just replace the 4 channel Replay block with
a 4 channel DRAM fifo (defined here
),
making sure to get the RAM address width (and perhaps other parameters)
correct for the N310 (will be same as Replay block uses).  The DRAM is 2GB
so each FIFO "channel" could be configured for 125MSamples.

And, back to one of my previous comments, if you have a lot of host RAM
such that it would be a possibility to stream from a RAM-disk based file, I
believe it would be worth a try.
Rob

On Thu, Apr 13, 2023 at 7:59 PM Marcus D. Leech 
wrote:

> On 13/04/2023 18:51, Jim Schatzman wrote:
> > N310 confirmed.
> >
> > Linux native.
> >
> > tx_samples_from_file produces underruns. So does a customized version of
> tx_samples_from_file that uses multiple buffers and threads to guarantee
> constant send pressure.
> >
> > I understand that the N310 should not do this. I agree that the most
> likely culprit is the host computer, coupled with inadequate buffering in
> the N310. Does anyone know how much buffering it provides and what the
> associated timing is?  That is, what is maximum lag between UDP packets
> before the N310 will experience an underrun condition?
> >
> > In the Ubuntu host system log, there are messages during period in
> question from NetworkManager. Nothing indicating a connection problem, but
> consistent with my general believe that NetworkManager is an evil
> abomination whose primary job is to create trouble and frustration, we will
> remove it from the workstation and try again.
> >
> > Thanks!
> > Jim
> >
> >
> This might seem counter-intuitive, but what happens if you use the
> "skip_dram=1" device argument?  Do things get better
>or worse?
>
> The N310 has 2GiB of DRAM
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

[Rob Kossler via USRP-users]

Hi Jim,
>From a quick review of this chain, it appears your concern is for the
transmit direction (hence, Underruns). Although I have never tried to run
for extended periods such as you are requiring, I am reasonably confident
that the issue is on the host side and not the Radio side.  Some remarks:

   - Perhaps you would get more reliable streaming using DPDK. When I last
   tried this a couple of years ago, the performance was great (at much higher
   rates than you, but for shorter periods of time). But, the side effects
   were substantial (PC mis-behaving to the point of becoming unusable) and so
   I abandoned it. The new DPDK is more mature (as is the OS) from when I
   tried it so it may be much better now with regard to side effects.
   - You could add buffering on the N310 (by building a custom FPGA image)
   that could robustly handle short host "hiccups" in streaming.  Originally,
   the DMA-FIFO RFNoC block was put in the Tx path of devices such as the X310
   for this express purpose. But, the DMA-FIFO block cannot handle 4 streams
   at full rate on an N310 so it is not part of the stock FPGA. The external
   RAM is used instead for the "Replay" block.  But at your data rates, the
   external RAM can handle four streams so you could build an FPGA image that
   replaced the Replay block with the DMA-FIFO such that you would have very
   large buffers on the FPGA to handle host streaming hiccups.  Note that you
   could also build a new image with larger FPGA fabric buffers, but they
   wouldn't approach the size of the external RAM.  If building your own FPGA
   image seems daunting (for some this is a show stopper), I just want to
   mention that what I am suggesting would not require FPGA design talent -
   the necessary blocks already exist  - it would just require purchasing
   Xilinx Vivado and getting past the initial learning curve of building an
   image.
   - How are you generating your Tx samples?  Custom app?  Reading from a
   very large data file?  I ask this because I have had the most streaming
   success when transmitting from a file (or receive to a file) if the file is
   in a "RAM disk".  We generally order Linux PCs with as much RAM as we can
   afford in order to configure such RAM as a RAM disk for the purpose of fast
   streaming to/from files.
   - Finally, if your data is not dynamic (a repeated fixed length sequence
   such as in a repeated radar transmission), I would highly recommend using
   the Replay block to send the data rather than streaming from the host. You
   will likely never see an underrun in this case.  But, I realize that if the
   data is dynamic, this is not possible.

Rob


On Thu, Apr 13, 2023 at 5:03 PM Jim Schatzman <
james.schatz...@futurelabusa.com> wrote:

> Even with all the recommended settings, and a very fast computer that is
> doing nothing except sending the data, it is maybe 50/50 that a 2 hour
> simulation can be conducted without an underrun. The longest run I have
> been able to do without an underrun is about 2.5 hours.
>
> The sample rate is 12.5 Msamp/sec at 16 bit I + 16 bit Q or 400 Mbit/sec.
>
> For our application, that is unacceptable. I need to be able to run for
> days without data loss.
>
> It is a mystery to me why a 10 Gbit connection cannot support 400 Mbit/sec
> UDP reliably.
>
> Any ideas about how we can completely eliminate underruns?
>
> At the moment, I am uncertain whether the problem is occurring on the host
> or on the radio. I suspect the radio, but I will do some testing of the
> host to see what UDP data rate it can support without loss.
>
> Thanks!
>
>
>
>
>
> At 10:53 PM 4/10/2023, Marcus D. Leech wrote:
> >On 10/04/2023 21:12, Jim Schatzman wrote:
> >>The following steps had no impact:
> >>
> >>a) Don't use a switch but do a point-to-point connection between the
> comptuer's NIC and the N310.
> >>b) Adjust network buffers and ring buffer per recommendations (actually,
> the network buffers setting was always being done).
> >>
> >>Increasing the MTU to 9000 had a significant impact. An occasionaly
> underrun is still experienced, but an hour or two of continuous
> transmission is possible.
> >>
> >>I am wondering if this is not an issue on the computer side but on the
> radio side. Is the N310 incapable of supporting 1x 10 Gbps streams with a
> MTU of 1500?  Perhaps.
> >>
> >>I will do some computer-to-computer testing to see if the problem can be
> reproduced there.
> >>
> >>Jim
> >Even non-SDR applications tend to use jumbo-frames for continuous traffic
> at 10Gbit.  I'm sorry that I didn't clue in to that
> >Â  in the first round.
> >
> >
> >>
> >>
> >>
> >>
> >>At 08:39 PM 4/7/2023, Marcus D. Leech wrote:
> >>>On 07/04/2023 22:13, Jim Schatzman wrote:
> We have been unable to estable 100% reliable connections to an N310
> USRP radio through its 10 Gbit ethernet from Linux. What happens is that it
> works fine for a period of time - 30 to 60 minutes, typically. Then we see
> a couple of U's in 

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

[Rob Kossler via USRP-users]

I have only used the Intel cards such as Intel XL710-QDA1 or Intel
XL710-QDA2 and I think that the utility is the following:

https://www.intel.com/content/www/us/en/download/18190/non-volatile-memory-nvm-update-utility-for-intel-ethernet-network-adapter-700-series.html


On Tue, Apr 4, 2023 at 3:52 PM  wrote:

> Hi Rob, thank you for the comments.
>
> I checked with StarTech support team (the manufacturer of XL710 NIC,
> B07983NGQH). But they are saying that it does not have the functionality to
> set as 4*10G.
>
> I was wondering what model of XL710 NIC do you have that worked or what is
> the utility tool you mentioned. Thank you.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

[Rob Kossler via USRP-users]

If you are using RFNoC capable USRPs, it is the UHD 'block controllers'
that propagate a command (or swallow it, if they want) to the next upstream
block controller. Thus if you develop a custom block (and custom block
controller), you can decide if/how you want to propagate properties,
commands, etc.
Rob

On Tue, Apr 4, 2023 at 3:06 PM Rob Kossler  wrote:

> It is really the opposite, the cmd propagation flows upstream (from the
> rx_streamer to the DDC to the Radio).
> Rob
>
> On Tue, Apr 4, 2023 at 3:00 PM yan zhang  wrote:
>
>> So in general, we can just issue stream cmd to one source rfnoc block and
>> the cmd will propagates to all down stream blocks. Is this understanding
>> correct?
>>
>> Thanks!
>>
>> On Tue, Apr 4, 2023 at 11:27 AM Rob Kossler  wrote:
>>
>>> issue_stream_cmd() tells the Rx radio to start sending samples. You
>>> typically call this as rx_streamer->issue_stream_cmd(), and then the
>>> command "propagates" to all the blocks in the graph (such as DDC and then
>>> ultimately the Rx Radio).  Without this command, the Rx radio will not
>>> begin streaming such that your call to "recv()" will timeout for lack of
>>> samples.
>>> Rob
>>>
>>> On Tue, Apr 4, 2023 at 10:58 AM  wrote:
>>>
 Hi all,

 Does anyone know the purpose of issue_stream_cmd() for the rx_streamer?
 When I use the rx_streamer to stream data to the host, I just call the
 recv() method.


 The question is what is the purpose of issue_stream_cmd() for
 rx_streamer in uhd?


 Thanks,

 Yan
 ___
 USRP-users mailing list -- usrp-users@lists.ettus.com
 To unsubscribe send an email to usrp-users-le...@lists.ettus.com

>>>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

[Rob Kossler via USRP-users]

It is really the opposite, the cmd propagation flows upstream (from the
rx_streamer to the DDC to the Radio).
Rob

On Tue, Apr 4, 2023 at 3:00 PM yan zhang  wrote:

> So in general, we can just issue stream cmd to one source rfnoc block and
> the cmd will propagates to all down stream blocks. Is this understanding
> correct?
>
> Thanks!
>
> On Tue, Apr 4, 2023 at 11:27 AM Rob Kossler  wrote:
>
>> issue_stream_cmd() tells the Rx radio to start sending samples. You
>> typically call this as rx_streamer->issue_stream_cmd(), and then the
>> command "propagates" to all the blocks in the graph (such as DDC and then
>> ultimately the Rx Radio).  Without this command, the Rx radio will not
>> begin streaming such that your call to "recv()" will timeout for lack of
>> samples.
>> Rob
>>
>> On Tue, Apr 4, 2023 at 10:58 AM  wrote:
>>
>>> Hi all,
>>>
>>> Does anyone know the purpose of issue_stream_cmd() for the rx_streamer?
>>> When I use the rx_streamer to stream data to the host, I just call the
>>> recv() method.
>>>
>>>
>>> The question is what is the purpose of issue_stream_cmd() for
>>> rx_streamer in uhd?
>>>
>>>
>>> Thanks,
>>>
>>> Yan
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

[Rob Kossler via USRP-users]

Unfortunately, I don't really know. I do not have an X410. However, I do
have an N321 which has both a QSFP+ port and two SFP+ ports. I use the SFP+
ports with a 4x10Gb breakout cable (either fiber or copper) and the XL710
NIC. But, it is my understanding that the N321 QSFP+ port is configured to
operate as 4x10Gbe (but use only 2 of the 4 lanes available on the
interface).  I don't really know if your cable will work but it seems to me
like it should
Rob


On Tue, Apr 4, 2023 at 2:39 PM  wrote:

> Thank you Rob,
>
> In USRP-X410 I can load X4_200 FPGA image to set QSFP28 port 0 interface
> to 4*10G, and as you said I need to set XL710-NIC similarly with some
> utility tools. Does that mean I do not need any extra adaptor between them
> for rate/protocol match.
>
> please correct me for the following step:
>
> 1- then for connection between USRP-X410 and XL710-NIC in such 4*10G
> configuration, does this cable works:
>
>  40G QSFP+ DAC Cable - 40GBASE-CR4 Passive Direct Attach Copper Twinax
> QSFP Cable (from 10Gtek)
>
> 2- Do I need other settings in USRP-X410 or XL710-NIC sides to establish
> communication links.
>
> 3- I assume I may need also install DPDK later.
>
> Thank you for support.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

[Rob Kossler via USRP-users]

There is a persistent setting on the XL710 such that it can be either
40GBASE or 4x10GBASE.  Intel has a utility that you can use to program this
setting.  Perhaps this is the issue for you?
Rob

On Tue, Apr 4, 2023 at 1:43 PM  wrote:

> Hello,
>
> I am trying to integrate USRP-X410 with XL710 intel PCIe NIC card through
> QSFP ports.
>
> LED on both sides is off and I cannot ping USRP (192.168.10.2 and
> 192.168.20.2) through XL710. PCI card ports can be ping successfully, as IP
> addresses configured in the same subnetwork. Therefore, it seems link
> cannot establish between USRP-X410 and XL710 NIC. I think, it may because
> of rate mismatch between USRP-X410 and XL710 NIC card. (While USRP X410
> with QSFP28 supports 10GE and 100GE, XL710 with QSFP+ only supports 40GE).
> Is there any way of auto-negotiating for speed in USRP, or other solution
> to help overcome this issue. Thank you.
>
> Here is my hardware setup.
>
> -  Ubuntu 22.04
>
> -  USRP X410
>
> -  UHD v4.4.0.0
>
> -  GNU radio v3.10.5.1
>
> -  Dual Port 40G QSFP+ NIC - Intel XL710
>
> -  40G QSFP+ DAC Cable - 40GBASE-CR4 Passive Direct Attach Copper
> Twinax QSFP Cable (from 10Gtek)
>
> BTW, I tried both X4_200 (10GE) and CG_400 (100GE) FPGA flavors, but still
> same problem.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

[Rob Kossler via USRP-users]

issue_stream_cmd() tells the Rx radio to start sending samples. You
typically call this as rx_streamer->issue_stream_cmd(), and then the
command "propagates" to all the blocks in the graph (such as DDC and then
ultimately the Rx Radio).  Without this command, the Rx radio will not
begin streaming such that your call to "recv()" will timeout for lack of
samples.
Rob

On Tue, Apr 4, 2023 at 10:58 AM  wrote:

> Hi all,
>
> Does anyone know the purpose of issue_stream_cmd() for the rx_streamer?
> When I use the rx_streamer to stream data to the host, I just call the
> recv() method.
>
>
> The question is what is the purpose of issue_stream_cmd() for rx_streamer
> in uhd?
>
>
> Thanks,
>
> Yan
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B205 mini i very high lo-leakage, image rejection and aggressive DC correction.

[Rob Kossler via USRP-users]

Hi Sorin,
Regarding the maximum LO offset you can use:
  LO-offset-max = (master_clock_rate - sample_rate) / 2;
This equation ensures that your desired bandwidth (determined by sample
rate), will fit within the digital stream (at rate MCR) that is supplied to
the FPGA from the RF front end. So, with the B200 series, you need to set
the master_clock_rate accordingly.
Rob

On Tue, Mar 28, 2023 at 9:54 AM  wrote:

> Thank you.
>
> A. Let me understand. Can I make the lo_offset higher than sampling rate/2
> ?
>
> B. I will try. About “But, also, consider LO offset in the TX path as
> well.” I don’t want to use a tunable filter.
>
> We did work with other Analog devices component. They are capable of
> better performance than they show in your device.
>
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Wideband IQ Daughterboard

[Rob Kossler via USRP-users]

Hi Eugene,
I don't know why the basic Rx has a lower frequency listed.  It seems
inconsistent with other notes such as the following found here


Some USRP radio users elect to use an external front end providing
upconversion, downconversion, amplification and filtering functionality. In
these cases, the frontend often outputs an intermediate frequency (IF). It
is also possible for the frontend to provide an analog, quadrature
interface. In either case the BasicRX/BasicTX and LFRX/LFTX daughterboards
are good candidates, as they provide a unity gain interface to the ADC(s)
and DAC(s) of the USRP hardware.

I have not tried so I can't confirm if it will work. I can only say that it
was my understanding that the Basic Rx could be used for your specific
application.
Rob

On Mon, Mar 27, 2023 at 12:08 PM Eugene Grayver 
wrote:

> Yes, as evidenced by UBX-160.  X310 can stream 200 Msps complex, which is
> sufficient for 160 MHz of BW.
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Engineer
> Tel: 310.336.1274
> 
> --
> *From:* Robert McGwier 
> *Sent:* Sunday, March 26, 2023 7:50 PM
> *To:* Brian Padalino 
> *Cc:* Eugene Grayver ; usrp-users <
> usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] Re: Wideband IQ Daughterboard
>
> Can the  existing firmware support that bandwidth? The 10Gbps Ethernet can
> but I am not sure about the rest of the USRP. I own two of them and have
> never tried to do that.
>
> Bob
>
>
> On Wed, Mar 22, 2023 at 9:58 AM Brian Padalino 
> wrote:
>
> You're right - I completely missed that part of the email.
>
> My apologies.
>
> Brian
>
> On Tue, Mar 21, 2023 at 7:12 PM Eugene Grayver 
> wrote:
>
> Yes, as stated in the original post 'Basic-RX with a minimum of 1 MHz'.
> The DC is cutoff by the balun on the basicRX making it unsuitable for IQ.
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Engineer
> Tel: 310.336.1274
> 
>
> --
> *From:* Brian Padalino 
> *Sent:* Tuesday, March 21, 2023 3:18 PM
> *To:* Eugene Grayver 
> *Cc:* usrp-users 
> *Subject:* Re: [USRP-users] Wideband IQ Daughterboard
>
> On Tue, Mar 21, 2023 at 6:12 PM Eugene Grayver 
> wrote:
>
> Hello,
>
> I want to use an external IQ mixer with an external LO.  My signal is 160
> MHz wide, which fits nicely into the nominal complex 200 MHz Nyquist of the
> X310.  Unfortunately the only daughterboards for direct access to the ADCs
> are LFRX which maxes out at 30 MHz, and the Basic-RX with a minimum of 1
> MHZ.
>
> I am thinking of spinning a custom daughter board derived from LFRX with a
> wideband differential driver such as
> https://www.analog.com/media/en/technical-documentation/data-sheets/6406fc.pdf
>  or
> alternatively just replacing the chip on an LFRX since these appear to be
> footprint compatible.
>
> Separately, I was looking at LFTX schematics and the part # for the
> amplifier is not specified.  Can somebody at Ettus/NI save me some time and
> lookup that part #.
>
> Comments?
>
>
> Have you considered the BasicRX?
>
>   https://www.ettus.com/all-products/basicrx/
>   https://files.ettus.com/schematics/basic_dbs/BasicRX.pdf
>
> Brian
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> --
> Dr. Robert W McGwier, Ph.D.
> Affiliated Faculty, Virginia Tech
> Affiliated Faculty, University of Scranton
> Former ARDC Member of Board
> N4HY: ARRL, TAPR, AMSAT, EARC, CSVHFS
> Sky: AAVSO, Sky360, explorescu.org, Skyscrapers
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Backpressure over Ethernet

[Rob Kossler via USRP-users]

Hi Wade,
I am using 10GbE.  It is likely an issue with host Ethernet handling (rx
descriptors or something like that) such that the OS ethernet handling gets
overwhelmed prior to UHD backpressuring the FPGA.  My OS is Ubuntu 22.04
LTS.

After lots of playing around, I am now getting semi-reliable behavior
running at about 7-8Gbps but it is curious that if I try to run my
application several times in a row, I often get bad behavior.  Instead, if
I run my application with a very short sample burst (say 4096 samples
total) following a typical execution with a long sample burst, this seems
to prevent bad behavior.  So, my theory is that running with the short
burst helps the host OS to clear / reset Ethernet buffers such that the
subsequent long burst can be successful.

Rob

On Sat, Mar 25, 2023 at 5:19 PM Wade Fife  wrote:

> It sounds like something isn't right. The streamers should automatically
> backpressure. That's how it works with the radio, and it should be the same
> for a custom block connected to stream endpoints.
>
> We have seen cases where host ethernet interfaces can't keep up when you
> start approaching the line rate of Ethernet (e.g., 10 Gbps) so they drop
> packets, which show up as sequence errors on the RX streamer.
>
> What kinds of rates are you getting across each interface? Is this over 10
> GbE? Any chance the "ready" signal isn't being used properly in your block
> to allow back-pressure? The block needs to deassert tready to tell the
> stream endpoint to backpressure the streamer.
>
> Wade
>
> On Fri, Mar 24, 2023 at 9:41 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> I developed a custom RFNoC block and was testing it with a graph that was
>> essentially:
>>   tx_streamer => myblock => rx_streamer
>>
>> This works fine unless I send a large number of samples, in which case
>> bad stuff happens in terms of sequence errors, timeouts, etc (i.e., the
>> typical streaming at high speed woes).
>>
>> In the case of a Radio that must stream output samples at a fixed rate, I
>> can easily understand the need for keeping up on the host side.  But, for
>> my case where I am just streaming through a custom block that does not care
>> about sample rate, it would be nice if backpressure could handle the host
>> rate variations.
>>
>> In order to make things "work", I have inserted a "sleep" statement in my
>> transmit loop to purposely throttle the Tx rate so that the Rx could keep
>> up.  This works well enough but in order to get reliable streaming I am
>> forced to throttle more than I would like.  So, I am wondering if anyone
>> has ideas on a better way to handle this.
>>
>> It seems that the host Rx gets overwhelmed and cannot backpressure my
>> block. I don't quite understand why because if there is no backpressure,
>> how do we get "Overflow" when the radio has no place to put incoming
>> samples "because of backpressure"?
>>
>> Rob
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Backpressure over Ethernet

[Rob Kossler via USRP-users]

Hi,
I developed a custom RFNoC block and was testing it with a graph that was
essentially:
  tx_streamer => myblock => rx_streamer

This works fine unless I send a large number of samples, in which case bad
stuff happens in terms of sequence errors, timeouts, etc (i.e., the typical
streaming at high speed woes).

In the case of a Radio that must stream output samples at a fixed rate, I
can easily understand the need for keeping up on the host side.  But, for
my case where I am just streaming through a custom block that does not care
about sample rate, it would be nice if backpressure could handle the host
rate variations.

In order to make things "work", I have inserted a "sleep" statement in my
transmit loop to purposely throttle the Tx rate so that the Rx could keep
up.  This works well enough but in order to get reliable streaming I am
forced to throttle more than I would like.  So, I am wondering if anyone
has ideas on a better way to handle this.

It seems that the host Rx gets overwhelmed and cannot backpressure my
block. I don't quite understand why because if there is no backpressure,
how do we get "Overflow" when the radio has no place to put incoming
samples "because of backpressure"?

Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Time base error

[Rob Kossler via USRP-users]

Following up on my previous email, I found that this error was happening
when I set UHD_MODULE_PATH to allow UHD to find my RFNOC library had also
linked my library explicitly in my custom app.  Thus, if I ran
uhd_usrp_probe, everything was fine because it found my library in the
defined UHD_MODULE_PATH.  But, when I ran my custom app, it loaded
my explicitly linked library and then UHD also loaded the library in the
path.  This seemed to cause the mentioned error because if I simply "unset"
the variable, everything worked fine.
Rob

On Thu, Mar 23, 2023 at 12:48 PM Rob Kossler  wrote:

> Hi Jeff,
> I am getting this same error.  Did you ever figure out the problem?
> Rob
>
> On Sat, May 22, 2021 at 5:46 PM Jeffrey P Long  wrote:
>
>> I am getting some weird error about a invalid time base clock name after
>> starting to create my own block. I did not see this just doing the simple
>> pass thru RFnoc example. What would this mean?
>>
>> Thanks
>> Jeff
>>
>> 
>>
>>
>> jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-example/build/apps$
>> ./txcore_block
>> [REGISTRY] WARNING: Attempting to overwrite previously registered RFNoC
>> block with noc_id,device_id: 0xb16, 0x
>> [REGISTRY] WARNING: Attempting to overwrite previously registered RFNoC
>> block with noc_id,device_id: 0xde30, 0x
>>
>> Creating the RFNoC graph with args: ...
>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
>> UHD_4.0.0.0-122-g75f2ba94
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=192.168.30.5,type=e3xx,product=e320,serial=31DCD15,claimed=False,addr=192.168.10.5
>> [INFO] [MPM.PeriphManager] init() called with device args
>> `mgmt_addr=192.168.30.5,product=e320'.
>> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
>> [INFO] [0/Radio#0] CODEC loopback test passed
>> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
>> [INFO] [0/Radio#0] CODEC loopback test passed
>> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
>> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
>> [ERROR] [MPMD::MB_IFACE] Invalid timebase clock name:
>> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
>> LookupError: KeyError: [MPMD_MB::IFACE] Invalid timebase clock name:
>> Error: RuntimeError: Failure to create rfnoc_graph.
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Time base error

[Rob Kossler via USRP-users]

Hi Jeff,
I am getting this same error.  Did you ever figure out the problem?
Rob

On Sat, May 22, 2021 at 5:46 PM Jeffrey P Long  wrote:

> I am getting some weird error about a invalid time base clock name after
> starting to create my own block. I did not see this just doing the simple
> pass thru RFnoc example. What would this mean?
>
> Thanks
> Jeff
>
> 
>
>
> jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-example/build/apps$
> ./txcore_block
> [REGISTRY] WARNING: Attempting to overwrite previously registered RFNoC
> block with noc_id,device_id: 0xb16, 0x
> [REGISTRY] WARNING: Attempting to overwrite previously registered RFNoC
> block with noc_id,device_id: 0xde30, 0x
>
> Creating the RFNoC graph with args: ...
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_4.0.0.0-122-g75f2ba94
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.30.5,type=e3xx,product=e320,serial=31DCD15,claimed=False,addr=192.168.10.5
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=192.168.30.5,product=e320'.
> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
> [INFO] [0/Radio#0] CODEC loopback test passed
> [INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
> [INFO] [0/Radio#0] CODEC loopback test passed
> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
> [INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
> [ERROR] [MPMD::MB_IFACE] Invalid timebase clock name:
> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
> LookupError: KeyError: [MPMD_MB::IFACE] Invalid timebase clock name:
> Error: RuntimeError: Failure to create rfnoc_graph.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Re: [USRP-users] X310 with dual TwinRX set up

[Rob Kossler via USRP-users]

Hi Oliver,
I don't have any example code to provide (and I don't use gnuradio), but I
can address a couple of things:
- the first step is to get all four channels recognized (as you indicated);
perhaps using subdev spec "A:0 A:1 B:0 B:1"
- synchronizing in time is definitely possible. From gnuradio, I thought
that it was the default for multi-channel operation.  You might have to
lookup a set_start_time or similar command. check the uhd gnuradio
documentation for usrp source
.
- four channels at 100 MS/s is also achievable.  To use dual 10Gbe, you
need to specify the "second_addr" device arg as indicated here
.
Rob

On Wed, Mar 10, 2021 at 1:10 PM Oliver Towlson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi
>
>
>
> I am trying to set up an X310 with 2 TwinRX boards such that:
>
>
>
> - each RF channel may be tuned to a different GNSS L-band frequency
>
> - all four RF channels may be synchronised in time
>
> - data streaming on all four channels at 100 MS/s (we are using dual 10G
> Ethernet for this)
>
>
>
> I’m pretty much a beginner when it comes to USRPs. I am using GNU radio to
> configure the USRP but so far it only recognizes two input channels. We
> found the code posted here -
> http://ettus.80997.x6.nabble.com/USRP-users-Example-code-for-a-pair-of-TwinRXs-td2673.html
> - useful but on closer inspection all four channels were set to the same
> frequency and it looks to be doing something different to what we want (it
> looks like it was written specifically to synchronise four channels
> receiving the same signal so that you can calibrate the internal phase
> offset of the USRP)
>
>
>
> Does anyone have any example code they might be willing to share, if only
> to get us started, to get our desired set-up?
>
>
>
> Thanks
>
>
>
> Oliver T
>
> P Please consider the environment before printing this e-mail.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC 4 metadata

[Rob Kossler via USRP-users]

Hi,
I just modified one of my RFNoC blocks to use metadata for the first time.
The following remarks identify issues I encountered along the way and some
suggestions that would make things a bit easier.

   - You can't use axis_data (with sideband signals) if you want access to
   metadata. While I realize that Ettus has indicated that metadata is an
   "advanced" use case and that the axis_data interface is a "simple"
   interface model, it still seems like it wouldn't be that difficult to
   expand the axis_data model to accommodate some metadata capability
   - Along the same lines, any block that uses axis_data will discard any
   metadata from an upstream block.  This is probably the bigger issue.  For
   example, if the rx radio were to insert a metadata word, it would be
   discarded by the DDC since the DDC uses the axis_data model
   - There is no structure to the metadata.  I fully understand that this
   is by intent.  However, I did start to wonder if some skeleton structure
   would make sense. For example, maybe some bits of the metadata should be
   designated for the NOC_ID of the block that inserts it.  Or, instead, maybe
   some bits could hold a unique WORD_ID that identifies the type of metadata
   word.  Ettus could reserve some IDs for itself to allow for future use of
   metadata by Ettus blocks.
   - It would be nice if it was easier for a block to just "insert" a
   metadata word.  With my own limited FPGA skills, I just decided to ignore
   any upstream metadata words and create 1 metadata word that gets sent to
   downstream blocks.  But, that's not very friendly to the upstream blocks.
   If it were easier to do, I would have preferred to just add my block's
   metadata word to the incoming metadata words.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD 4 "properties"

[Rob Kossler via USRP-users]

Hi,
I wanted to revisit a couple of issues with UHD 4.0 properties and ask
whether Ettus is planning any changes to the property architecture that
would address these issues.  The 2 issues are the following:

   - There is presently not a good way to use a property with a read-only
   register (where the register values are dynamic).  As seen in the exchange
   below, Martin suggests the ALWAYS_DIRTY setting, but it seems that is
   impractical because of the unnecessary register I/O that occurs.  I
   inserted some LOG messages in my code which showed that the register was
   being read at numerous times, not just in response to a user-initiated
   query of the given property (as would be the case if there was a "get"
   callback function in a similar way to UHD 3.15 args).
   - If the user "sets" the value of a property such that the value does
   not change, the "set" callback does not execute. This again differs from
   behavior of 3.15 args.  In 3.15, I used an "arg" that was a string which
   identified a window coefficient file.  Whenever I set the arg, the callback
   read the file and downloaded the coefficients to the FPGA.  I could
   externally update the coefficients inside the file and then set the arg
   again and the coefficients would be reloaded even though the filename
   itself did not change. With UHD 4 properties, this does not happen.  If the
   property string does not change (i.e., the filename does not change), the
   "set" callback does not execute.

Rob


On Wed, Oct 7, 2020 at 6:40 PM Rob Kossler  wrote:

> Hi,
> I have 2 issues related to properties in UHD 4.0.
>
> The first is regarding the concept of a read-only property where the
> property is monitoring some HW status. This was discussed in another thread
> (which I copied  below) but I decided to move it here to a new thread. The
> proposed solution doesn't seem practical if ALWAYS_DIRTY causes numerous
> register reads as it appears to.
>
> The second issue is related to setting a property to a value that does not
> change. This may seem stupid but in the past (UHD 3.15), I could use a
> block arg as representing a string filename (e.g., a file containing Window
> coefficients).  If I registered a function as a publisher for this arg,
> then my function would run whenever this property was set (whether or not
> it changed) so that I could read my file and load the coefficients.  But,
> with UHD4 properties, my function is not getting called when the property
> is set to the same filename as it was before the set.  So, even though the
> coefficients in the file are changed, they are never loaded because the
> filename itself did not change.
>
> Let me know if you have any suggestions on either issue.
> Rob
>
>
> > Rob, you might want to check out host/tests/rfnoc_graph_mock_nodes.hpp,
> > and look at the RSSI property. It's supposed to mock a property that
> > only represents a value that is read back from the radio (none of our
> > RFNoC radios actually have that property, but we provisioned for it in
> > the specification, and this is an example of that).
> >
> > Instead of updating a counter (which we only do because this is a mock
> > for unit testing), you would peek a register.
>
> Hi Martin,
> I looked at this and implemented a property using the ALWAYS_DIRTY
> dependency shown in the mock case. This does work, but it causes my
> actual register peek to occur quite a lot - not just when a user calls
> get_property for that property.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc architecture suggestions

[Rob Kossler via USRP-users]

I have one additional suggestion, but it is somewhat related to my other
suggestion about alleviating the user's need to care about packet lengths.
In order to illustrate, consider the Ettus FFT RFNoC block.  For this block
to function properly, we pretty much need to guarantee that the incoming
packet length matches the FFT size.  Otherwise partial packets end up stuck
in the FFT input. So, the way it stands presently, the user must do the
following when using the FFT block:

   - Set the Radio SPP equal to the FFT size.
   - Include the DDC. If the user does not include the DDC, then the final
   radio packet will likely be a partial packet and thus will get stuck in the
   FFT input
   - Stick to FFT sizes that are within the range of allowable packet sizes

When I realized this, I realized that the "key" was the "axi_rate_change"
module used by the DDC.  In addition to its primary function of handling
rate change stuff, this module ensures that the user logic never receives
partial packets. Thus, I decided to incorporate it into my own FFT-based
RFNoC block directly such that (A) I wouldn't need to have the DDC, (B) I
wouldn't need to set the radio SPP, and (C) I could use FFT sizes as large
as I want (independent of packet sizes limited by MTU considerations).

While this seems to work fine for me, it is a little bit strange using a
"rate_change" module for an RFNoC block that is not actually changing rate.
It is simply convenient because of its discarding of partial packets and
its automatic handling of the header info (alleviating this requirement
from the actual user logic). And, the other odd thing about using this rate
change module is the fact that the module still uses axi settings regs and
thus causes me to use that style in my rfnoc block.

So, after all that discussion, my suggestion is to provide additional
functionality for automatic handling of context information and packetizing
along the lines of "axi_rate_change" and/or functionality from the old
"axi_wrapper" (although the custom noc_shell replaces some of the
functionality from "axi_wrapper", it does not provide replacement
functionality for all "axi_wrapper" capabilities). Perhaps it would be
possible to include such functionality as options in the custom noc_shell.
Rob

On Fri, Feb 26, 2021 at 2:23 PM Wade Fife  wrote:

> Rob,
>
> Thanks for the feedback! I like your suggestions. In fact, the bypass
> option is one that we've discussed a few times, since it would be very
> useful for debug and would allow some blocks to be statically routed that
> currently use the crossbar. We definitely want to make things easier for
> users. Please continue to share suggestions you have.
>
> Thanks!
>
> Wade
>
> On Fri, Feb 26, 2021 at 10:08 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> While I am a big fan of the architectural changes to RFNoC with the
>> release of UHD 4.0, I have a couple of suggestions for improvement. I am
>> admittedly a novice FPGA developer so it's certainly possible that these
>> suggestions are "easier said than done" or poor choices for other reasons.
>> But, that won't stop me from suggesting them...
>>
>>- Remove to a greater extent the requirement for user logic to "care"
>>about packet lengths.  In many cases, the user logic does not care about
>>packet lengths and MTU sizes and such.  For example, if I am writing a
>>signal generator that is feeding a DUC/Radio, I may care about a time 
>> stamp
>>and EOB, but I simply do not care about RFNoC packet sizes. This is true 
>> in
>>several custom blocks I have written.  However, in the current RFNoc
>>architecture, I am forced to care about them. At a minimum, I must set
>>tlast and depending upon the context model I choose, I may also have to
>>make sure that my context payload length matches this. It seems to me that
>>the custom noc_shell could be tweaked further to alleviate this burden for
>>more use cases.
>>- Provide an automatic "bypass" mode (or an option to enable this in
>>the block yml) in the custom noc_shell. I am talking about a capability
>>that would allow the user to bypass user logic by setting a register such
>>that the custom block would become a "thru" block.  While I recognize that
>>this functionality is not appropriate to all blocks (e.g., 2 input, 3
>>output), there are a large number of blocks for which this would be
>>helpful.  Given the new capability for static routing, this would allow 
>> the
>>user to bypass a statically routed block. And, while I could certainly
>>implement such logic in

[USRP-users] rfnoc architecture suggestions

[Rob Kossler via USRP-users]

While I am a big fan of the architectural changes to RFNoC with the release
of UHD 4.0, I have a couple of suggestions for improvement. I am admittedly
a novice FPGA developer so it's certainly possible that these suggestions
are "easier said than done" or poor choices for other reasons. But, that
won't stop me from suggesting them...

   - Remove to a greater extent the requirement for user logic to "care"
   about packet lengths.  In many cases, the user logic does not care about
   packet lengths and MTU sizes and such.  For example, if I am writing a
   signal generator that is feeding a DUC/Radio, I may care about a time stamp
   and EOB, but I simply do not care about RFNoC packet sizes. This is true in
   several custom blocks I have written.  However, in the current RFNoc
   architecture, I am forced to care about them. At a minimum, I must set
   tlast and depending upon the context model I choose, I may also have to
   make sure that my context payload length matches this. It seems to me that
   the custom noc_shell could be tweaked further to alleviate this burden for
   more use cases.
   - Provide an automatic "bypass" mode (or an option to enable this in the
   block yml) in the custom noc_shell. I am talking about a capability that
   would allow the user to bypass user logic by setting a register such that
   the custom block would become a "thru" block.  While I recognize that this
   functionality is not appropriate to all blocks (e.g., 2 input, 3 output),
   there are a large number of blocks for which this would be helpful.  Given
   the new capability for static routing, this would allow the user to bypass
   a statically routed block. And, while I could certainly implement such
   logic in all of my custom blocks, it would be more useful if this were
   standard across all blocks including Ettus blocks such as DDC & DUC.

Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] User register on X300 UHD 3.9

[Rob Kossler via USRP-users]

Hi Cédric,
I don't fully know the answer, but if you look in the 3.9.LTS source code
for examples of "publish()", "subscribe()", and "coerce()" functions.
Something along the lines of
  grep "publish(" $(find ./ -name "*.cpp")  # if you are in the host/uhd
folder

At this point, I think that you then just access the given node of the
property tree using a get or set function.

Rob

On Wed, Feb 24, 2021 at 9:13 AM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 18/02/21 10:27, Cédric Hannotier via USRP-users wrote:
> > On 17/02/21 18:39, Marcus Müller via USRP-users wrote:
> > > Then, you'll have to add a setter / getter in C++ UHD. That boils down
> to adding a coercer
> > > and getter to the property_tree. Copy existing code and modify the
> read/write address
> > > appropriately to address your settings_register!
> >
> > Ok, that is the part that I did not get.
> > I tried out with set_user_register but it failed.
> > Do you know where I can find documentation
> > for adding setter/getter to the "property_tree"?
>
> Does anyone know how to do that or can redirect me to documentation?
>
> Regards
> --
>
> Cédric Hannotier
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to issue start stream command directly to DDC/Radio block using GNU Radio

[Rob Kossler via USRP-users]

Hi Mark, Tuan,
The problem seems to be that the default block controller does not
propagate the issue_stream_cmd (I'm guessing that this is a "bug" but
perhaps it is intended behavior). In any case, it seems that you have to
build & link your own block controller if you need this to happen. There
are a few work arounds that I know about, but they might not be possible in
all cases:

   - you could build your block controller in-tree.  This assumes that you
   have the ability to build UHD from source code. If so, you can place your
   controller HPP & CPP files in the same folder that Ettus uses for the RFNOC
   block HPP & CPP files, edit the CMakeLists.txt file in those folders to add
   your new files, and then re-build UHD (and re-install using "make install"
   or "sudo make install").  This has the nice advantage that uhd_usrp_probe
   will now be aware of your blocks when it runs.
   - you could build your block controller out-of-tree and link it using
   the --no-as-needed link option.  As you pointed out, you will need to link
   to rfnoc-tutorial or whatever the name of your OOT library is. This library
   will need to be installed in a location where the linker can find it.
   Perhaps by running "sudo make install" on your OOT library, this will take
   care of it, but not really sure.
   - you could modify the gnuradio code to call issue_stream_cmd() from the
   DDC block rather than from the rx_streamer.  I'm a little fuzzy here
   because I don't use gnuradio, but I have done something similar from an
   Ettus c++ example and it seemed to work fine.  Note that this case is
   assuming you don't really need a block controller and can live with the
   block id "Block#0".  If you actually need your custom block controller
   (because it has functions you want to call), you will need to get one of
   the above items working.

Rob

On Mon, Feb 22, 2021 at 9:50 AM Mark D via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Tuan,
>
>
>
> Good to know that I’m not the only one struggling to get past this issue.
>
>
>
> I must admit that the solutions proposed have left me rather confused and
> needing to start look into a whole load of stuff that I was hoping to
> avoid. I don’t know how to build controller code in the UHD tree. I was
> also thinking of adapting the rfnox_rx_to_file.cpp code, but again
> modifying this to set the routing in the FPGA and then building it is
> something that I just don’t where to start with.
>
>
>
> I’ve been trying to just build a renamed copy of rfnoc_rx_to_file.cpp
> under my OTT folder but so far have had no luck yet even getting it to
> compile.
>
>
>
> I’m assuming the line after “"-Wl,--no-as-needed” should have the name of
> OTT module, such as rfnoc-tutorial, but I get an error to “/usr/bin/ld:
> cannot find -rfnoc-tutorial”
>
>
>
> The tutorial video on UHD with the gain block all looks quite straight
> forward, but not being able to include an OTT block into a real-world GNU
> Radio application is a huge stumbling block for those without prior
> experience building CPP applications and make files.
>
>
>
> Do we have any idea when Ettus plan to release the next revision of UHD
> that would have a fix for this?
>
>
>
> Mark
>
>
>
> *From:* USRP-users  *On Behalf Of *Tuan
> Hoang Dinh via USRP-users
> *Sent:* 21 February 2021 12:29
> *To:* usrp-users 
> *Subject:* [USRP-users] How to issue start stream command directly to
> DDC/Radio block using GNU Radio
>
>
>
> Hi,
>
> I'm testing my first RFNoC block using GNU radio, when executing the
> graph, the UHD return recv() time out like the picture below.
>
>
>
>
>
> I searched on the mailing list and know this is a problem when start
> stream command did not send directly to DDC/Radio block, the new RFNoC
> block (Block0) did not forward start stream command to DDC block. You can
> find the error here: https://github.com/EttusResearch/uhd/issues/406
>
>
>
> Some solutions have been issued to fix rfnoc_rx_to_file.cpp but I'm still
> looking for how to fix this error in GNU Radio.
>
> Does anyone know how to solve this?
>
> Thank you!
>
>
>
> Best regards,
>
> Tuan
>
>
> --
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OTT Gain Block stopping samples flowing from RFNoC Digital Down Converter

[Rob Kossler via USRP-users]

Yes, that is my best guess.  Did you try it?

On Fri, Feb 19, 2021 at 11:00 AM Cédric Hannotier via USRP-users
 wrote:
>
> Hi Rob,
>
> On 19/02/21 09:30, Rob Kossler wrote:
> > Yes, I just double-checked and mine is working.
> >
> > So, I just re-checked your link to issue #406. In "steps to reproduce", I
> > noticed 2 things:
> >
> >- On the next-to-last line, the g++ command does not include your custom
> >library and does not include this link option.  The Ettus example builds
> >your block controller in its own shared library - it does not add it to 
> > the
> >uhd shared library. So, you need to link with both uhd and your
> >rfnoc-example shared library (or whatever it is named). And, you need to
> >have that link option.  (as a side note, when you built the 
> > rfnoc-example,
> >this did build the init_gain_block.cpp example in the apps folder with 
> > this
> >link option so if you were to run that example, you could confirm that 
> > the
> >block ID in that example is "Gain#0" rather than "Block#0". But since 
> > this
> >example doesn't use the radio, you couldn't use it to verify action
> >propagation).
>
> So, to summarise:
>
> g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd
>
> does not work,
>
> g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd 
> -lrfnoc_example
>
> does not work either, but
>
> g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd 
> -Wl,--no-as-needed -lrfnoc_example
>
> works.
>
> Am I correct?
>
> Regards
> --
>
> Cédric Hannotier
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com