Re: [USRP-users] Addsub HLS Block Error
Yes, I've used it, no custom block controller required. Attached are XML and GRC descriptors. On Sat, Sep 7, 2019 at 11:22 AM d.des wrote: > I wonder if you have successfully used this block with grc or if you > were just using it with uhd. When I try to use the 2-input, 1-output > block in grc I get: "RuntimeError: Invalid stream args." this looks > like same issue as > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057702.html > and the solution at that time seemed to be to keep the second port so > as not to confuse the streamer. > > In case I'm doing something dumb in the xml, here are the files I > created for uhd and grc: > > > > > addonly > addonly > > 41253002 > > > > in0 > > > in1 > > > out > > > > > > > > > RFNoC: addonly > dave_addonly > import ettus > ettus.rfnoc_generic( > self.device3, > uhd.stream_args( \# TX Stream Args > cpu_format="$type", \# TODO: This must be made an option > otw_format="sc16", > channels=(0,1), > args="align=1", > ), > uhd.stream_args( \# RX Stream Args > cpu_format="$type", > otw_format="sc16", > channels=(0,1), > args="align=1", > ), > "addonly", $block_index, $device_index, > ) > > > Host Data Type > type > enum > > Complex float32 > fc32 > type:fc32 > > > Complex int16 > sc16 > type:sc16 > > > > > dcovariance Select > block_index > -1 > int > #if int($block_index()) 0 then 'part' else > 'none'# > RFNoC Config > > > Device Select > device_index > -1 > int > #if int($device_index()) 0 then 'part' else > 'none'# > RFNoC Config > > > > FPGA Module Name > fpga_module_name > noc_block_dcovariance > string > all > RFNoC Config > > > > in > $type.type > rfnoc > 2 > > > > out > $type.type > rfnoc > > > > > The messages just before the error are: > [DEBUG] [DEVICE3] Port 0x20: Found NoC-Block with ID 41253002. > [DEBUG] [RFNOC] Reading XML file > /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC > ID 0x41253002 > [DEBUG] [E300] [E300] Setting up dest map for host ep 35 to be stream 3 > > [TRACE] [RFNOC] [RFNoC Factory] block_ctrl_base::make() > [DEBUG] [RFNOC] Reading XML file > /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC > ID 0x41253002 > [WARNING] [RFNOC] Can't find a block controller for key addonly, using > default block controller! > [TRACE] [RFNOC] [RFNoC Factory] Using controller key 'Block' and block > name 'addonly' > [DEBUG] [RFNOC] Reading XML file > /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC > ID 0x41253002 > [INFO] [0/dcorrelate_0] Initializing block control (NOC ID: > 0x41253002) > [DEBUG] [0/dcorrelate_0] Checking compat number for FPGA component > `noc_shell': Expecting 5.1, actual: 5.1. > [TRACE] [0/addonly_0] Adding port definition at > xbar/dcorrelate_0/ports/in/0: type = '' pkt_size = '0' vlen = '0' > [TRACE] [0/addonly_0] Adding port definition at > xbar/dcorrelate_0/ports/in/1: type = '' pkt_size = '0' vlen = '0' > [TRACE] [0/addonly_0] Adding port definition at > xbar/addonly_0/ports/out/0: type = '' pkt_size = '0' vlen = '0' > [DEBUG] [E300] [E300] Setting up dest map for host ep 36 to be stream 4 > > : > > : > [DEBUG] [E300] Actually got clock rate 10 MHz > > [DEBUG] [CORES] Performing timer loopback test... > [DEBUG] [CORES] Timer loopback test passed. > [TRACE] [RFNOC] e3xx_radio_ctrl_impl::_update_enables() > > [TRACE] [RFNOC] e3xx_radio_ctrl_impl::_update_gpio_state() > > Traceback (most recent call last): > File "./dave_addonly_usrp.py", line 169, in > main() > File "./dave_addonly_usrp.py", line 158, in main > tb = top_block_cls() > File "./dave_addonly_usrp.py", line 94, in __init__ > "addonly", -1, -1, > File "/home/root/localinstall/usr/lib/python2.7/site- > packages/ettus/ettus_swig.py", line 3270, in make > return _ettus_swig.rfnoc_generic_make(*args, **kwargs) > RuntimeError: Invalid stream args. > > It never gets to the part where it attempts to connect ports together. > > > The line in the Python launcher that generates the error is: > > self.dave_addonly_0 = ettus.rfnoc_generic( > self.device3, > uhd.stream_args( # TX Stream Args > cpu_format="fc32", # TODO: This must be made an option > otw_format="sc16", > channels=(0,1), > args="align=1", > ), > uhd.stream_args( # RX Stream Args > cpu_format="fc32", > otw_format="sc16", > channels=(0,1), > args="align=1", > ), > "addonly", -1, -1, > ) > > > Maybe
Re: [USRP-users] Using DmaFIFO for receive on X310
Thanks Michael, This info was very helpful. Regarding "recv_buff_size", I tried setting to 100M and received a warning that it could not do so because rmem_max was only 33M. Given that my rmem_max was set all along to 33M, would the recv_buff_size default to 33M or does it default to something lower such that I still need to set this device arg? Regarding cpufrequtils, I have done everything I can find to get the CPUs to stay at 3.5GHz. On Ubuntu 14.04, this worked well. And, I have tried to disable the intel_pstate driver with the appropriate grub setting, but I have not been successful in Ubuntu 18.04 at keeping the CPU freqs max-ed. Finally, regarding DPDK, this seems like the way to go, but with the limited amount of info available, it is difficult to get this properly configured. Rob On Mon, Sep 9, 2019 at 5:43 PM Michael West wrote: > Hi Rob, > > I would recommend not using the DMA FIFO block. Although the DMA FIFO > block should work, setting a larger socket buffer on the host or using DPDK > are much better options. To use a larger socket buffer, just use the > device argument "recv_buff_size=" and set the to something > reasonably large. > > As far as the Ds, there is flow control between the device and host, but > drops are still possible between the NIC and system memory if the host is > not releasing descriptors to the NIC fast enough. For some network cards, > this can be seen by looking at "rx_missed_errors" value in the output of > 'ethtool -S '. Increasing the number of RX descriptors helps, > but is limited. Use 'sudo ethtool -G rx 4096' to set the > descriptors to the maximum value. > > For the cpufreq utils, you may have to set the governor on each core (i.e. > cpufreq-set -g performance -c ). Also, if you have the intel_pstate > driver, it still may vary the CPU frequency with the performance governor. > > Regards, > Michael > > On Mon, Sep 9, 2019 at 1:41 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Nate, >> I looked at the link you sent (performance tuning tips) and your email. >> Here are a few comments / questions: >> >>- Regarding my initial question, what could be the cause of WORSE >>performance when I inserted the DmaFIFO in the receive chain of my RFNoC >>graph? Recall the "Radio->DDC->host" produces no errors, but >>"Radio->DDC->DmaFIFO->host" produces errors (timeouts) >>- Regarding "cpufrequtils" (from the performance tuning tips), I have >>run the suggestions on my 18.04 Ubuntu system (Xeon E5-1620v4 3.5GHz, >>4-core/8-thread), but when I run cpufreq-info, there is often 1 or more >>CPUs that show up at 1.6 GHz or so (while the majority report ~3.6 GHz). >>It is not clear to me whether this utility is doing its job or not. >>- Regarding DPDK, I have tried to install it, but have had no >>success. The instructions say that after updating grub with "iommu=pt >>intel_iommu=on hugepages=2048", then "After you reboot, you should see >>/sys/kernel/iommu_groups populated". I do have such a folder, but it is >>empty so I'm not sure if this step was successful or not. Furthermore, I >>am unable to run the dpdk-devbind python script to bind the vfio-pci >> driver >>to my Intel X520-DA2 NIC (see error message below) >>- Regarding XFS vs EXT4, this is something I haven't tried yet, but >>plan to. I am completely unfamiliar with XFS. My SSD is actually 4 >>Samsung EVO 850 SATA SSDs in a software RAID-0 (using mdadm). If I copy a >>huge file from my RAM disk to the SSD, I am able to verify transfer rates >>greater than 1GB/s (I believe closer to 1.5GB/s). >>- Finally, regarding "D" (sequence errors), what is the possible >>cause? These are the most frustrating errors because their cause is a >>mystery to me. I fully expect that when my host PC is too slow to keep up >>with the torrent of data coming from the USRP that it should eventually >>backpressure all the way to the Radio which will then generate Overflows >>because it has no place to send the A/D data. So, if I was only seeing >>"O", it would make sense to me. But, the "D" makes no sense to me in my >>point-to-point direct connection between host and USRP. Do you know of >> any >>root cause for "D"? >> >> Thanks. >> Rob >> >> *DPDK error messages during dpdk-devbind.py* >> irisheyes0@irisheyes0-HP-Z440-Workstation:~$ >> /usr/share/dpdk/usertools/dpdk-devbind.py --status >> >> Network devices using DPDK-compatible driver >> >> >> >> Network devices using kernel driver >> === >> :00:19.0 'Ethernet Connection (2) I218-LM 15a0' if=eno1 drv=e1000e >> unused= *Active* >> :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> if=ens4f0 drv=ixgbe unused= >> :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> if=ens4f1 drv=ixgbe unused= >>
Re: [USRP-users] Using DmaFIFO for receive on X310
Hi Rob, I would recommend not using the DMA FIFO block. Although the DMA FIFO block should work, setting a larger socket buffer on the host or using DPDK are much better options. To use a larger socket buffer, just use the device argument "recv_buff_size=" and set the to something reasonably large. As far as the Ds, there is flow control between the device and host, but drops are still possible between the NIC and system memory if the host is not releasing descriptors to the NIC fast enough. For some network cards, this can be seen by looking at "rx_missed_errors" value in the output of 'ethtool -S '. Increasing the number of RX descriptors helps, but is limited. Use 'sudo ethtool -G rx 4096' to set the descriptors to the maximum value. For the cpufreq utils, you may have to set the governor on each core (i.e. cpufreq-set -g performance -c ). Also, if you have the intel_pstate driver, it still may vary the CPU frequency with the performance governor. Regards, Michael On Mon, Sep 9, 2019 at 1:41 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Nate, > I looked at the link you sent (performance tuning tips) and your email. > Here are a few comments / questions: > >- Regarding my initial question, what could be the cause of WORSE >performance when I inserted the DmaFIFO in the receive chain of my RFNoC >graph? Recall the "Radio->DDC->host" produces no errors, but >"Radio->DDC->DmaFIFO->host" produces errors (timeouts) >- Regarding "cpufrequtils" (from the performance tuning tips), I have >run the suggestions on my 18.04 Ubuntu system (Xeon E5-1620v4 3.5GHz, >4-core/8-thread), but when I run cpufreq-info, there is often 1 or more >CPUs that show up at 1.6 GHz or so (while the majority report ~3.6 GHz). >It is not clear to me whether this utility is doing its job or not. >- Regarding DPDK, I have tried to install it, but have had no >success. The instructions say that after updating grub with "iommu=pt >intel_iommu=on hugepages=2048", then "After you reboot, you should see >/sys/kernel/iommu_groups populated". I do have such a folder, but it is >empty so I'm not sure if this step was successful or not. Furthermore, I >am unable to run the dpdk-devbind python script to bind the vfio-pci driver >to my Intel X520-DA2 NIC (see error message below) >- Regarding XFS vs EXT4, this is something I haven't tried yet, but >plan to. I am completely unfamiliar with XFS. My SSD is actually 4 >Samsung EVO 850 SATA SSDs in a software RAID-0 (using mdadm). If I copy a >huge file from my RAM disk to the SSD, I am able to verify transfer rates >greater than 1GB/s (I believe closer to 1.5GB/s). >- Finally, regarding "D" (sequence errors), what is the possible >cause? These are the most frustrating errors because their cause is a >mystery to me. I fully expect that when my host PC is too slow to keep up >with the torrent of data coming from the USRP that it should eventually >backpressure all the way to the Radio which will then generate Overflows >because it has no place to send the A/D data. So, if I was only seeing >"O", it would make sense to me. But, the "D" makes no sense to me in my >point-to-point direct connection between host and USRP. Do you know of any >root cause for "D"? > > Thanks. > Rob > > *DPDK error messages during dpdk-devbind.py* > irisheyes0@irisheyes0-HP-Z440-Workstation:~$ > /usr/share/dpdk/usertools/dpdk-devbind.py --status > > Network devices using DPDK-compatible driver > > > > Network devices using kernel driver > === > :00:19.0 'Ethernet Connection (2) I218-LM 15a0' if=eno1 drv=e1000e > unused= *Active* > :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' > if=ens4f0 drv=ixgbe unused= > :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' > if=ens4f1 drv=ixgbe unused= > :04:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' > if=ens2f0 drv=ixgbe unused= > :04:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' > if=ens2f1 drv=ixgbe unused= > > Other Network devices > = > > > Crypto devices using DPDK-compatible driver > === > > > Crypto devices using kernel driver > == > > > Other Crypto devices > > > > Eventdev devices using DPDK-compatible driver > = > > > Eventdev devices using kernel driver > > > > Other Eventdev devices > == > > > Mempool devices using DPDK-compatible driver > > > > Mempool devices using kernel driver > === > > > Other Mempool devices > = > >
Re: [USRP-users] Using DmaFIFO for receive on X310
Hi Nate, I looked at the link you sent (performance tuning tips) and your email. Here are a few comments / questions: - Regarding my initial question, what could be the cause of WORSE performance when I inserted the DmaFIFO in the receive chain of my RFNoC graph? Recall the "Radio->DDC->host" produces no errors, but "Radio->DDC->DmaFIFO->host" produces errors (timeouts) - Regarding "cpufrequtils" (from the performance tuning tips), I have run the suggestions on my 18.04 Ubuntu system (Xeon E5-1620v4 3.5GHz, 4-core/8-thread), but when I run cpufreq-info, there is often 1 or more CPUs that show up at 1.6 GHz or so (while the majority report ~3.6 GHz). It is not clear to me whether this utility is doing its job or not. - Regarding DPDK, I have tried to install it, but have had no success. The instructions say that after updating grub with "iommu=pt intel_iommu=on hugepages=2048", then "After you reboot, you should see /sys/kernel/iommu_groups populated". I do have such a folder, but it is empty so I'm not sure if this step was successful or not. Furthermore, I am unable to run the dpdk-devbind python script to bind the vfio-pci driver to my Intel X520-DA2 NIC (see error message below) - Regarding XFS vs EXT4, this is something I haven't tried yet, but plan to. I am completely unfamiliar with XFS. My SSD is actually 4 Samsung EVO 850 SATA SSDs in a software RAID-0 (using mdadm). If I copy a huge file from my RAM disk to the SSD, I am able to verify transfer rates greater than 1GB/s (I believe closer to 1.5GB/s). - Finally, regarding "D" (sequence errors), what is the possible cause? These are the most frustrating errors because their cause is a mystery to me. I fully expect that when my host PC is too slow to keep up with the torrent of data coming from the USRP that it should eventually backpressure all the way to the Radio which will then generate Overflows because it has no place to send the A/D data. So, if I was only seeing "O", it would make sense to me. But, the "D" makes no sense to me in my point-to-point direct connection between host and USRP. Do you know of any root cause for "D"? Thanks. Rob *DPDK error messages during dpdk-devbind.py* irisheyes0@irisheyes0-HP-Z440-Workstation:~$ /usr/share/dpdk/usertools/dpdk-devbind.py --status Network devices using DPDK-compatible driver Network devices using kernel driver === :00:19.0 'Ethernet Connection (2) I218-LM 15a0' if=eno1 drv=e1000e unused= *Active* :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens4f0 drv=ixgbe unused= :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens4f1 drv=ixgbe unused= :04:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens2f0 drv=ixgbe unused= :04:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens2f1 drv=ixgbe unused= Other Network devices = Crypto devices using DPDK-compatible driver === Crypto devices using kernel driver == Other Crypto devices Eventdev devices using DPDK-compatible driver = Eventdev devices using kernel driver Other Eventdev devices == Mempool devices using DPDK-compatible driver Mempool devices using kernel driver === Other Mempool devices = irisheyes0@irisheyes0-HP-Z440-Workstation:~$ sudo /usr/share/dpdk/usertools/dpdk-devbind.py --bind=vfio-pci 01:00.0 [sudo] password for irisheyes0: Error - no supported modules(DPDK driver) are loaded irisheyes0@irisheyes0-HP-Z440-Workstation:~$ /usr/share/dpdk/usertools/dpdk-devbind.py --status Network devices using DPDK-compatible driver Network devices using kernel driver === :00:19.0 'Ethernet Connection (2) I218-LM 15a0' if=eno1 drv=e1000e unused= *Active* :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens4f0 drv=ixgbe unused= :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens4f1 drv=ixgbe unused= :04:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens2f0 drv=ixgbe unused= :04:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens2f1 drv=ixgbe unused= Other Network devices = Crypto devices using DPDK-compatible driver === Crypto devices using kernel driver == Other Crypto devices Eventdev devices using DPDK-compatible driver = Eventdev devices using
[USRP-users] Error running 1024 pt FFT block on N310
Hi, I am having trouble running the FFT block of size 1024 on an N310. I am using the "rfnoc_rx_to_file" example program (UHD v3.14.1.0) to run it. It works with size 256 or 512. Additionally, I am able to run with 1024 if I switch to an X310 (same PC). Please let me know if you have any ideas... Rob *Here is the command that fails:* rfnoc_rx_to_file --args="type=n3xx" --nsamps=65536 --block-id=FFT_0 --block-args="spp=1024" --rate=125e6 --freq=2400e6 --radio-args="spp=1024" *The following is the output with error message:* Using radio 0, channel 0 Setting RX Rate: 125.00 Msps... Actual RX Rate: 125.00 Msps... Setting RX Freq: 2400.00 MHz... Actual RX Freq: 2400.00 MHz... Connecting 0/Radio_0 ==> 0/FFT_0 [WARNING] [RFNOC] Assuming max packet size for 0/Radio_0 Samples per packet: 1024 Using streamer args: block_id=0/FFT_0,spp=1024 Issuing stream cmd [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or packet fragment [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: Bad CHDR or packet fragment Error: Receiver error: ERROR_CODE_BAD_PACKET *Note that the following works fine with an X310* rfnoc_rx_to_file --args="type=x300" --nsamps=65536 --block-id=FFT_0 --block-args="spp=1024" --rate=100e6 --freq=2400e6 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase Sync between to UBX-160 Daugtherboards using RFNoC Radio
Hey,
sorry to post again, but I think this time I have a solution.
In my grc-generated python file I added the lines:
cmd_time_1 = self.sender_A.get_time_now() + uhd.time_spec_t(5.0)
self.uhd_rfnoc_streamer_fifo_0_0.set_start_time(cmd_time_1)
self.uhd_rfnoc_streamer_fifo_0.set_start_time(cmd_time_1)
Unfortunately this command did not do anything so i had to modify
rfnoc_block_impl.cc in the gr-ettus folder. I added:
#define BETTER
#ifdef BETTER
if (_start_time_set) {
_tx.metadata.has_time_spec = true;
_tx.metadata.time_spec = _start_time;
std::cout << "Patch: Start Time Stream inserted"<< std::endl;
}
else {
_tx.metadata.has_time_spec = false;
}
#endif
around line 300 after the commands
_tx.metadata.start_of_burst = false;
_tx.metadata.end_of_burst = false;
_tx.metadata.has_time_spec = false;
so that now the _start_time_set variable actually is used.
(I then of course used make and make install in the gr-ettus/build)
Now I get the desired behauviour and in addition can set a start time for
both my streams.
Kudos to this guy
https://discuss-gnuradio.gnu.narkive.com/joj8MDyW/gnu-radio-3-7-12-rfnoc-set-start-time
who used this, to correct the set_start_time command and I hoped that this
would also fix my random phase offset problem, which was the case.
Best Regards
Felix
> Hello together,
>
> I wanted to give you a short update about phase-synchronizing my
> USRPx310's ubx160 daugtherboards and clarify the problem I am facing for
> better understandig.
>
> I am using both TX-Ports of my USRP to transmit the same complex cosine
> generated with GNU-Radio. My image is a custom RFNoC image and contains
> 2xDDC, 2xDUC, 2xRadio,1xDMA-FIFO,1xAddsub and 2xFIFO. My center frequency
> is 2.45 GHz and the frequency of the cosine is 100 KHz.
>
> My flowgraph looks like this,
>
> SigSource--->RFNoC_FIFO_0--->DMA_FIFO--->RFNoC-DUC_0-->RFNoC_Radio_A
> || |
> -->RFNoC_FIFO_1--- --->RFNoC_DUC_1-->RFNoC_Radio_B
>
> and both antenna outputs are connected to an Agilent infiniium
> oscilloscope.
> Thus I can measure the phase offset between both of my output ports, by
> measuring the phase offset of both displayed cosines. My goal is to
> receive the same/almost the same relative phase offset with each new
> restart of the flowgraph. Sadly, using the RFNoC blocks, I get a different
> phase offset every time.
>
> When I use UHD-USRP Sink instead, (with the same Image and without RFNoC
> blocks) I do get a consistent phase offset between both ports with every
> restart of the flowgraph or even power cycles. This is the behaviour I
> want for my RFNoC Flowgraph as well; and because it is the same image, I
> am pretty sure there just must be a way to clone this behaviour to the
> RFNoC realm as well.
>
> My approach up till now was, to use timed commands in my GRC-generated
> python code for both RFnoC-Radio Blocks A and B, which each represent one
> daugtherboard, I think. I then put the .set_tx_freq commands in the code
> betweeen set_command time and clear_command time:
>
> #A.get_time_now equals B.get_time_now
> cmd_time = self.sender_A.get_time_now() + uhd.time_spec_t(0.1)
> self.sender_A.set_command_time(cmd_time)
> self.sender_B.set_command_time(cmd_time)
>
> Tuning Commands
> self.sender_A.set_tx_freq(c_freq, i)
> self.sender_B.set_tx_freq(c_freq, i)
> ---
>
> self.sender_A.clear_command_time(0)
> self.sender_B.clear_command_time(0)
> # End Timed Commands
>
> This approach however did not work for me.
>
> After my attempt with the timed commands failed, I tried to change all
> paramters. When I set the frequency of my cosine to zero I actually got a
> consistent phase offset. My conclusion is, that the mixers lock with a
> consistent relative phase offset every time, because DC Signals do not
> have relative phases. Because of that I think that maybe really both
> Radio-Blocks start streaming with a random time offset or something
> similar.
>
> Now to my questions
>
> 1) Is using the timed commands really the way to go? Remember I do NOT
> want to synchronize multiple USRP-Devices but only that both
> D-Boards/Radio-Blocks of one device, lock with the same relative phase.
>
> 2) Do I have to start the streaming manually somehow, with a timestamp or
> something similar? And when the answer is yes, how do I do it in python
> without the multi_usrp_api?
>
> 3) How can I control the start of streaming in my python code so that both
> RFNoC Radios start at the same time?
>
> 4) How does the UHD_USRP_Sink Block work? I mean is there a verilog code
> for it too and does it call the rfnoc_radio and rfnoc_duc modules etc.?
> What are the parameters for the UHD_USRP_Sink Blocks DMA_FIFO and DUC?
> I am asking this because I would like to clone that blocks behaviour
>
> 5) Any other question that I am not smart enough to ask but that deserves
> an answer either way :D
>
> Again, any help is greatly appreciated
Re: [USRP-users] Detection of USRP X310
Hi Sam, Thanks for your kind words. Firstly, it had detection problems. Even, after writing FPGA image nothing happened. There were no indications, that it failed. I assumed it is dead, since after successful image writing, nothing happened. I waited for sometime, maybe after I wrote email, I tried one more time. It successfully loaded the image and usrp was back to life. But, I am still wondering, if this has impacted USRP(Which is presumably problematic). I am trying to emulate it via Open source LTE software and I see from logs, that the software sends signal to the radio via physical layer. But, there is no wireless network created. Multiple COTS devices didn't detect it, in spite of all the correct configurations (After the first failure, I am not able to get the network somehow). Summarizing, does device recovery affect the working of device? If multiple times, it's recovered, what impact or implications, it might have? This is a good starting point to analyze, in my opinion. Regards, Saimanoj On Thu, Sep 5, 2019 at 11:03 PM Sam Reiter wrote: > Saimanoj, > > Depending on which red lights you're talking about, that's not necessarily > indicative of an issue. > > Can you tell me a bit more about what was going on when you had the issue? > Were you trying to write an FPGA image to the device, or did it just die > out of nowhere? > > Additionally, I'd like to know if you experience any issues during the > jtag process. Screenshots are always helpful. > > Sam Reiter > SDR Support Engineer > Ettus Research > > > On Tue, Sep 3, 2019 at 2:52 AM Saimanoj Katta > wrote: > >> Hi Sam, >> >> Thank you for the information. Yes, you were right. I didn't see the LEDs >> on the SFP port illuminating. I followed your instructions and the USRP >> worked like a charm for all these days. >> >> However, I didn't have any issues until yesterday. Yesterday, it suddenly >> stopped working. I could see the Red LED lights from the side and from my >> earlier observation(as LEDs were not illuminating in SFP port), I concluded >> it to be in the earlier state. I tried reprogramming the same way and it >> doesn't work now. Any further points on how to bring back the device to the >> normal state? I am still hopeful of it getting fixed. >> >> Looking forward to your reply. Thank you for your time and consideration. >> >> Regards, >> Saimanoj >> >> On Tue, Jul 23, 2019 at 11:59 PM Sam Reiter wrote: >> >>> When you plug in either link, do you see the LEDs on the SFP ports >>> illuminate? You may have bricked the X310 if these ports are unresponsive. >>> >>> Here's a *discovery* guide that might be helpful: >>> https://kb.ettus.com/Troubleshooting_X300/X310_Device_Discovery_Issues >>> >>> Here's a *recovery* guide if that fails: >>> https://kb.ettus.com/X300/X310_Device_Recovery >>> >>> Best, >>> >>> Sam Reiter >>> SDR Support Engineer >>> Ettus Research >>> >>> >>> On Fri, Jul 19, 2019 at 6:03 AM Saimanoj Katta via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Hi, I was previously working with the USRP X310. I wanted to enable Dual Connectivity mode for enabling two ports with 10 Giga bit connectivity. I ran the update: uhd_image_loader --args "type=x300,addr=192.168.50.2, fpga=XG". Since this, I have not been able to detect my USRP. *My setup: * Ubuntu is 18.04 and the UHD version is UHD_3.14.1.0-0-gbfb9c1c7 I have connected to the laptop via thunderbolt port which is equivalent to USB-3.0. Firewall is disabled. It is not behind a router/switch. Host interface IP address is 192.168.10.3 and subnet is 255.255.255.0 I have tried the following: 1) Ran as root user - uhd_find_devices, uhd_usrp_probe and uhd_images_downloader. Device is not found in first two options. And, the fpga_default images seem to be up to date. 2) By default, USRPs have addresses from the 192.168.10.XXX range ( XXX=2 in factory settings). I searched addresses in this range, but still USRP not detected. Ping to the address also fails. Any suggestions would be appreciated to detect the device! Many thanks in advance. Regards, Saimanoj ___ 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
