Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Marcus D. Leech via USRP-users]

On 09/09/2017 12:16 AM, Steven Knudsen wrote:
I am not sure that is an option. The TDMA scheme is such that the 
TX/RX to inactive time duty cycle is low. During the “inactive” time, 
other things  are going on.


I suppose maybe I could just turn the RX gain to zero (and will be anyway)

But what you are really suggesting is more polling  vs “interrupt” 
driven programming. Polling is generally not a way I like to go, 
especially when a) I can avoid it and b) I may be asked to host this 
on lesser hardware…


Put another way, if polling was okay, why have the ability to schedule 
receives?
Oh, I agree that it's a useful feature.  I'm just not certain of the 
hardware's ability to maintain sub-ms-scale scheduling abilities on the 
B210.





Thanks for all the discussion and help!

steven



Steven Knudsen, Ph.D., P.Eng.
www.techconficio.ca 
www.linkedin.com/in/knudstevenknudsen 



/Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt 
ist zu erreichen. - Franz Kafka/


On Sep 8, 2017, at 22:01, Marcus D. Leech > wrote:


On 09/08/2017 11:53 PM, Steven Knudsen wrote:

Okay, I can accept that.

What it means is that since my customer has not settled on a USRP 
platform, I should put some checks in that enforce timing 
constraints. Stuff like looking at the number of samples for the max 
expected packet length times the sample rate and comparing to a max 
allowable packet time. Of course, I have some such checks already, 
but I guess not enough… Too bad…


thanks,

steven
I'll point out that one could simply just receive all the time, and 
only pay attention to the RX samples that are within the RX timeslots






Steven Knudsen, Ph.D., P.Eng.
www.techconficio.ca 
www.linkedin.com/in/knudstevenknudsen 



/Der entscheidende Augenblick der menschlichen Entwicklung 
ist immerwährend. Darum sind die revolutionären 
geistigen Bewegungen, welche alles Frühere für nichtig erklären, im 
Recht, denn es ist noch nichts geschehen. - Franz Kafka/


On Sep 8, 2017, at 21:47, Marcus D. Leech > wrote:


On 09/08/2017 11:38 PM, Steven Knudsen wrote:
Let me see if I understand you correctly. Are you saying that 
turning on the first reception takes significant time?


In my case, the receive loop is running before the scheduling 
starts; it just times out and spins around again. So I am not sure 
that the receive startup is the problem.


But if it was, then could I simply not do a “dummy” receive and 
then start scheduling?


I can live with the 350 us pre-receive dead time.

However, without digging into the FPGA code, I would have thought 
that a command queue would be periodically checked to see if the 
next command time has arrived and then the waiting command would 
execute right away. But, if there was a set number of events that 
needed to execute for a reception, that might explain things. 
E.g., if things were disabled after NUM_SAMPS_AND_DONE and needed 
to be re-enabled the next time receive is invoked, that could and 
would take time.


At this point I am just speculating…

steven

PS You work long hours!


In general, starting the receive process takes a finite amount of 
time, because various bits of hardware need to be turned (back) 
on.   Tuning is the most
  notoriously slow part in the B2xx series--the chip wasn't 
designed for frequency-hopping, for example.  But other bits and 
pieces need to be initialized.
  I'm just not sure how many such bits and pieces and what the 
latency is.











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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Steven Knudsen via USRP-users]

I am not sure that is an option. The TDMA scheme is such that the TX/RX to 
inactive time duty cycle is low. During the “inactive” time, other things  are 
going on. 

I suppose maybe I could just turn the RX gain to zero (and will be anyway)

But what you are really suggesting is more polling  vs “interrupt” driven 
programming. Polling is generally not a way I like to go, especially when a) I 
can avoid it and b) I may be asked to host this on lesser hardware…

Put another way, if polling was okay, why have the ability to schedule receives?

Thanks for all the discussion and help!

steven



Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt ist zu 
erreichen. - Franz Kafka

> On Sep 8, 2017, at 22:01, Marcus D. Leech  wrote:
> 
> On 09/08/2017 11:53 PM, Steven Knudsen wrote:
>> Okay, I can accept that.
>> 
>> What it means is that since my customer has not settled on a USRP platform, 
>> I should put some checks in that enforce timing constraints. Stuff like 
>> looking at the number of samples for the max expected packet length times 
>> the sample rate and comparing to a max allowable packet time. Of course, I 
>> have some such checks already, but I guess not enough… Too bad…
>> 
>> thanks,
>> 
>> steven
> I'll point out that one could simply just receive all the time, and only pay 
> attention to the RX samples that are within the RX timeslots
> 
> 
>> 
>> 
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca 
>> www.linkedin.com/in/knudstevenknudsen 
>> 
>> 
>> Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. 
>> Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für 
>> nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
>> 
>>> On Sep 8, 2017, at 21:47, Marcus D. Leech >> > wrote:
>>> 
>>> On 09/08/2017 11:38 PM, Steven Knudsen wrote:
 Let me see if I understand you correctly. Are you saying that turning on 
 the first reception takes significant time?
 
 In my case, the receive loop is running before the scheduling starts; it 
 just times out and spins around again. So I am not sure that the receive 
 startup is the problem.
 
 But if it was, then could I simply not do a “dummy” receive and then start 
 scheduling?
 
 I can live with the 350 us pre-receive dead time.
 
 However, without digging into the FPGA code, I would have thought that a 
 command queue would be periodically checked to see if the next command 
 time has arrived and then the waiting command would execute right away. 
 But, if there was a set number of events that needed to execute for a 
 reception, that might explain things. E.g., if things were disabled after 
 NUM_SAMPS_AND_DONE and needed to be re-enabled the next time receive is 
 invoked, that could and would take time.
 
 At this point I am just speculating…
 
 steven
 
 PS You work long hours!
 
 
>>> In general, starting the receive process takes a finite amount of time, 
>>> because various bits of hardware need to be turned (back) on.   Tuning is 
>>> the most
>>>   notoriously slow part in the B2xx series--the chip wasn't designed for 
>>> frequency-hopping, for example.  But other bits and pieces need to be 
>>> initialized.
>>>   I'm just not sure how many such bits and pieces and what the latency is.
>>> 
>>> 
>> 
> 

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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Marcus D. Leech via USRP-users]

On 09/08/2017 11:53 PM, Steven Knudsen wrote:

Okay, I can accept that.

What it means is that since my customer has not settled on a USRP 
platform, I should put some checks in that enforce timing constraints. 
Stuff like looking at the number of samples for the max expected 
packet length times the sample rate and comparing to a max allowable 
packet time. Of course, I have some such checks already, but I guess 
not enough… Too bad…


thanks,

steven
I'll point out that one could simply just receive all the time, and only 
pay attention to the RX samples that are within the RX timeslots






Steven Knudsen, Ph.D., P.Eng.
www.techconficio.ca 
www.linkedin.com/in/knudstevenknudsen 



/Der entscheidende Augenblick der menschlichen Entwicklung 
ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, 
welche alles Frühere für nichtig erklären, im Recht, denn es ist 
noch nichts geschehen. - Franz Kafka/


On Sep 8, 2017, at 21:47, Marcus D. Leech > wrote:


On 09/08/2017 11:38 PM, Steven Knudsen wrote:
Let me see if I understand you correctly. Are you saying that 
turning on the first reception takes significant time?


In my case, the receive loop is running before the scheduling 
starts; it just times out and spins around again. So I am not sure 
that the receive startup is the problem.


But if it was, then could I simply not do a “dummy” receive and then 
start scheduling?


I can live with the 350 us pre-receive dead time.

However, without digging into the FPGA code, I would have thought 
that a command queue would be periodically checked to see if the 
next command time has arrived and then the waiting command would 
execute right away. But, if there was a set number of events that 
needed to execute for a reception, that might explain things. E.g., 
if things were disabled after NUM_SAMPS_AND_DONE and needed to be 
re-enabled the next time receive is invoked, that could and would 
take time.


At this point I am just speculating…

steven

PS You work long hours!


In general, starting the receive process takes a finite amount of 
time, because various bits of hardware need to be turned (back) on.   
Tuning is the most
  notoriously slow part in the B2xx series--the chip wasn't designed 
for frequency-hopping, for example.  But other bits and pieces need 
to be initialized.
  I'm just not sure how many such bits and pieces and what the 
latency is.







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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Steven Knudsen via USRP-users]

Okay, I can accept that.

What it means is that since my customer has not settled on a USRP platform, I 
should put some checks in that enforce timing constraints. Stuff like looking 
at the number of samples for the max expected packet length times the sample 
rate and comparing to a max allowable packet time. Of course, I have some such 
checks already, but I guess not enough… Too bad…

thanks,

steven


Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. 
Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für 
nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

> On Sep 8, 2017, at 21:47, Marcus D. Leech  wrote:
> 
> On 09/08/2017 11:38 PM, Steven Knudsen wrote:
>> Let me see if I understand you correctly. Are you saying that turning on the 
>> first reception takes significant time?
>> 
>> In my case, the receive loop is running before the scheduling starts; it 
>> just times out and spins around again. So I am not sure that the receive 
>> startup is the problem.
>> 
>> But if it was, then could I simply not do a “dummy” receive and then start 
>> scheduling?
>> 
>> I can live with the 350 us pre-receive dead time.
>> 
>> However, without digging into the FPGA code, I would have thought that a 
>> command queue would be periodically checked to see if the next command time 
>> has arrived and then the waiting command would execute right away. But, if 
>> there was a set number of events that needed to execute for a reception, 
>> that might explain things. E.g., if things were disabled after 
>> NUM_SAMPS_AND_DONE and needed to be re-enabled the next time receive is 
>> invoked, that could and would take time.
>> 
>> At this point I am just speculating…
>> 
>> steven
>> 
>> PS You work long hours!
>> 
>> 
> In general, starting the receive process takes a finite amount of time, 
> because various bits of hardware need to be turned (back) on.   Tuning is the 
> most
>   notoriously slow part in the B2xx series--the chip wasn't designed for 
> frequency-hopping, for example.  But other bits and pieces need to be 
> initialized.
>   I'm just not sure how many such bits and pieces and what the latency is.
> 
> 

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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Marcus D. Leech via USRP-users]

On 09/08/2017 11:38 PM, Steven Knudsen wrote:
Let me see if I understand you correctly. Are you saying that turning 
on the first reception takes significant time?


In my case, the receive loop is running before the scheduling starts; 
it just times out and spins around again. So I am not sure that the 
receive startup is the problem.


But if it was, then could I simply not do a “dummy” receive and then 
start scheduling?


I can live with the 350 us pre-receive dead time.

However, without digging into the FPGA code, I would have thought that 
a command queue would be periodically checked to see if the next 
command time has arrived and then the waiting command would execute 
right away. But, if there was a set number of events that needed to 
execute for a reception, that might explain things. E.g., if things 
were disabled after NUM_SAMPS_AND_DONE and needed to be re-enabled the 
next time receive is invoked, that could and would take time.


At this point I am just speculating…

steven

PS You work long hours!


In general, starting the receive process takes a finite amount of time, 
because various bits of hardware need to be turned (back) on.   Tuning 
is the most
  notoriously slow part in the B2xx series--the chip wasn't designed 
for frequency-hopping, for example.  But other bits and pieces need to 
be initialized.

  I'm just not sure how many such bits and pieces and what the latency is.


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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Steven Knudsen via USRP-users]

Let me see if I understand you correctly. Are you saying that turning on the 
first reception takes significant time?

In my case, the receive loop is running before the scheduling starts; it just 
times out and spins around again. So I am not sure that the receive startup is 
the problem.

But if it was, then could I simply not do a “dummy” receive and then start 
scheduling?

I can live with the 350 us pre-receive dead time.

However, without digging into the FPGA code, I would have thought that a 
command queue would be periodically checked to see if the next command time has 
arrived and then the waiting command would execute right away. But, if there 
was a set number of events that needed to execute for a reception, that might 
explain things. E.g., if things were disabled after NUM_SAMPS_AND_DONE and 
needed to be re-enabled the next time receive is invoked, that could and would 
take time.

At this point I am just speculating…

steven

PS You work long hours!


Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. 
Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für 
nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

> On Sep 8, 2017, at 21:30, Marcus D. Leech  wrote:
> 
> On 09/08/2017 10:54 PM, Steven Knudsen wrote:
>> Hi Marcus,
>> 
>> I did rebuild LiquidDSP, though it has no dependencies on the UHD. No change 
>> in behaviour.
>> 
>> Rather than speculate further with you (and waste your time), I pressed 
>> ahead with various avenues of investigation and appear to have had some 
>> success.
>> 
>> 
>> What seems to be the problem is that when you schedule multiple consecutive 
>> receptions using a stream command, you must leave some minimum time between 
>> the end of one reception and the start of the next.
>> 
>> Mine is a TDMA radio design with (for this experiment) 4 consecutive slots 
>> followed by an extended guard time. Each radio in the system is assigned one 
>> slot for transmission, and can use 3 slots for reception.
>> 
>> What I do now is the following
>> 
>> Every 10 ms;
>> 1) in one thread schedule 3 receptions 10 ms into the future, each separated 
>> by 1 ms and that will acquire samples over N microseconds (us) where N <= 
>> 1000 us. That is, do a batch scheduling for the reception of 3 slots
>> 2) A second thread runs forever and invokes recv with a timeout = 100 ms
>> 
>> As you know, the recv will block until it times out or a scheduled reception 
>> starts.
>> 
>> If N < 650 us, it all works as expected. However, if N > 650 us, I start to 
>> miss slots, and if N is too large a seg fault occurs (as per below, in 
>> __convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD).
>> 
>> My tentative conclusion is that there is some minimum time needed between 
>> scheduled receive commands even if they have been scheduled as a batch (all 
>> at once) in the “distant” past.
>> 
>> What do you think? Is there a minimum time in the FW required to set up for 
>> a scheduled reception?
>> 
>> thanks
>> 
>> steven
>> 
>> 
> I know that tuning on the B2xx series is quite time consuming, and there will 
> necessarily be *some* setup time for scheduled receives.  But I can't 
> definitively
>   comment on the magnitude of such setup times.
> 
> 
> 

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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Marcus D. Leech via USRP-users]

On 09/08/2017 10:54 PM, Steven Knudsen wrote:

Hi Marcus,

I did rebuild LiquidDSP, though it has no dependencies on the UHD. No 
change in behaviour.


Rather than speculate further with you (and waste your time), I 
pressed ahead with various avenues of investigation and appear to have 
had some success.



What seems to be the problem is that when you schedule multiple 
consecutive receptions using a stream command, you must leave some 
minimum time between the end of one reception and the start of the next.


Mine is a TDMA radio design with (for this experiment) 4 consecutive 
slots followed by an extended guard time. Each radio in the system is 
assigned one slot for transmission, and can use 3 slots for reception.


What I do now is the following

Every 10 ms;
1) in one thread schedule 3 receptions 10 ms into the future, each 
separated by 1 ms and that will acquire samples over N microseconds 
(us) where N <= 1000 us. That is, do a batch scheduling for the 
reception of 3 slots

2) A second thread runs forever and invokes recv with a timeout = 100 ms

As you know, the recv will block until it times out or a scheduled 
reception starts.


If N < 650 us, it all works as expected. However, if N > 650 us, I 
start to miss slots, and if N is too large a seg fault occurs (as per 
below, in __convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD).


My tentative conclusion is that there is some minimum time needed 
between scheduled receive commands even if they have been scheduled as 
a batch (all at once) in the “distant” past.


What do you think? Is there a minimum time in the FW required to set 
up for a scheduled reception?


thanks

steven


I know that tuning on the B2xx series is quite time consuming, and there 
will necessarily be *some* setup time for scheduled receives. But I 
can't definitively

  comment on the magnitude of such setup times.



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

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

[Steven Knudsen via USRP-users]

Hi Marcus,

I did rebuild LiquidDSP, though it has no dependencies on the UHD. No change in 
behaviour.

Rather than speculate further with you (and waste your time), I pressed ahead 
with various avenues of investigation and appear to have had some success.


What seems to be the problem is that when you schedule multiple consecutive 
receptions using a stream command, you must leave some minimum time between the 
end of one reception and the start of the next.

Mine is a TDMA radio design with (for this experiment) 4 consecutive slots 
followed by an extended guard time. Each radio in the system is assigned one 
slot for transmission, and can use 3 slots for reception.

What I do now is the following

Every 10 ms;
1) in one thread schedule 3 receptions 10 ms into the future, each separated by 
1 ms and that will acquire samples over N microseconds (us) where N <= 1000 us. 
That is, do a batch scheduling for the reception of 3 slots
2) A second thread runs forever and invokes recv with a timeout = 100 ms

As you know, the recv will block until it times out or a scheduled reception 
starts.

If N < 650 us, it all works as expected. However, if N > 650 us, I start to 
miss slots, and if N is too large a seg fault occurs (as per below, in 
__convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD).

My tentative conclusion is that there is some minimum time needed between 
scheduled receive commands even if they have been scheduled as a batch (all at 
once) in the “distant” past.

What do you think? Is there a minimum time in the FW required to set up for a 
scheduled reception?

thanks

steven


Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Du bist die Aufgabe. Kein Schüler weit und breit. - Franz Kafka 

> On Sep 6, 2017, at 22:42, Marcus D. Leech  wrote:
> 
> On 09/07/2017 12:37 AM, Steven Knudsen wrote:
>> Thanks, Marcus.
>> 
>> I was running a slightly older version, so updated to 
>> release_003_010_002_000. 
>> 
>> Now it does not get as far at all, but seg faults :-(
>> 
>> Backtrace looks like
> Did you rebuild your LiquidDSP libraries after doing the UHD upgrade?
> 
>> 
>> Thread 18 "TxRxFlood" received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fffe8ff9700 (LWP 7602)]
>> 0x7731fb96 in 
>> __convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector>  const*> const&, uhd::ref_vector const&, unsigned long) () from 
>> /usr/local/lib/libuhd.so.003
>> (gdb) bt
>> #0  0x7731fb96 in 
>> __convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector>  const*> const&, uhd::ref_vector const&, unsigned long) () from 
>> /usr/local/lib/libuhd.so.003
>> #1  0x7768a361 in 
>> uhd::transport::sph::recv_packet_handler::convert_to_out_buff(unsigned long) 
>> ()
>>from /usr/local/lib/libuhd.so.003
>> #2  0x77695d1f in 
>> uhd::transport::sph::recv_packet_streamer::recv(uhd::ref_vector 
>> const&, unsigned long, uhd::rx_metadata_t&, double, bool) () from 
>> /usr/local/lib/libuhd.so.003
>> #3  0x004841e0 in uhd::jitc::liquidDspPhy::receiveLoop 
>> (this=0x754650)
>> at /home/knud/Development/uhd-jitc/lib/phy_layer/liquidDspPhy.cpp:273
>> #4  0x0048a543 in boost::_mfi::mf0> uhd::jitc::liquidDspPhy>::operator() (this=0x7790c8, p=0x754650)
>> at /usr/include/boost/bind/mem_fn_template.hpp:49
>> #5  0x0048a4c4 in 
>> boost::_bi::list1 
>> >::operator(), 
>> boost::_bi::list0> (this=0x7790d8, f=..., a=...) at 
>> /usr/include/boost/bind/bind.hpp:253
>> #6  0x0048a45c in boost::_bi::bind_t> uhd::jitc::liquidDspPhy>, 
>> boost::_bi::list1 > 
>> >::operator() (this=0x7790c8) at /usr/include/boost/bind/bind_template.hpp:20
>> #7  0x0048a40e in 
>> boost::detail::thread_data> uhd::jitc::liquidDspPhy>, 
>> boost::_bi::list1 > > >::run 
>> (this=0x778f10)
>> at /usr/include/boost/thread/detail/thread.hpp:116
>> #8  0x767305d5 in ?? () from 
>> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
>> #9  0x765096ba in start_thread (arg=0x7fffe8ff9700) at 
>> pthread_create.c:333
>> #10 0x753b93dd in clone () at 
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>> 
>> 
>> Looked at the source for the __convert_sc16_item32_le_… and can’t see the 
>> issue easily. Obviously originates at my call to recv at #2, which is 
>> invoked after the first scheduled receive. I assume that recv starts getting 
>> samples at the scheduled time and a wire sample conversion goes awry. 
>> 
>> Tried a different program that does only scheduled receives and it still 
>> works properly, so it must be something in the new program, but not 
>> UHD-related.
>> 
>> I’ll keep looking…
>> 
>> 
>> thanks,
>> 
>> steven
>> 
>> 
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca 
>> www.linkedin.com/in/knudstevenknudsen 
>> 
>> 
>> An Fortschritt glauben heißt nicht glauben, daß ein Forts

[USRP-users] (RFNoC) Command Sequence Number Mismatches

[Rupert Lloyd via USRP-users]

We have an app using RFNoC Radio blocks running on the e310 that uses a TX
frequency hopping at ~70Hz and a non-hopping RX that is intermittently
re-tuned every few seconds.

We are experiencing an intermittent, but ultimately unrecoverable IO error
when sending tuning commands to our RFNoC radio blocks. After a few minutes
of running time we will see a command timeout exception caused by an
exception caused by a mismatch between the sequence number in the command
and the response:

*** RuntimeError: EnvironmentError: IOError: [0/Radio_0]
user_reg_read32() failed:
EnvironmentError: IOError: [0/Radio_0] sr_read32() failed:
EnvironmentError: IOError: Block ctrl (CE_00_Port_10) packet parse
error -
EnvironmentError: IOError: Expected packet index: 3261  Received index:
3262

All subsequent commands to either of our RX/TX RFNoC blocks trigger a this
exception so we are unable to recover from this error without restarting
the flowgraph.

Has anyone experienced this behavior or could suggest a troubleshooting
strategy?

Note: I think the values of “Expected packet index” and “Received index”
should be switched around in the exception message [1] (so we are expecting
3262 and receiving 3261)

[1] uhd/host/lib/rfnoc/ctrl_iface.cpp:282
[2] https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD dropping samples running on Debian 9

[Meelis Nõmm via USRP-users]

Yes. We are using a N210 and the memory limits have been updated to 50M.
Interesting to hear that it works with Ubuntu17, tho we would like to stick
with Debian.

Any other ideas or queations?
Meelis

8. sept 2017 6:46 PM kirjutas kuupäeval :

> The original e-mail reporting "trouble" didn't specify which USRP device
> was involved, so in the interests of clarification and completeness, I
> thought that I'd interject about USB devices.  Yes, the N2xx and X3xx
> devices use a 1GiGe (or optionally 10GiGe for X3xx) for connecting to the
> host computer.
>
>
>
>
>
>
> On 2017-09-08 11:28, David wrote:
>
> USRP N2xx or X3xx are network devices?
>
> On 08/09/17 16:07, mle...@ripnet.com wrote:
>
> USRP devices that are attached via USB don't use the networking stack, so
> tweaking network-stack kernel parameters is irrelevant.
>
> Since the USB devices use LibUSB, which is entirely user-space, the
> transport parameters here should be investigated:
>
> https://files.ettus.com/manual/page_transport.html#transport_usb_params
>
> But if problems are occurring at low sample rates, it may be that your USB
> subsystem just isn't up to the task.
>
>
>
>
>
>
> On 2017-09-08 11:02, David wrote:
>
> could you explain why please?
>
> On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote:
>
> This is presumably a network-attached USRP (N2xx or X3xx)?  Otherwise,
> network parameters are irrelevant.
>
>
>
>
>
>
> On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:
>
> Hello,
>
> We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK),
> installed Debian 9 on it and tested Gnuradio on it. At first we installed
> via apt-get. We saw some drops in the gnuradio-companion and had issue with
> setting the real-time priority, so we removed it from the system and
> installed it again with pybombs.
> However, no difference. Today tested it again with UHD provided benchmark
> example (for easy reference).  Saw occasional drops with Sps from 1e6 to
> 10e6. Thought it might be a network driver issue, updated the Intel network
> driver with the latest(?) e1000e driver. Still no difference.
>
> Any ideas, can we fix this somehow?
> Thank you
> Meelis
>
> Additional information is in the file attached, but most important system
> parameters:
> #system
> Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
> #Network driver
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> I219-LM (rev 31)
> filename:   /lib/modules/4.9.0-3-amd64/upd
> ates/drivers/net/ethernet/intel/e1000e/e1000e.ko
> version:3.3.5.10-NAPI
>
>
> $ ./benchmark_rate --rx_rate 10e6 --duration 300
>
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200;
> UHD_3.11.0.git-181-g8f9f4184]
>
> ___
> 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

Re: [USRP-users] [RFNoC][BLOCK DESIGN] Questions about design in RFNoC

[Nick Foster via USRP-users]

Hi Ruben,

Regarding why the "copy" block is necessary, please see the following post:
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

Specifically, the "Addendum" section at the bottom. The E310 needs to have
the TX streamer enabled explicitly if the application doesn't include a
stream to the host. This means you must modify the Python generated from
gnuradio-companion before it will work.

Regarding the RFNoC file format, you're free to use whatever internal data
representation you want. But when you're interfacing with other blocks, or
with the host, the assumption is that your data is Q15, as you said. If
it's not, you'll be responsible for translating it in a way that can be
understood by the rest of the system.

--n

On Fri, Sep 8, 2017 at 6:31 AM LCD PI via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everybody,
>
> We are working in a PRBS Generator and the idea is to make it works with
> the RFNoC structure. But we are having some troubles and need some help on
> it. Could you please clarify this four points? :
>
>
> 1. Trying to understand the functionality of a RFNoC Generator, we were
> trying to transmit a signal with RFNoC:Siggen block on Ettus E310. This
> signal will be received by a laptop through a RTL-SDR dongle with
> GNURadio.
>
> Flowgraph of transmitter that we generated on the E310:
>
> Note: we also put the RFNoC FIFO between the RFNoc Radio and the SigGen.
>
> Flowgraph of the receiver on our laptop:
>
> [image: print2.png]
>
> Software versions in use:
>
> UHD: UHD_4.0.0.HEAD-239-g89427e8c
>
> GNURADIO: 3.7.9.3
>
> When we executed the transmitter flowgraph illustrated above, and trigger
> “Enable” to 1,  the TX indicator led turn red but the receiver doesn’t show
> our signal.
>
> But if we change the flowgraph into this:
>
>
> In this case, when we trigger “Enable” to 1, we can see our signal
> spectrum in the receiver.
>
>
>1.
>
>Why we cannot generate and transmit data directly in the FPGA without
>“up” to the PS?
>2.
>
>Is there any incompatibility between the RFNoC: Siggen block and the
>E310?
>3.
>
>Are we forgetting some configurations  ?
>
>
> 2. The second question is about Datatypes, we are designing a PRBS
> Generator with LFSR method, which generates data of 32bits in our IP Core
> with this format:
>
>16 I bits, 16 Q bits.
>
>-
>
>1 → [16’b1, 16’b0]
>-
>
>0 → [16’b0, 16’b0]
>
>
> En archivo de configuracion de UHD (xml) configuramos el host type como
> fc32 y el otw type como sc16,
>
> In the configuration file of the UHD “XML” we set the host type in FC32
> and the OTW in SC16, but when we run our example in the GnuRadio the QT
> TIME SINK doesn’t show 0’s and 1’s, but instead we see smaller values ( 0’s
> and 0,30519). This make us think that the I and Q values were
> interpreted like a Q15 format.
>
> So, we made some changes in our Verilog Code and generate data using the
> fixed-point format (signed Q15), like this:
>
>16 I bits , 16 Q bits.
>
>1 sign bit - 15 fractional I bits , 1 sign bit - 15 fractional Q
> bits .
>
>-
>
>1 → [1’b0 - 15’d32767, 1’b0 - 15’b0]
>-
>
>0 → [1’b0 - 15’b0, 1’b0 - 15’b0]
>
>
> After that, values of 1’s and 0’s were observed in QT TIME SINK.
>
>
>1.
>
>Can we say that the data inside our IPCORE must be mandatory generated
>like a signed Q15 type, or we are misunderstanding something?
>
>
> 3. In addition to RFNoC block, we created the same block in Python
> language for GNURadio. This, like FPGA block, generate 1's and 0's but in a
> "bit to bit" mode. Our problem is that we cannot know the run frequency of
> the block in the PS (in the FPGA the blocks are connected to the
> radio_clk). When we connect this block to the QT TIME SINK, we can see the
> generate data without problem; but when we try to “down” to the FPGA and
> transmit that data with the RFNoC:Radio, the TX red led does not turn on
> and we obtain Underflow.
>
>
>1.
>
>If our block can not generate data at the same rate that RFNoC:Radio
>block was configure, is there any way to resolve/avoid the Underflow?
>
>
> 4. The Ettus web page say that this bandwidth between PS and PL is 10MS/s,
> but does not explain under what circumstances.
>
>
>1.
>
>Is there any way to measure the data bandwidth between the PS and PL?
>
>
> Regards and thanks for your time.
>
> Ruben Vogel
>
>
> --
>
> ___
> 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] B200mini & XU4 problem

[Marcus D. Leech via USRP-users]

I've run a simple interferometer application with a B210 on an XU4, with
two channels at 15Msps. 

On 2017-09-08 11:23, David wrote:

> Thanks Marcus, 
> 
> so doing ... benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6
> 
> no overruns (got a couple with 256).
> 
> I'm just trying to get a feel of what is possible with this processor, 
> 
> Cheers
> Dave
> 
> On 08/09/17 15:58, mle...@ripnet.com wrote: 
> 
> I've found that altering num_recv_frames in the device args to be helpful on 
> XU4--try 128 or 256 
> 
> On 2017-09-08 10:34, David via USRP-users wrote: 
> Just tried out a USB3 powered hub, to power the b200.
> 
> The XU4 wouldn't boot powered from the hub (2A max), but powered from it's 
> own supply (4A) and the B200mini powered from the hub all seems OK, no device 
> errors, fscks on reboot, etc. :-) :-)
> 
> So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).
> 
> Using uhd_fft at 10MHz rate results in just a few overruns over several 
> minutes, it's marginal...
> 
> Now I can move on to do some real stuff...
> 
> Kind regards,
> Dave
> 
> On 04/09/17 18:21, David wrote: So after a reboot of my main Ubuntu PC...
> 
> It's now recognised, so doing...
> 
> # fsck /dev/sdd2
> fsck from util-linux 2.27.1
> e2fsck 1.42.13 (17-May-2015)
> rootfs was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
> # fsck /dev/sdd1
> fsck from util-linux 2.27.1
> fsck.fat 3.0.28 (2015-05-16)
> 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be 
> corrupt.
> 1) Remove dirty bit
> 2) No action
> ? 1
> Perform changes ? (y/n) y
> /dev/sdd1: 7 files, 5028/65399 clusters
> 
> Then put it back into the XU4, and it reboots OK. So there is more than one 
> issue here?
> 
> Sorry for the commentary/verboseness, but I've been at this for a while now...
> 
> Kind Regards,
> 
> Dave
> 
> On 02/09/17 22:02, Nate Temple wrote: Hi Dave,
> 
> This is certainly an interesting issue. I suspect the core of the issue may 
> be power draw on the USB interface during boot. One of the common issues with 
> the XU4 that I've seen reported is that the USB3 ports do not provide USB3 
> spec power levels.
> 
> Using a powered USB3 hub may resolve the issue.
> 
> Another option would be a Y power cable such as this 
> http://www.ebay.com/itm/262045046196 which would allow you to use an external 
> power adapter to feed power to the USRP.
> 
> Another test you could try -- Try using the USB2 on the XU4. Does it result 
> in the same boot up problems?
> 
> I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini 
> and have not seen any issue such as this.
> 
> Regards,
> Nate Temple
> 
> On Sep 2, 2017, at 1:44 AM, David via USRP-users  
> wrote:
> 
> Hi All,
> 
> I'm trying to get XU4 and B200mini to work together, but having a serious 
> issue: the SD card gets trashed!
> 
> I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and 
> latest GIT clone of UHD (as of two weeks ago). Two uSD cards I had are now 
> totally trashed. I'm on my last card. They seem to get totally trashed after 
> I run uhd-fft a few times.
> 
> The main symptom is that if the B200mini is connected and I reboot, an fsck 
> is done every time, and also has the effect of continually rebooting, and 
> continually corrupting the card.
> 
> Unplug the B200mini and all is fine (after a couple of fscks). I managed to 
> work out that if I remove the udev rule that starts up UHD (uhd-usrp.rules) I 
> am also able to reboot with no issues. So a driver issue?
> 
> Without the udev rule I get the following, which I'm assuming is normal?:
> 
> [   24.555119] usb 3-1.1: device descriptor read/64, error -110
> [   29.995114] usb 3-1.1: device descriptor read/64, error -110
> [   45.675119] usb 3-1.1: device descriptor read/64, error -110
> [   56.685085] usb 3-1.1: device not accepting address 5, error -62
> [   67.565082] usb 3-1.1: device not accepting address 6, error -62
> [   67.569976] usb 3-1-port1: unable to enumerate USB device
> 
> Hope you can help, thanks,
> 
> Dave.
> 
> ___
> 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] UHD dropping samples running on Debian 9

[Marcus D. Leech via USRP-users]

The original e-mail reporting "trouble" didn't specify which USRP device
was involved, so in the interests of clarification and completeness, I
thought that I'd interject about USB devices.  Yes, the N2xx and X3xx
devices use a 1GiGe (or optionally 10GiGe for X3xx) for connecting to
the host computer. 

On 2017-09-08 11:28, David wrote:

> USRP N2xx or X3xx are network devices? 
> On 08/09/17 16:07, mle...@ripnet.com wrote: 
> 
> USRP devices that are attached via USB don't use the networking stack, so 
> tweaking network-stack kernel parameters is irrelevant. 
> 
> Since the USB devices use LibUSB, which is entirely user-space, the transport 
> parameters here should be investigated: 
> 
> https://files.ettus.com/manual/page_transport.html#transport_usb_params 
> 
> But if problems are occurring at low sample rates, it may be that your USB 
> subsystem just isn't up to the task. 
> 
> On 2017-09-08 11:02, David wrote: 
> 
> could you explain why please? 
> On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote: 
> 
> This is presumably a network-attached USRP (N2xx or X3xx)?  Otherwise, 
> network parameters are irrelevant. 
> 
> On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote: 
> Hello,
> 
> We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed 
> Debian 9 on it and tested Gnuradio on it. At first we installed via apt-get. 
> We saw some drops in the gnuradio-companion and had issue with setting the 
> real-time priority, so we removed it from the system and installed it again 
> with pybombs. 
> However, no difference. Today tested it again with UHD provided benchmark 
> example (for easy reference).  Saw occasional drops with Sps from 1e6 to 
> 10e6. Thought it might be a network driver issue, updated the Intel network 
> driver with the latest(?) e1000e driver. Still no difference. 
> 
> Any ideas, can we fix this somehow? 
> Thank you 
> Meelis 
> 
> Additional information is in the file attached, but most important system 
> parameters: #system
> Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) 
> #Network driver
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) 
> I219-LM (rev 31)
> filename:   
> /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
> version:3.3.5.10-NAPI
> 
> $ ./benchmark_rate --rx_rate 10e6 --duration 300
> 
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
> UHD_3.11.0.git-181-g8f9f4184] 
> ___
> 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] UHD dropping samples running on Debian 9

[David via USRP-users]

USRP N2xx or X3xx are network devices?


On 08/09/17 16:07, mle...@ripnet.com wrote:


USRP devices that are attached via USB don't use the networking stack, 
so tweaking network-stack kernel parameters is irrelevant.


Since the USB devices use LibUSB, which is entirely user-space, the 
transport parameters here should be investigated:


https://files.ettus.com/manual/page_transport.html#transport_usb_params

But if problems are occurring at low sample rates, it may be that your 
USB subsystem just isn't up to the task.


On 2017-09-08 11:02, David wrote:


could you explain why please?


On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote:


This is presumably a network-attached USRP (N2xx or X3xx)? 
Otherwise, network parameters are irrelevant.


On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:

Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a
NUC6i7KYK), installed Debian 9 on it and tested Gnuradio on it.
At first we installed via apt-get. We saw some drops in the
gnuradio-companion and had issue with setting the real-time
priority, so we removed it from the system and installed it
again with pybombs.
However, no difference. Today tested it again with UHD provided
benchmark example (for easy reference). Saw occasional drops
with Sps from 1e6 to 10e6. Thought it might be a network driver
issue, updated the Intel network driver with the latest(?)
e1000e driver. Still no difference.
Any ideas, can we fix this somehow?
Thank you
Meelis
Additional information is in the file attached, but most
important system parameters:
#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet
Connection (2) I219-LM (rev 31)
filename:  
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200;
UHD_3.11.0.git-181-g8f9f4184]

___
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] B200mini & XU4 problem

[David via USRP-users]

Thanks Marcus,

so doing ...

benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6

no overruns (got a couple with 256).

I'm just trying to get a feel of what is possible with this processor,

Cheers
Dave



On 08/09/17 15:58, mle...@ripnet.com wrote:


I've found that altering num_recv_frames in the device args to be 
helpful on XU4--try 128 or 256


On 2017-09-08 10:34, David via USRP-users wrote:


Just tried out a USB3 powered hub, to power the b200.

The XU4 wouldn't boot powered from the hub (2A max), but powered from 
it's own supply (4A) and the B200mini powered from the hub all seems 
OK, no device errors, fscks on reboot, etc. :-) :-)


So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).

Using uhd_fft at 10MHz rate results in just a few overruns over 
several minutes, it's marginal...


Now I can move on to do some real stuff...

Kind regards,
Dave


On 04/09/17 18:21, David wrote:

So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some data 
may be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more 
than one issue here?


Sorry for the commentary/verboseness, but I've been at this for a 
while now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of 
the common issues with the XU4 that I've seen reported is that the 
USB3 ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use 
an external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does 
it result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with a 
B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
mailto:usrp-users@lists.ettus.com>> 
wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 
4.9.28-38, and latest GIT clone of UHD (as of two weeks ago). Two 
uSD cards I had are now totally trashed. I'm on my last card. They 
seem to get totally trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I 
reboot, an fsck is done every time, and also has the effect of 
continually rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts up 
UHD (uhd-usrp.rules) I am also able to reboot with no issues. So a 
driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
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] UHD dropping samples running on Debian 9

[Marcus D. Leech via USRP-users]

USRP devices that are attached via USB don't use the networking stack,
so tweaking network-stack kernel parameters is irrelevant. 

Since the USB devices use LibUSB, which is entirely user-space, the
transport parameters here should be investigated: 

https://files.ettus.com/manual/page_transport.html#transport_usb_params 

But if problems are occurring at low sample rates, it may be that your
USB subsystem just isn't up to the task. 

On 2017-09-08 11:02, David wrote:

> could you explain why please? 
> On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote: 
> 
> This is presumably a network-attached USRP (N2xx or X3xx)?  Otherwise, 
> network parameters are irrelevant. 
> 
> On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote: 
> Hello,
> 
> We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed 
> Debian 9 on it and tested Gnuradio on it. At first we installed via apt-get. 
> We saw some drops in the gnuradio-companion and had issue with setting the 
> real-time priority, so we removed it from the system and installed it again 
> with pybombs. 
> However, no difference. Today tested it again with UHD provided benchmark 
> example (for easy reference).  Saw occasional drops with Sps from 1e6 to 
> 10e6. Thought it might be a network driver issue, updated the Intel network 
> driver with the latest(?) e1000e driver. Still no difference. 
> 
> Any ideas, can we fix this somehow? 
> Thank you 
> Meelis 
> 
> Additional information is in the file attached, but most important system 
> parameters: #system
> Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) 
> #Network driver
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) 
> I219-LM (rev 31)
> filename:   
> /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
> version:3.3.5.10-NAPI
> 
> $ ./benchmark_rate --rx_rate 10e6 --duration 300
> 
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
> UHD_3.11.0.git-181-g8f9f4184] 
> ___
> 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] UHD dropping samples running on Debian 9

[David via USRP-users]

could you explain why please?


On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote:


This is presumably a network-attached USRP (N2xx or X3xx)? Otherwise, 
network parameters are irrelevant.


On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:


Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), 
installed Debian 9 on it and tested Gnuradio on it. At first we 
installed via apt-get. We saw some drops in the gnuradio-companion 
and had issue with setting the real-time priority, so we removed it 
from the system and installed it again with pybombs.
However, no difference. Today tested it again with UHD provided 
benchmark example (for easy reference).  Saw occasional drops with 
Sps from 1e6 to 10e6. Thought it might be a network driver issue, 
updated the Intel network driver with the latest(?) e1000e driver. 
Still no difference.

Any ideas, can we fix this somehow?
Thank you
Meelis
Additional information is in the file attached, but most important 
system parameters:

#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection 
(2) I219-LM (rev 31)
filename:   
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184]


___
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] B200mini & XU4 problem

[Marcus D. Leech via USRP-users]

I've found that altering num_recv_frames in the device args to be
helpful on XU4--try 128 or 256 

On 2017-09-08 10:34, David via USRP-users wrote:

> Just tried out a USB3 powered hub, to power the b200.
> 
> The XU4 wouldn't boot powered from the hub (2A max), but powered from it's 
> own supply (4A) and the B200mini powered from the hub all seems OK, no device 
> errors, fscks on reboot, etc. :-) :-)
> 
> So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).
> 
> Using uhd_fft at 10MHz rate results in just a few overruns over several 
> minutes, it's marginal...
> 
> Now I can move on to do some real stuff...
> 
> Kind regards,
> Dave
> 
> On 04/09/17 18:21, David wrote: So after a reboot of my main Ubuntu PC...
> 
> It's now recognised, so doing...
> 
> # fsck /dev/sdd2
> fsck from util-linux 2.27.1
> e2fsck 1.42.13 (17-May-2015)
> rootfs was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
> # fsck /dev/sdd1
> fsck from util-linux 2.27.1
> fsck.fat 3.0.28 (2015-05-16)
> 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be 
> corrupt.
> 1) Remove dirty bit
> 2) No action
> ? 1
> Perform changes ? (y/n) y
> /dev/sdd1: 7 files, 5028/65399 clusters
> 
> Then put it back into the XU4, and it reboots OK. So there is more than one 
> issue here?
> 
> Sorry for the commentary/verboseness, but I've been at this for a while now...
> 
> Kind Regards,
> 
> Dave
> 
> On 02/09/17 22:02, Nate Temple wrote: Hi Dave,
> 
> This is certainly an interesting issue. I suspect the core of the issue may 
> be power draw on the USB interface during boot. One of the common issues with 
> the XU4 that I've seen reported is that the USB3 ports do not provide USB3 
> spec power levels.
> 
> Using a powered USB3 hub may resolve the issue.
> 
> Another option would be a Y power cable such as this 
> http://www.ebay.com/itm/262045046196 which would allow you to use an external 
> power adapter to feed power to the USRP.
> 
> Another test you could try -- Try using the USB2 on the XU4. Does it result 
> in the same boot up problems?
> 
> I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini 
> and have not seen any issue such as this.
> 
> Regards,
> Nate Temple
> 
> On Sep 2, 2017, at 1:44 AM, David via USRP-users  
> wrote:
> 
> Hi All,
> 
> I'm trying to get XU4 and B200mini to work together, but having a serious 
> issue: the SD card gets trashed!
> 
> I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and 
> latest GIT clone of UHD (as of two weeks ago). Two uSD cards I had are now 
> totally trashed. I'm on my last card. They seem to get totally trashed after 
> I run uhd-fft a few times.
> 
> The main symptom is that if the B200mini is connected and I reboot, an fsck 
> is done every time, and also has the effect of continually rebooting, and 
> continually corrupting the card.
> 
> Unplug the B200mini and all is fine (after a couple of fscks). I managed to 
> work out that if I remove the udev rule that starts up UHD (uhd-usrp.rules) I 
> am also able to reboot with no issues. So a driver issue?
> 
> Without the udev rule I get the following, which I'm assuming is normal?:
> 
> [   24.555119] usb 3-1.1: device descriptor read/64, error -110
> [   29.995114] usb 3-1.1: device descriptor read/64, error -110
> [   45.675119] usb 3-1.1: device descriptor read/64, error -110
> [   56.685085] usb 3-1.1: device not accepting address 5, error -62
> [   67.565082] usb 3-1.1: device not accepting address 6, error -62
> [   67.569976] usb 3-1-port1: unable to enumerate USB device
> 
> Hope you can help, thanks,
> 
> Dave.
> 
> ___
> 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] UHD dropping samples running on Debian 9

[Marcus D. Leech via USRP-users]

This is presumably a network-attached USRP (N2xx or X3xx)?  Otherwise,
network parameters are irrelevant. 

On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote:

> Hello,
> 
> We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed 
> Debian 9 on it and tested Gnuradio on it. At first we installed via apt-get. 
> We saw some drops in the gnuradio-companion and had issue with setting the 
> real-time priority, so we removed it from the system and installed it again 
> with pybombs. 
> However, no difference. Today tested it again with UHD provided benchmark 
> example (for easy reference).  Saw occasional drops with Sps from 1e6 to 
> 10e6. Thought it might be a network driver issue, updated the Intel network 
> driver with the latest(?) e1000e driver. Still no difference. 
> 
> Any ideas, can we fix this somehow? 
> Thank you 
> Meelis 
> 
> Additional information is in the file attached, but most important system 
> parameters: #system
> Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) 
> #Network driver
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) 
> I219-LM (rev 31)
> filename:   
> /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
> version:3.3.5.10-NAPI
> 
> $ ./benchmark_rate --rx_rate 10e6 --duration 300
> 
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
> UHD_3.11.0.git-181-g8f9f4184] 
> ___
> 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 dropping samples running on Debian 9

[David via USRP-users]

network buffer size?

Should be...

# sysctl net.core.rmem_max
net.core.rmem_max = 5000


On 08/09/17 15:25, Meelis Nõmm via USRP-users wrote:

Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), 
installed Debian 9 on it and tested Gnuradio on it. At first we 
installed via apt-get. We saw some drops in the gnuradio-companion and 
had issue with setting the real-time priority, so we removed it from 
the system and installed it again with pybombs.
However, no difference. Today tested it again with UHD provided 
benchmark example (for easy reference).  Saw occasional drops with Sps 
from 1e6 to 10e6. Thought it might be a network driver issue, updated 
the Intel network driver with the latest(?) e1000e driver. Still no 
difference.


Any ideas, can we fix this somehow?
Thank you
Meelis

Additional information is in the file attached, but most important 
system parameters:

#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) 
I219-LM (rev 31)
filename:   
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184]



___
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 dropping samples running on Debian 9

[Dan CaJacob via USRP-users]

We use several NUC6i7KYK units without any issues. They run Ubuntu 17.04

On Fri, Sep 8, 2017 at 10:29 AM Meelis Nõmm via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK),
> installed Debian 9 on it and tested Gnuradio on it. At first we installed
> via apt-get. We saw some drops in the gnuradio-companion and had issue with
> setting the real-time priority, so we removed it from the system and
> installed it again with pybombs.
> However, no difference. Today tested it again with UHD provided benchmark
> example (for easy reference).  Saw occasional drops with Sps from 1e6 to
> 10e6. Thought it might be a network driver issue, updated the Intel network
> driver with the latest(?) e1000e driver. Still no difference.
>
> Any ideas, can we fix this somehow?
> Thank you
> Meelis
>
> Additional information is in the file attached, but most important system
> parameters:
> #system
> Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
> #Network driver
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> I219-LM (rev 31)
> filename:
> /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
> version:3.3.5.10-NAPI
>
>
> $ ./benchmark_rate --rx_rate 10e6 --duration 300
>
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200;
> UHD_3.11.0.git-181-g8f9f4184]
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Very Respectfully,

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

Re: [USRP-users] B200mini & XU4 problem

[David via USRP-users]

Just tried out a USB3 powered hub, to power the b200.

The XU4 wouldn't boot powered from the hub (2A max), but powered from 
it's own supply (4A) and the B200mini powered from the hub all seems OK, 
no device errors, fscks on reboot, etc. :-) :-)


So, using "benchmark_rate --rx_rate 40e6", I get no dropped samples :-).

Using uhd_fft at 10MHz rate results in just a few overruns over several 
minutes, it's marginal...


Now I can move on to do some real stuff...

Kind regards,
Dave


On 04/09/17 18:21, David wrote:

So after a reboot of my main Ubuntu PC...

It's now recognised, so doing...

# fsck /dev/sdd2
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
rootfs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 124553/237568 files (0.4% non-contiguous), 783269/920192 blocks
# fsck /dev/sdd1
fsck from util-linux 2.27.1
fsck.fat 3.0.28 (2015-05-16)
0x25: Dirty bit is set. Fs was not properly unmounted and some data 
may be corrupt.

1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdd1: 7 files, 5028/65399 clusters

Then put it back into the XU4, and it reboots OK. So there is more 
than one issue here?


Sorry for the commentary/verboseness, but I've been at this for a 
while now...


Kind Regards,

Dave


On 02/09/17 22:02, Nate Temple wrote:

Hi Dave,

This is certainly an interesting issue. I suspect the core of the 
issue may be power draw on the USB interface during boot. One of the 
common issues with the XU4 that I've seen reported is that the USB3 
ports do not provide USB3 spec power levels.


Using a powered USB3 hub may resolve the issue.

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an 
external power adapter to feed power to the USRP.


Another test you could try -- Try using the USB2 on the XU4. Does it 
result in the same boot up problems?


I have a early rev 0.1 20151201 XU4 that I often use paired with a 
B205mini and have not seen any issue such as this.


Regards,
Nate Temple




On Sep 2, 2017, at 1:44 AM, David via USRP-users 
 wrote:


Hi All,

I'm trying to get XU4 and B200mini to work together, but having a 
serious issue: the SD card gets trashed!


I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, 
and latest GIT clone of UHD (as of two weeks ago). Two uSD cards I 
had are now totally trashed. I'm on my last card. They seem to get 
totally trashed after I run uhd-fft a few times.


The main symptom is that if the B200mini is connected and I reboot, 
an fsck is done every time, and also has the effect of continually 
rebooting, and continually corrupting the card.


Unplug the B200mini and all is fine (after a couple of fscks). I 
managed to work out that if I remove the udev rule that starts up 
UHD (uhd-usrp.rules) I am also able to reboot with no issues. So a 
driver issue?


Without the udev rule I get the following, which I'm assuming is 
normal?:


[   24.555119] usb 3-1.1: device descriptor read/64, error -110
[   29.995114] usb 3-1.1: device descriptor read/64, error -110
[   45.675119] usb 3-1.1: device descriptor read/64, error -110
[   56.685085] usb 3-1.1: device not accepting address 5, error -62
[   67.565082] usb 3-1.1: device not accepting address 6, error -62
[   67.569976] usb 3-1-port1: unable to enumerate USB device

Hope you can help, thanks,

Dave.


___
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] UHD dropping samples running on Debian 9

[Meelis Nõmm via USRP-users]

Hello,

We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed
Debian 9 on it and tested Gnuradio on it. At first we installed via
apt-get. We saw some drops in the gnuradio-companion and had issue with
setting the real-time priority, so we removed it from the system and
installed it again with pybombs.
However, no difference. Today tested it again with UHD provided benchmark
example (for easy reference).  Saw occasional drops with Sps from 1e6 to
10e6. Thought it might be a network driver issue, updated the Intel network
driver with the latest(?) e1000e driver. Still no difference.

Any ideas, can we fix this somehow?
Thank you
Meelis

Additional information is in the file attached, but most important system
parameters:
#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-LM (rev 31)
filename:   /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/
intel/e1000e/e1000e.ko
version:3.3.5.10-NAPI


$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200;
UHD_3.11.0.git-181-g8f9f4184]
#system
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) 
#Network driver
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM 
(rev 31)
filename:   
/lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:3.3.5.10-NAPI



$ ./benchmark_rate --rx_rate 10e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184] 
Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[INFO] [USRP2] Detecting internal GPSDO 
[INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929
[INFO] [USRP2] Setting references to the internal GPSDO
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N210r4
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv4 RX+GDB
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv4 TX+GDB

Setting device timestamp to 0...
Testing receive rate 10.00 Msps on 1 channels
DD
Benchmark rate summary:
  Num received samples:289326
  Num dropped samples: 2178
  Num overflows detected:  0
  Num transmitted samples: 0
  Num sequence errors: 0
  Num underflows detected: 0
  Num late commands:   0
  Num timeouts:0


Done!

$ ./benchmark_rate --rx_rate 10e6 --duration 180

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184] 
Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[INFO] [USRP2] Detecting internal GPSDO 
[INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929
[INFO] [USRP2] Setting references to the internal GPSDO
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N210r4
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv4 RX+GDB
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv4 TX+GDB

Setting device timestamp to 0...
Testing receive rate 10.00 Msps on 1 channels
^X@sd

Benchmark rate summary:
  Num received samples:176569
  Num dropped samples: 0
  Num overflows detected:  0
  Num transmitted samples: 0
  Num sequence errors: 0
  Num underflows detected: 0
  Num late commands:   0
  Num timeouts:0


Done!

$ ./benchmark_rate --rx_rate 10e6 --duration 180

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184] 
Creating the usrp device with: ...
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[INFO] [USRP2] Detecting internal GPSDO 
[INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929
[INFO] [USRP2] Setting references to the internal GPSDO
Using Device: Single USRP:
  Device: USRP2 / N-Series Device
  Mboard 0: N210r4
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv4 RX+GDB
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv4 TX+GDB

Setting device timestamp to 0...
Testing receive rate 10.00 Msps on 1 channels
D
Benchmark rate summary:
  Num received samples:174194
  Num dropped samples: 1815
  Num overflows detected:  0
  Num transmitted samples: 0
  Num sequence errors: 0
  Num underflows detected: 0
  Num late commands:   0
  Num timeouts:0


Done!

$ ./benchmark_rate --rx_rate 5e6 --duration 300

[INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; 
UHD_3.11.0.git-181-g8f9f4184] 
Creating the u

[USRP-users] [RFNoC][BLOCK DESIGN] Questions about design in RFNoC

[LCD PI via USRP-users]

Hi everybody,

We are working in a PRBS Generator and the idea is to make it works with
the RFNoC structure. But we are having some troubles and need some help on
it. Could you please clarify this four points? :


1. Trying to understand the functionality of a RFNoC Generator, we were
trying to transmit a signal with RFNoC:Siggen block on Ettus E310. This
signal will be received by a laptop through a RTL-SDR dongle with GNURadio.

Flowgraph of transmitter that we generated on the E310:

Note: we also put the RFNoC FIFO between the RFNoc Radio and the SigGen.

Flowgraph of the receiver on our laptop:

[image: print2.png]

Software versions in use:

UHD: UHD_4.0.0.HEAD-239-g89427e8c

GNURADIO: 3.7.9.3

When we executed the transmitter flowgraph illustrated above, and trigger
“Enable” to 1,  the TX indicator led turn red but the receiver doesn’t show
our signal.

But if we change the flowgraph into this:


In this case, when we trigger “Enable” to 1, we can see our signal spectrum
in the receiver.


   1.

   Why we cannot generate and transmit data directly in the FPGA without
   “up” to the PS?
   2.

   Is there any incompatibility between the RFNoC: Siggen block and the
   E310?
   3.

   Are we forgetting some configurations  ?


2. The second question is about Datatypes, we are designing a PRBS
Generator with LFSR method, which generates data of 32bits in our IP Core
with this format:

   16 I bits, 16 Q bits.

   -

   1 → [16’b1, 16’b0]
   -

   0 → [16’b0, 16’b0]


En archivo de configuracion de UHD (xml) configuramos el host type como
fc32 y el otw type como sc16,

In the configuration file of the UHD “XML” we set the host type in FC32 and
the OTW in SC16, but when we run our example in the GnuRadio the QT TIME
SINK doesn’t show 0’s and 1’s, but instead we see smaller values ( 0’s and
0,30519). This make us think that the I and Q values were interpreted
like a Q15 format.

So, we made some changes in our Verilog Code and generate data using the
fixed-point format (signed Q15), like this:

   16 I bits , 16 Q bits.

   1 sign bit - 15 fractional I bits , 1 sign bit - 15 fractional Q
bits .

   -

   1 → [1’b0 - 15’d32767, 1’b0 - 15’b0]
   -

   0 → [1’b0 - 15’b0, 1’b0 - 15’b0]


After that, values of 1’s and 0’s were observed in QT TIME SINK.


   1.

   Can we say that the data inside our IPCORE must be mandatory generated
   like a signed Q15 type, or we are misunderstanding something?


3. In addition to RFNoC block, we created the same block in Python language
for GNURadio. This, like FPGA block, generate 1's and 0's but in a "bit to
bit" mode. Our problem is that we cannot know the run frequency of the
block in the PS (in the FPGA the blocks are connected to the radio_clk).
When we connect this block to the QT TIME SINK, we can see the generate
data without problem; but when we try to “down” to the FPGA and transmit
that data with the RFNoC:Radio, the TX red led does not turn on and we
obtain Underflow.


   1.

   If our block can not generate data at the same rate that RFNoC:Radio
   block was configure, is there any way to resolve/avoid the Underflow?


4. The Ettus web page say that this bandwidth between PS and PL is 10MS/s,
but does not explain under what circumstances.


   1.

   Is there any way to measure the data bandwidth between the PS and PL?


Regards and thanks for your time.

Ruben Vogel


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

Re: [USRP-users] Porting from x86 to armv7 (Ettus E310) - performance issues

[Marcus Müller via USRP-users]

I'm not feeling the same guilt, Philip, so I'll just go ahead and
"complain" about ARM :D

So, the ARM/Thumb instruction sets don't come with a Modulo instruction;
Hence, "a%b" very likely is implemented as

a-⎣a/b⎦·b

And integer division often takes multiple cycles, and even more so, can
take 4 up to 20 cycles (IIRC, but that might've been on an A7). NEON,
the ARM SIMD instruction set extension, afaik doesn't even *have* a
vectorized division operation, so this takes *at least* four cycle for
the `a/b`, one for the `·b`, and one for the `a-`, and then you use that
to address an array, so there's another multiply/accumulate happening
there. That's a minimum of 8 cycles just to know where to store the
result of whatever you do in `= …`. Of course, take this with a grain of
salt, compilers aren't stupid :)

So, the first thing I'd try is make your counter / index variable `int
i` an `unsigned int i`, and the same for your size variable `arr_size`.
(I'd still argue that the compiler *should* be inferring that `i` can
only take signed values, but we don't know it does.)

I'd even go as far as simply using `size_t arr_size` being the "optimal"
way, because that way you tell your compiler that it must use an integer
type that can hold the largest array size your architecture can deal
with (`size_t` is in stddef.h, and an unsigned type, btw). I'm sometimes
a bit zealous about making sure that size and counter variables are
unsigned numbers – that way, your compiler will warn you whenever you
are comparing a counter to a signed int, which can only count "half as
far", and also, in function signatures, will tell you early on when
there might be a corner case where you e.g. `malloc(-1 * sizeof(int))`
or so.

As Philip said, you can improve that if you have knowledge about
`arr_size`. If it's a power of 2, then `i%arr_size=i&(arr_size-1)`, for
example.

There's also beauty in having an outer loop that simply runs from 0 to
`arr_size` and an inner loop that iterates over all the `i` that are in
the same rest class mod arr_size: If you do it that way, your stores
will be linear in memory, and that's something you want to avoid
unnecessarily updating cache lines mulitple times.

Best regards,
Marcus

On 07.09.2017 04:21, Philip Balister via USRP-users wrote:
> On 09/06/2017 10:17 PM, Philip Balister via USRP-users wrote:
>>
>> On 09/06/2017 07:07 PM, Taliver Heath wrote:
>>> I had the same issues -- the big performance eater in my case was anything
>>> that was doing modulo in a tight loop.
>>>
>>> So, if you have something like:
>>>
>>> for ( int i = 0; i < 1000; i++) {
>>>   array[i % arr_size] = ...
>>> }
>> Yeah, basically the % operator has a poor implementation. I found this
> OK, feel guilty saying poor implementation :)
>
> % calculates the remainder after a division. So far two number, without
> any idea how you got there, I'm sure it is fine. If you are using it to
> detect a counter going past a number, you are doing it wrong :)
>
> Philip
>
>> out yeara ago. Really glad it made it to the list. Just count and reset
>> back to zero when you overflow.
>>
>> Philip
>>
>>> You'll take a pretty big hit.
>>>
>>> On Wed, Sep 6, 2017 at 4:00 PM, Tom Bereknyei via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 We ran into a similar issue. Big things that helped us was to move high
 rate dsp calculations to RFNoC.

 I've also had luck with volk_profile. It seems to help with some
 workloads.
 On Wed, Sep 6, 2017 at 16:53 Philip Balister via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> On 09/06/2017 04:38 PM, Marcus Müller via USRP-users wrote:
>> Hi Mr Hamilton,
>>
>> So, what you'd want to optimize first depends on what needs the most
>> optimization. Your x86 program might be a good place to start looking
>> into what the bottleneck is. If you're running Linux on your x86, I can
>> heartily recommend `perf`, which is a tool that lets you display live,
>> record and analyze the points in your code where the program spends most
>> time.
> "perf top" gives results pretty quickly.
>
> It also sounds like you aren't using both cpu's to the full extent.
> Maybe there is just one block doing all the work?
>
> Also, looking at using rfnoc to do high rate functions to reduce
> calculations that need doing on the arm is a good plan.
>
> Philip
>
>> In general, modern x86 have way larger memory bandwidth and larger CPU
>> caches, so that alone can become critical, but also things like more
>> capable SIMD instructions and less hardware-handling overhead.
>>
>> I don't know whether this helped you much, but I hope it's a start,
>> best regards,
>>
>> Marcus Müller
>>
>> On 09/06/2017 10:06 PM, S Hamilton via USRP-users wrote:
>>> We're moving an application that we had running on pc hardware with
>>> the Ettus B210, to the embedded arm E310.  On the pc side 

Re: [USRP-users] The difference for usrp source

[Marcus Müller via USRP-users]

Hi John,

the one "USRP Source" with three addresses combines both X310 in one UHD
"multi_usrp". The most prominent advantage of that is that UHD will
automatically try to align the sample streams coming from the USRPs
according to the timestamps in the metadata coming from the USRPs.

But that can only work if you coordinate the device time on both X310.

Best regards,
Marcus


On 07.09.2017 10:08, john liu via USRP-users wrote:
> Hi all,
> If we wan to make a 1TX and 3RX with 2 x310s,we can do like this:
>
> Also we can do like this:
>
> Could tell me the difference between them.
> In fact,in the second method,the transmiting and receiving stream work
> alternatively, several seconds receiving and then several seconds
> transmitting ( I learn this by seeing the LED in the front panel).
>
> best reagrds
> John
>
>
> ___
> 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] Error using coder.internal.errorIf (line 8) The input signal must be complex.

[Marcus Müller via USRP-users]

Hi Nur Qalbi,

with that info, we can't really infer what's wrong with your Matlab
program. You'll have to give a more comprehensive error description, and
that means you'll probably have to investigate some more on your own.

Apologies,

Marcus


On 08.09.2017 04:07, nur qalbi via USRP-users wrote:
>
> hi.i am using MATLAB R2016a os Ubuntu 14.04.i have two USRP N210. i
> have done follow all the instruction from github :
> https://github.com/80211bSDR/LinkLayer-MATLAB
>
> i have faced problem when trying transmit DATA to 2nd USRP,i found an
> error like below:
>
> Error using coder.internal.errorIf (line 8) The input signal must be
> complex.
>
> hope anyone can give idea.how to solve this problem.
>
>
>
> ___
> 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