[USRP-users] USRP B200 Mini as donation required

[Babar Ali via USRP-users]

Hi Every one 
 I am student of MS telecommunication and working on project based on GSM 
security, as the time of need I am looking for USRP B200 mini board, as due to 
high price of this product and my limited budget I cannot buy this one, as 
requesting some would please donate this board.
If someone interested to donate please email me.
Thank You 
Regards 
Ali___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathon,

I have identified the cause of this problem as being chdr_framer.v. It appears 
to not be adhering to the axi_stream protocol and is holding onto packets until 
the fifo is full even when o_tready is asserted, causing the described behavior.

The root cause is the switch to axi_fifo_flop2 for the header fifo (changed 
with commit that eb0ae36). The problem is fixed completely by switching this 
back to an axi_fifo_short.

Thanks,

Sam
On Oct 25, 2018, 7:36 PM -0700, Samuel Prager , wrote:
> Hey Jonathon,
>
> I had a chance to debug this a little further (On an N300) and have observed 
> the following behavior:
>
> The command packets are getting through to the radio block but are being 
> buffered somewhere along the line so that the first command is either not 
> received or not processed until exactly 16 have been sent.
>
> So if I am sending commands in a loop, there is a 16 command delay before the 
> settings bus writes and a rx command is triggered in the radio.
>
> This seems to indicate that there is a buffer somewhere that doesn’t pass the 
> commands until it is full.
>
> Any thoughts on what the culprit could be?
>
> Sam
> On Oct 23, 2018, 11:17 PM -0700, Jon Pendlum , wrote:
> > Hey Sam,
> >
> > There have been some changes to noc_shell, maybe they are related to your 
> > issue. If you want to try to debug this on the FPGA, I suggest using 
> > chipscope on the file cmd_pkt_proc.v. That is the state machine that 
> > receives command packets and issues settings bus writes. You should be able 
> > to see your command packets come in and get processed by the state machine. 
> > You can double check the command packet / timed command vita time versus 
> > the radio core's vita time. You can also see if the state machine gets 
> > stuck in a certain state.
> >
> > Jonathon
> >
> > > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager  wrote:
> > > > Hi Jonathan,
> > > >
> > > > Just following up on this. I have switched to the UHD 3.13 release + 
> > > > FPGA version 5.2. This issue still persists.
> > > >
> > > > Is it possible that a change to UHD could be causing this to not work?
> > > >
> > > > If anyone can confirm that they are able to send commands to the radio 
> > > > block from an rfnoc block in recent versions of UHD it would help a lot.
> > > >
> > > > Thanks,
> > > >
> > > > Sam
> > > >
> > > > On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , wrote:
> > > > > Hi Jonathan,
> > > > >
> > > > > Yes I add my block and the radio block, connect them and tell my 
> > > > > block to send commands to radio block. I have confirmed today that 
> > > > > the simulation still works correctly in Vivado 2017.4 — the settings 
> > > > > registers are written as expected, an rx command is generated in the 
> > > > > radio and the correct number of samples are streamed back into the 
> > > > > tb_streamer.
> > > > >
> > > > > Sam
> > > > > On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum , 
> > > > > wrote:
> > > > > > How does your testbench work? Do you add the radio core block, send 
> > > > > > timed commands to it, and see the outputs toggle?
> > > > > >
> > > > > > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  
> > > > > > > wrote:
> > > > > > > > Hi Jonathon,
> > > > > > > >
> > > > > > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. 
> > > > > > > > Thanks for sharing your code — the only real difference I see 
> > > > > > > > is that you increment the seq_num. I am leaving it as 12’b0 — 
> > > > > > > > could this be causing an issue?
> > > > > > > >
> > > > > > > > I should also say that In my case, the command packets are 
> > > > > > > > being sent to the radio block to trigger timed receive commands 
> > > > > > > > in order to reduce the number of software sr_writes.
> > > > > > > >
> > > > > > > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2.
> > > > > > > >
> > > > > > > > This is something that was simulated/verified and worked in the 
> > > > > > > > past, but perhaps a change has been made that prevents this 
> > > > > > > > from working?
> > > > > > > >
> > > > > > > > I will try a release tag as soon as possible — however this is 
> > > > > > > > something I’ve been seeing for a couple of months now that has 
> > > > > > > > kept me on pre-2017.4 releases.
> > > > > > > >
> > > > > > > > Sam
> > > > > > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum 
> > > > > > > > , wrote:
> > > > > > > > > Hi Sam,
> > > > > > > > >
> > > > > > > > > I am using command packets to tune the DDC block's DSP 
> > > > > > > > > frequency. Are you using ce_clk and ce_rst for clock and 
> > > > > > > > > reset? Here is my code if you want to take a look: 
> > > > > > > > > https://pastebin.com/1AeHFb0J. Also, it might be worth trying 
> > > > > > > > > your code on a release tag like v3.13.0.2 in case master has 
> > > > > > > > > a regression.
> > > > > > > > >
> > > > > > > > > Jonathon
> > > > > > > > >
> > > > > > > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel 

Re: [USRP-users] RFNoC Replay block for E310?

[Wade Fife via USRP-users]

Hi Rob,

The Replay block was only tested with X310/N310. E310 doesn't have the PL
DRAM connected like it is on those products. In theory the Replay block
could be used on E310, but it hasn't been tried. It would take some work to
get the memory interface set up and connected to the Replay block (you
would want to hook it up similarly to how its done on X310/N310), and there
might be resource challenges depending on what you're trying to fit in the
design. But I'm not aware of a specific reason why it couldn't work.

Thanks,

Wade

On Mon, Oct 29, 2018 at 10:26 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I have successfully compiled & used the RFNoC replay block with an X310.
> Now, I would like to do the same with an E310.  After some quick
> investigation, I noticed that the "use_replay" logic has been included in
> both "n3xx_core.v" and "x300_core.v" but not in "e310_core.v" or any other
> E310 verilog files.  I also noticed that application note AN-642, Using
> the RFNoC Replay Block ,
> specifically mentions support for the X300/X310 and N310, but no mention of
> the E310.
>
> I'm wondering if I just need to modify "e310_core.v" to implement similar
> logic to that in "n3xx_core.v" and/or "x300_core.v" in order to get this
> working on the E310?  Or, is there some reason that this will not work such
> that I am wasting my time?
>
> Thanks.
> Rob
> ___
> 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] UHD performance on Odroid XU4 with B210

[Marcus D. Leech via USRP-users]

On 10/30/2018 01:30 PM, Vladimir via USRP-users wrote:

Hi all,

We are trying to run UHD on Odroid XU4 which has Samsung Exynos 5244 
(4xA15 cores @ 2 GHz + 4xA7 cores @ 1.4 GHz with NEON support) and USB 
3.0 onboard. UHD version is 003.010.002. We managed to build it 
(essentially just having added compiler flags to enable neon support), 
and it is able to run rx_samples_to_file at 20 MHz (w/o storing, since 
SD is not fast at all), but trying to run


rx_samples_to_file --rate 30e6 --freq 1e9 --null

I get permanent OOO series from the very capture start. Did anyone 
succeed to run the capture on XU4 at 30 MSps? With htop I can see that 
the example runs on lower 4 cores of XU4 which are low-rate A7 cores 
(it uses them at average 50% though). Is it possible to force it to 
run on high-power cores?


I tried to put 4 lower cores offline, but then rx_samples_to_file 
freezes the whole system after printing "Waiting for "lo_locked": 
++" (the following " locked." never gets printed, and all 
other remote connections to the system freeze; only power cycle helps).


What is the decent way to test usb3 input speed with such a setup?

Vladimir
In my experience with the XU4Q, you're unlikely to achieve 30Msps. Make 
sure your heatsink is large, otherwise, the CPU will throttle

  down to protect itself.

You cannot expect these ARM CPUs to perform at the same levels as 
high-end desktop X86 systems.





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

[USRP-users] UHD performance on Odroid XU4 with B210

[Vladimir via USRP-users]

Hi all,

We are trying to run UHD on Odroid XU4 which has Samsung Exynos 5244 (4xA15 
cores @ 2 GHz + 4xA7 cores @ 1.4 GHz with NEON support) and USB 3.0 onboard. 
UHD version is 003.010.002. We managed to build it (essentially just having 
added compiler flags to enable neon support), and it is able to run 
rx_samples_to_file at 20 MHz (w/o storing, since SD is not fast at all), but 
trying to run

rx_samples_to_file --rate 30e6 --freq 1e9 --null

I get permanent OOO series from the very capture start. Did anyone succeed 
to run the capture on XU4 at 30 MSps? With htop I can see that the example runs 
on lower 4 cores of XU4 which are low-rate A7 cores (it uses them at average 
50% though). Is it possible to force it to run on high-power cores?

I tried to put 4 lower cores offline, but then rx_samples_to_file freezes the 
whole system after printing "Waiting for "lo_locked": ++" (the 
following " locked." never gets printed, and all other remote connections to 
the system freeze; only power cycle helps).

What is the decent way to test usb3 input speed with such a setup?

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

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Daniel May via USRP-users]

Marcus,

Thanks for the info. Waiting is what we do now, but it's not ideal.

The "skip_dram=1"argument fixes the issue for low sample rates, but causes
underflows for higher sample rates, as expected.

Thanks,
Daniel



On Tue, Oct 30, 2018 at 10:25 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote:
>
> Is there a way to query the amount of data in the FIFO so that I can wait
> until it clears?
>
> I don't believe so.
>
> You could simply wait an amount of time, based on empirical data, that is
> commensurate with your sample rate.
>
> But the whole "the next run causes fatal errors" thing does need to be
> investigated, I agree.
>
>
>
> On Tue, Oct 30, 2018 at 9:37 AM Rob Kossler  wrote:
>
>> The DRAM is 2GB, I think.
>>
>> On Tue, Oct 30, 2018 at 10:34 AM Daniel May 
>> wrote:
>>
>>> Thanks, I'll give that a try. I thought it might be the FIFO clearing,
>>> but it takes longer than I would expect. There's only 512kB of FIFO,
>>> correct? It takes up to several seconds to finish at a 1 Msps rate.
>>>
>>> Restarting the radio before Tx completes causes the radio to enter an
>>> unrecoverable error state. This is a UHD or Firmware bug, correct?
>>>
>>> Thanks,
>>> Daniel
>>>
>>> On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler  wrote:
>>>
 It sounds like the DMA FIFO is just emptying out.  For fast sample
 rates, the FIFO empties quickly, but for slow sample rates, it empties
 slowly.  Perhaps you could supply the arg "skip_dram=1" so that the
 streaming goes directly to the DUC rather than through the FIFO.  This will
 probably work fine for slow sample rates (i.e., perhaps a FIFO is not
 needed for such rates).
 Rob

 On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> All,
>
> Can anyone else reproduce this issue and/or suggest a solution?
>
> This is happening over the Ethernet interface as well. Application
> exits, Tx light stays on, relaunching application causes X310 to enter an
> unrecoverable state and requires power cycling. It looks like an issue 
> with
> initializing DMA. Tested using v3.13.0.1.
>
> Thanks,
> Daniel
>
> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> All,
>>
>>
>>
>> I am using an Ettus x310 over PCIe and am noticing that there is a
>> delay from when my program finished sending to the radio and when the 
>> radio
>> tells me that transmission as ended ( the red Tx light turning off).
>>
>> As I bump up the sample rate I notice this delay decreases until it
>> is nonexistent. Is this intended behavior or have I done something wrong 
>> in
>> my tests? The procedure to test this is listed below:
>>
>>
>>
>> 1.   Download a copy of the official UHD example scripts from
>> https://github.com/EttusResearch/uhd/tree/master/host/examples
>>
>> 2.   Ensure that UHD is installed correctly on your testing
>> device and build the example programs above
>>
>> 3.   Run the following command “ ./tx_waveforms - -rate=100
>> - -freq=15
>>
>> 4.   Stop the program at any time (how long the radio is running
>> does not affect the delay)
>>
>> 5.   Observe the radio and notice that the red light under the
>> Tx/Rx port is still lit on the RF A channel
>>
>> 6.   If you start another transmission while the light is still
>> red, the console output contains hundreds of thousands of L’s and the 
>> radio
>> will not receive data until the USRP object is recreated.
>>
>>
>>
>> I am also curious if there is a hard stop functionality for this
>> radio. All the examples I have seen send an End of Burst packet but is
>> there a way to completely halt the radio without doing this?
>>
>>
>>
>> Thanks for the help!
>>
>> Andrew
>> ___
>> 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 mailing 
> listUSRP-users@lists.ettus.comhttp://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 mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Brian Padalino via USRP-users]

On Tue, Oct 30, 2018 at 11:25 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote:
>
> Is there a way to query the amount of data in the FIFO so that I can wait
> until it clears?
>
> I don't believe so.
>

There's a method in the core (host side code and FPGA code) but it isn't
brought out to the controller:


https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L168

The controller is here:


https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp

Add a method and you should be able to, using RFNoC, query the current FIFO
usage.

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

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Daniel May via USRP-users]

Is there a way to query the amount of data in the FIFO so that I can wait
until it clears?

On Tue, Oct 30, 2018 at 9:37 AM Rob Kossler  wrote:

> The DRAM is 2GB, I think.
>
> On Tue, Oct 30, 2018 at 10:34 AM Daniel May  wrote:
>
>> Thanks, I'll give that a try. I thought it might be the FIFO clearing,
>> but it takes longer than I would expect. There's only 512kB of FIFO,
>> correct? It takes up to several seconds to finish at a 1 Msps rate.
>>
>> Restarting the radio before Tx completes causes the radio to enter an
>> unrecoverable error state. This is a UHD or Firmware bug, correct?
>>
>> Thanks,
>> Daniel
>>
>> On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler  wrote:
>>
>>> It sounds like the DMA FIFO is just emptying out.  For fast sample
>>> rates, the FIFO empties quickly, but for slow sample rates, it empties
>>> slowly.  Perhaps you could supply the arg "skip_dram=1" so that the
>>> streaming goes directly to the DUC rather than through the FIFO.  This will
>>> probably work fine for slow sample rates (i.e., perhaps a FIFO is not
>>> needed for such rates).
>>> Rob
>>>
>>> On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 All,

 Can anyone else reproduce this issue and/or suggest a solution?

 This is happening over the Ethernet interface as well. Application
 exits, Tx light stays on, relaunching application causes X310 to enter an
 unrecoverable state and requires power cycling. It looks like an issue with
 initializing DMA. Tested using v3.13.0.1.

 Thanks,
 Daniel

 On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> All,
>
>
>
> I am using an Ettus x310 over PCIe and am noticing that there is a
> delay from when my program finished sending to the radio and when the 
> radio
> tells me that transmission as ended ( the red Tx light turning off).
>
> As I bump up the sample rate I notice this delay decreases until it is
> nonexistent. Is this intended behavior or have I done something wrong in 
> my
> tests? The procedure to test this is listed below:
>
>
>
> 1.   Download a copy of the official UHD example scripts from
> https://github.com/EttusResearch/uhd/tree/master/host/examples
>
> 2.   Ensure that UHD is installed correctly on your testing
> device and build the example programs above
>
> 3.   Run the following command “ ./tx_waveforms - -rate=100 -
> -freq=15
>
> 4.   Stop the program at any time (how long the radio is running
> does not affect the delay)
>
> 5.   Observe the radio and notice that the red light under the
> Tx/Rx port is still lit on the RF A channel
>
> 6.   If you start another transmission while the light is still
> red, the console output contains hundreds of thousands of L’s and the 
> radio
> will not receive data until the USRP object is recreated.
>
>
>
> I am also curious if there is a hard stop functionality for this
> radio. All the examples I have seen send an End of Burst packet but is
> there a way to completely halt the radio without doing this?
>
>
>
> Thanks for the help!
>
> Andrew
> ___
> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Rob Kossler via USRP-users]

The DRAM is 2GB, I think.

On Tue, Oct 30, 2018 at 10:34 AM Daniel May  wrote:

> Thanks, I'll give that a try. I thought it might be the FIFO clearing, but
> it takes longer than I would expect. There's only 512kB of FIFO, correct?
> It takes up to several seconds to finish at a 1 Msps rate.
>
> Restarting the radio before Tx completes causes the radio to enter an
> unrecoverable error state. This is a UHD or Firmware bug, correct?
>
> Thanks,
> Daniel
>
> On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler  wrote:
>
>> It sounds like the DMA FIFO is just emptying out.  For fast sample rates,
>> the FIFO empties quickly, but for slow sample rates, it empties slowly.
>> Perhaps you could supply the arg "skip_dram=1" so that the streaming goes
>> directly to the DUC rather than through the FIFO.  This will probably work
>> fine for slow sample rates (i.e., perhaps a FIFO is not needed for such
>> rates).
>> Rob
>>
>> On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> All,
>>>
>>> Can anyone else reproduce this issue and/or suggest a solution?
>>>
>>> This is happening over the Ethernet interface as well. Application
>>> exits, Tx light stays on, relaunching application causes X310 to enter an
>>> unrecoverable state and requires power cycling. It looks like an issue with
>>> initializing DMA. Tested using v3.13.0.1.
>>>
>>> Thanks,
>>> Daniel
>>>
>>> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 All,



 I am using an Ettus x310 over PCIe and am noticing that there is a
 delay from when my program finished sending to the radio and when the radio
 tells me that transmission as ended ( the red Tx light turning off).

 As I bump up the sample rate I notice this delay decreases until it is
 nonexistent. Is this intended behavior or have I done something wrong in my
 tests? The procedure to test this is listed below:



 1.   Download a copy of the official UHD example scripts from
 https://github.com/EttusResearch/uhd/tree/master/host/examples

 2.   Ensure that UHD is installed correctly on your testing device
 and build the example programs above

 3.   Run the following command “ ./tx_waveforms - -rate=100 -
 -freq=15

 4.   Stop the program at any time (how long the radio is running
 does not affect the delay)

 5.   Observe the radio and notice that the red light under the
 Tx/Rx port is still lit on the RF A channel

 6.   If you start another transmission while the light is still
 red, the console output contains hundreds of thousands of L’s and the radio
 will not receive data until the USRP object is recreated.



 I am also curious if there is a hard stop functionality for this radio.
 All the examples I have seen send an End of Burst packet but is there a way
 to completely halt the radio without doing this?



 Thanks for the help!

 Andrew
 ___
 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Daniel May via USRP-users]

Thanks, I'll give that a try. I thought it might be the FIFO clearing, but
it takes longer than I would expect. There's only 512kB of FIFO, correct?
It takes up to several seconds to finish at a 1 Msps rate.

Restarting the radio before Tx completes causes the radio to enter an
unrecoverable error state. This is a UHD or Firmware bug, correct?

Thanks,
Daniel

On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler  wrote:

> It sounds like the DMA FIFO is just emptying out.  For fast sample rates,
> the FIFO empties quickly, but for slow sample rates, it empties slowly.
> Perhaps you could supply the arg "skip_dram=1" so that the streaming goes
> directly to the DUC rather than through the FIFO.  This will probably work
> fine for slow sample rates (i.e., perhaps a FIFO is not needed for such
> rates).
> Rob
>
> On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> All,
>>
>> Can anyone else reproduce this issue and/or suggest a solution?
>>
>> This is happening over the Ethernet interface as well. Application exits,
>> Tx light stays on, relaunching application causes X310 to enter an
>> unrecoverable state and requires power cycling. It looks like an issue with
>> initializing DMA. Tested using v3.13.0.1.
>>
>> Thanks,
>> Daniel
>>
>> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> All,
>>>
>>>
>>>
>>> I am using an Ettus x310 over PCIe and am noticing that there is a delay
>>> from when my program finished sending to the radio and when the radio tells
>>> me that transmission as ended ( the red Tx light turning off).
>>>
>>> As I bump up the sample rate I notice this delay decreases until it is
>>> nonexistent. Is this intended behavior or have I done something wrong in my
>>> tests? The procedure to test this is listed below:
>>>
>>>
>>>
>>> 1.   Download a copy of the official UHD example scripts from
>>> https://github.com/EttusResearch/uhd/tree/master/host/examples
>>>
>>> 2.   Ensure that UHD is installed correctly on your testing device
>>> and build the example programs above
>>>
>>> 3.   Run the following command “ ./tx_waveforms - -rate=100 -
>>> -freq=15
>>>
>>> 4.   Stop the program at any time (how long the radio is running
>>> does not affect the delay)
>>>
>>> 5.   Observe the radio and notice that the red light under the
>>> Tx/Rx port is still lit on the RF A channel
>>>
>>> 6.   If you start another transmission while the light is still
>>> red, the console output contains hundreds of thousands of L’s and the radio
>>> will not receive data until the USRP object is recreated.
>>>
>>>
>>>
>>> I am also curious if there is a hard stop functionality for this radio.
>>> All the examples I have seen send an End of Burst packet but is there a way
>>> to completely halt the radio without doing this?
>>>
>>>
>>>
>>> Thanks for the help!
>>>
>>> Andrew
>>> ___
>>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Rob Kossler via USRP-users]

It sounds like the DMA FIFO is just emptying out.  For fast sample rates,
the FIFO empties quickly, but for slow sample rates, it empties slowly.
Perhaps you could supply the arg "skip_dram=1" so that the streaming goes
directly to the DUC rather than through the FIFO.  This will probably work
fine for slow sample rates (i.e., perhaps a FIFO is not needed for such
rates).
Rob

On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
usrp-users@lists.ettus.com> wrote:

> All,
>
> Can anyone else reproduce this issue and/or suggest a solution?
>
> This is happening over the Ethernet interface as well. Application exits,
> Tx light stays on, relaunching application causes X310 to enter an
> unrecoverable state and requires power cycling. It looks like an issue with
> initializing DMA. Tested using v3.13.0.1.
>
> Thanks,
> Daniel
>
> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> All,
>>
>>
>>
>> I am using an Ettus x310 over PCIe and am noticing that there is a delay
>> from when my program finished sending to the radio and when the radio tells
>> me that transmission as ended ( the red Tx light turning off).
>>
>> As I bump up the sample rate I notice this delay decreases until it is
>> nonexistent. Is this intended behavior or have I done something wrong in my
>> tests? The procedure to test this is listed below:
>>
>>
>>
>> 1.   Download a copy of the official UHD example scripts from
>> https://github.com/EttusResearch/uhd/tree/master/host/examples
>>
>> 2.   Ensure that UHD is installed correctly on your testing device
>> and build the example programs above
>>
>> 3.   Run the following command “ ./tx_waveforms - -rate=100 -
>> -freq=15
>>
>> 4.   Stop the program at any time (how long the radio is running
>> does not affect the delay)
>>
>> 5.   Observe the radio and notice that the red light under the Tx/Rx
>> port is still lit on the RF A channel
>>
>> 6.   If you start another transmission while the light is still red,
>> the console output contains hundreds of thousands of L’s and the radio will
>> not receive data until the USRP object is recreated.
>>
>>
>>
>> I am also curious if there is a hard stop functionality for this radio.
>> All the examples I have seen send an End of Burst packet but is there a way
>> to completely halt the radio without doing this?
>>
>>
>>
>> Thanks for the help!
>>
>> Andrew
>> ___
>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] use multiple X310 USRPs with the RFNOC system in a single host system with gnuradio

[Mitterer, Tobias via USRP-users]

Hello,

We couldn't find any examples or older questions in this mailing list 
pertaining our problem. We want to use multiple (for starters 2) X310 USRP 
devices and control them from one host via gnuradio. (pps and sync are 
connected daisy chain at the moment but will be connected via octoclock at a 
later time).
The question now is if we need multiple device3 blocks in the flowgraph to be 
able to talk to all USRPs or just one device3 block which has all IPs etc. 
configured for all USRPs ?
We already tested it with two device3 blocks where each one was configured for 
one USRP and then in the blocks just use the device select option with "0" and 
"1", where we got the error that a device for "0" id is available but for "1" 
not.

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

[USRP-users] Interest Check: GNU Radio Symposium hosted in the UK

[Ben Hilburn via USRP-users]

Hi all -

*Survey Link: *https://goo.gl/forms/Plifla0fYgSdxzQe2

We just concluded the 8th annual GNU Radio Conference, which was once again
a great success. Thanks so much to everyone that helped put the event
together and attended!

For the past few years, interest in GNU Radio events outside of the United
States has grown. Starting in 2018, the first "European GNU Radio Days"
(previously named "French GNU Radio Days") was held in Lyon, France. The
second, in July of 2019, has already been announced (
https://gnuradio-fr-19.sciencesconf.org/).

The purpose of this survey is to gauge interest in a GNU Radio conference
event hosted in the UK, with a working name of the "GNU Radio Symposium".

Note that just as the "European GNU Radio Days" event is *in addition* to
the annual GNU Radio Conference event held in the USA, the "GNU Radio
Symposium" would also be in addition to an annual event held in the USA.
Thus, given enough interest, there will be three annual GNU Radio events.

If you're interested in e-mail updates about this event, you can provide
your e-mail address in the last question. Otherwise, the gnuradio-discuss
mailing list, the @gnuradio Twitter account (https://twitter.com/gnuradio),
and the website (https://www.gnuradio.org/) are the best ways to stay
up-to-date.

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

Re: [USRP-users] Calculate packet error rate using rx-ofdm

[Michael Dickens via USRP-users]

Hi dapodun nudopad - Check out < https://github.com/anastas/gr-cdma >
... the "pac_err_cal" block might do what you want. If not, it's
probably a good template for doing what you actually want. Hope this is
useful! - MLD
On Mon, Oct 29, 2018, at 8:26 AM, dapodun nudopad via USRP-users wrote:> Hello, 
> I am currently working with USRP for the gr-digital ofdm rx and tx. I
> want to know any reasonable way to calculate the packet error rate. I
> am using the signal source at the transmit side while I am planning to
> get the loss in packet at the receiver side. Currently, i looked at a
> dated back to 2015 discussion on this but it says using the packet_len
> in header formatter by multiplying it by 10,000 which is 96 * 10,000.
> However, this gave me an error and i could not see any FFT signal
> being transmitted. I even tried to increase my buffer size but the
> problem is still persistent. I Supposedly, the packet error rate
> should be derived from ratio of received packet divided by the
> packet_len.> Therefore, I would be grateful if anyone can suggest a detail 
> way to
> calculate the packet loss or show an alternative to getting a
> reasonable metrics here.> Thanks. Regards
> _
> 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