Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: weird FFT behavior (Federico Larroca)
2. Frequency Hopping with B200 Issue? (Richard Bell)
3. Re: Frequency Hopping with B200 Issue? (Marcus D. Leech)
4. Re: Frequency Hopping with B200 Issue? (Richard Bell)
5. Re: Frequency Hopping with B200 Issue? (Marcus D. Leech)
6. Re: Frequency Hopping with B200 Issue? (Richard Bell)
7. Re: Frequency Hopping with B200 Issue? (Richard Bell)
8. Re: Frequency Hopping with B200 Issue? (Marcus D. Leech)
9. Re: Frequency Hopping with B200 Issue? (Richard Bell)
10. Fwd: get_rx_sensor exceptions (Kevin McGuire)
11. Re: Frequency Hopping with B200 Issue? (Ian Buckley)
12. Re: Frequency Hopping with B200 Issue? (Sylvain Munaut)
13. "deaf" WBX daughterboard (Keith)
14. Re: "deaf" WBX daughterboard (Marcus D. Leech)
15. AssertionError: accum_timeout <_timeout (Swanson, Craig)
16. Re: AssertionError: accum_timeout <_timeout (James Humphries)
----------------------------------------------------------------------
Message: 1
Date: Thu, 14 Apr 2016 15:34:40 -0300
From: Federico Larroca <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] weird FFT behavior
Message-ID:
<cahe2e1jcgrlksw8mt6c4hq2vpusd0pkd20h5znbfpmmdf5f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Matt,
Thank you for the quick answer. Here's what I've obtained. When using a
central frequency 300.25, the weird signal has moved up by (approximately)
1 MHz (or maybe 0.75MHz?).
[image: Im?genes integradas 1]
I've looked around a bit the spectrum for the "original" signal, and here's
what I've found (at 893 MHz) which looks similar:
[image: Im?genes integradas 1]
I have two questions then:
1 - What generates this phenomena? This is probably an answer I should
know already, but maybe there is a reference I may read (or keyword I may
look up).
2- How can I make sure that what I see is actually a signal at that
frequency, and not an harmonic of another signal? The example I mentioned
at 180MHz shows what seems like a DTV channel, and it sometimes masks the
analog TV channels, which may be much more disturbing than the figures I
show here.
best,
Federico
2016-04-14 14:26 GMT-03:00 Matt Ettus <[email protected]>:
>
> What you are seeing is most likely not at exactly the frequency it looks
> like, and you may be looking at a subharmonic. Instead of shifting from
> 300 to 307, try moving to 300.25. Does the signal of interest move towards
> the middle of the display, or away? Does it move exactly 0.25 MHz, or a
> multiple of that?
>
> Matt
>
> On Thu, Apr 14, 2016 at 7:37 AM, Federico Larroca via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> We have been using USRPs for some years now, mostly for teaching. One of
>> the first things we show is naturally the spectrum. Some time ago we have
>> seen a weird behavior in certain frequencies.
>>
>> For instance, when using a b200 centered at 300MHz (sampling rate 20MS/s)
>> obtains the following:
>> [image: Im?genes integradas 1]
>>
>> Apparently, there is something interesting around 307MHz. When we
>> re-center the frequency we obtain the following:
>>
>> [image: Im?genes integradas 2]
>>
>> The interesting signal is gone. This is just an example. We get similar
>> behaviors at different frequencies (e.g. 180MHz).
>>
>> Maybe it's a known phenomena which we ignore. Interestingly, it's present
>> also in our b100, and using the simple FFT (the examples are made with the
>> cool gr-fosphor).
>>
>> Can anybody give us a pointer?
>> Best regards,
>> Federico
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/09b69a1a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 307M_b200_samp_20M.png
Type: image/png
Size: 705376 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/09b69a1a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 885M_b200_samp_20M.png
Type: image/png
Size: 1255330 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/09b69a1a/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 300M_b200_samp_20M.png
Type: image/png
Size: 742197 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/09b69a1a/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 300250k_b200_samp_20M.png
Type: image/png
Size: 870103 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/09b69a1a/attachment-0007.png>
------------------------------
Message: 2
Date: Thu, 14 Apr 2016 18:17:12 -0700
From: Richard Bell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<CAMMoi3sTcS=ud1FD+uE4mjFzoUJz=_ep_-aj9ioszvfhui6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I've been testing the frequency hopping capabilities of the N210 and B100
the past few weeks and just started playing with the B200. I'm finding that
calls to set_center_freq(target_freq) on the N210 and B100 take in the
hundreds of microsecond range of time to return from while the B200 takes 3
milliseconds to return from that call, an order of magnitude longer. Is
this expected or is there a bug in the B200 code?
I updated everything on my computer to the latest, GNU Radio 3.7.10, UHD
3.9.3 and downloaded the latest firmware image and fpga source to the
radios. Running on Ubuntu 14.04.
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/51fbff93/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 14 Apr 2016 21:35:07 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
> Hi all,
>
> I've been testing the frequency hopping capabilities of the N210 and
> B100 the past few weeks and just started playing with the B200. I'm
> finding that calls to set_center_freq(target_freq) on the N210 and
> B100 take in the hundreds of microsecond range of time to return from
> while the B200 takes 3 milliseconds to return from that call, an order
> of magnitude longer. Is this expected or is there a bug in the B200 code?
>
> I updated everything on my computer to the latest, GNU Radio 3.7.10,
> UHD 3.9.3 and downloaded the latest firmware image and fpga source to
> the radios. Running on Ubuntu 14.04.
>
> Rich
>
The RFFE chip (AD9361) requires a *lot* longer to change frequencies,
and Ettus R&D have worked fairly hard to reduce this as much as
possible--not sure if there are other optimizations available in the
code-base.
Not sure there's much more that can be done--the AD9361 wasn't really
designed for fast frequency-hopping, changing frequencies requires
a *bunch* of things to be setup inside the chip, not just the
synthesizer.
------------------------------
Message: 4
Date: Thu, 14 Apr 2016 18:47:16 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<cammoi3ue7uhlsqssxmeqmnfhknmycgpmxuxogrxjx2th5_6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Does it make sense to you that the B100 would outperform the B200 in this
domain by an order of magnitude?
Rich
On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>
>> Hi all,
>>
>> I've been testing the frequency hopping capabilities of the N210 and B100
>> the past few weeks and just started playing with the B200. I'm finding that
>> calls to set_center_freq(target_freq) on the N210 and B100 take in the
>> hundreds of microsecond range of time to return from while the B200 takes 3
>> milliseconds to return from that call, an order of magnitude longer. Is
>> this expected or is there a bug in the B200 code?
>>
>> I updated everything on my computer to the latest, GNU Radio 3.7.10, UHD
>> 3.9.3 and downloaded the latest firmware image and fpga source to the
>> radios. Running on Ubuntu 14.04.
>>
>> Rich
>>
>> The RFFE chip (AD9361) requires a *lot* longer to change frequencies, and
> Ettus R&D have worked fairly hard to reduce this as much as possible--not
> sure if there are other optimizations available in the code-base.
>
> Not sure there's much more that can be done--the AD9361 wasn't really
> designed for fast frequency-hopping, changing frequencies requires
> a *bunch* of things to be setup inside the chip, not just the
> synthesizer.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/2b6317d4/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 14 Apr 2016 21:52:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/14/2016 09:47 PM, Richard Bell wrote:
> Does it make sense to you that the B100 would outperform the B200 in
> this domain by an order of magnitude?
>
> Rich
3msec is pretty good for the AD9361.
What card did you have in the B100?
>
> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>
> Hi all,
>
> I've been testing the frequency hopping capabilities of the
> N210 and B100 the past few weeks and just started playing with
> the B200. I'm finding that calls to
> set_center_freq(target_freq) on the N210 and B100 take in the
> hundreds of microsecond range of time to return from while the
> B200 takes 3 milliseconds to return from that call, an order
> of magnitude longer. Is this expected or is there a bug in the
> B200 code?
>
> I updated everything on my computer to the latest, GNU Radio
> 3.7.10, UHD 3.9.3 and downloaded the latest firmware image and
> fpga source to the radios. Running on Ubuntu 14.04.
>
> Rich
>
> The RFFE chip (AD9361) requires a *lot* longer to change
> frequencies, and Ettus R&D have worked fairly hard to reduce this
> as much as possible--not sure if there are other optimizations
> available in the code-base.
>
> Not sure there's much more that can be done--the AD9361 wasn't
> really designed for fast frequency-hopping, changing frequencies
> requires
> a *bunch* of things to be setup inside the chip, not just the
> synthesizer.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/15e86762/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 14 Apr 2016 18:54:58 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<cammoi3vmvf+_gpagh8swewkys05jso_ryhlq5fjoehkcnmx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I tried both the WBX and the SBX, they showed very similar times.
On Thu, Apr 14, 2016 at 6:52 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/14/2016 09:47 PM, Richard Bell wrote:
>
> Does it make sense to you that the B100 would outperform the B200 in this
> domain by an order of magnitude?
>
> Rich
>
> 3msec is pretty good for the AD9361.
>
> What card did you have in the B100?
>
>
>
> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>>
>>> Hi all,
>>>
>>> I've been testing the frequency hopping capabilities of the N210 and
>>> B100 the past few weeks and just started playing with the B200. I'm finding
>>> that calls to set_center_freq(target_freq) on the N210 and B100 take in the
>>> hundreds of microsecond range of time to return from while the B200 takes 3
>>> milliseconds to return from that call, an order of magnitude longer. Is
>>> this expected or is there a bug in the B200 code?
>>>
>>> I updated everything on my computer to the latest, GNU Radio 3.7.10, UHD
>>> 3.9.3 and downloaded the latest firmware image and fpga source to the
>>> radios. Running on Ubuntu 14.04.
>>>
>>> Rich
>>>
>>> The RFFE chip (AD9361) requires a *lot* longer to change frequencies,
>> and Ettus R&D have worked fairly hard to reduce this as much as
>> possible--not sure if there are other optimizations available in the
>> code-base.
>>
>> Not sure there's much more that can be done--the AD9361 wasn't really
>> designed for fast frequency-hopping, changing frequencies requires
>> a *bunch* of things to be setup inside the chip, not just the
>> synthesizer.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/42fc48b3/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 14 Apr 2016 18:57:46 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<cammoi3upjd6o4ju0alj8qqwumaakj3---fmommsuoee+byc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Similar meaning they were both in the hundreds of microsecond range.
On Thu, Apr 14, 2016 at 6:54 PM, Richard Bell <[email protected]>
wrote:
> I tried both the WBX and the SBX, they showed very similar times.
>
> On Thu, Apr 14, 2016 at 6:52 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 04/14/2016 09:47 PM, Richard Bell wrote:
>>
>> Does it make sense to you that the B100 would outperform the B200 in this
>> domain by an order of magnitude?
>>
>> Rich
>>
>> 3msec is pretty good for the AD9361.
>>
>> What card did you have in the B100?
>>
>>
>>
>> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've been testing the frequency hopping capabilities of the N210 and
>>>> B100 the past few weeks and just started playing with the B200. I'm finding
>>>> that calls to set_center_freq(target_freq) on the N210 and B100 take in the
>>>> hundreds of microsecond range of time to return from while the B200 takes 3
>>>> milliseconds to return from that call, an order of magnitude longer. Is
>>>> this expected or is there a bug in the B200 code?
>>>>
>>>> I updated everything on my computer to the latest, GNU Radio 3.7.10,
>>>> UHD 3.9.3 and downloaded the latest firmware image and fpga source to the
>>>> radios. Running on Ubuntu 14.04.
>>>>
>>>> Rich
>>>>
>>>> The RFFE chip (AD9361) requires a *lot* longer to change frequencies,
>>> and Ettus R&D have worked fairly hard to reduce this as much as
>>> possible--not sure if there are other optimizations available in the
>>> code-base.
>>>
>>> Not sure there's much more that can be done--the AD9361 wasn't really
>>> designed for fast frequency-hopping, changing frequencies requires
>>> a *bunch* of things to be setup inside the chip, not just the
>>> synthesizer.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/0dac2b4d/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 14 Apr 2016 21:58:38 -0400
From: "Marcus D. Leech" <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/14/2016 09:54 PM, Richard Bell wrote:
> I tried both the WBX and the SBX, they showed very similar times.
Yes, that's expected--they both use the same synthesizer chip.
>
> On Thu, Apr 14, 2016 at 6:52 PM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 04/14/2016 09:47 PM, Richard Bell wrote:
>> Does it make sense to you that the B100 would outperform the B200
>> in this domain by an order of magnitude?
>>
>> Rich
> 3msec is pretty good for the AD9361.
>
> What card did you have in the B100?
>
>
>>
>> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>>
>> Hi all,
>>
>> I've been testing the frequency hopping capabilities of
>> the N210 and B100 the past few weeks and just started
>> playing with the B200. I'm finding that calls to
>> set_center_freq(target_freq) on the N210 and B100 take in
>> the hundreds of microsecond range of time to return from
>> while the B200 takes 3 milliseconds to return from that
>> call, an order of magnitude longer. Is this expected or
>> is there a bug in the B200 code?
>>
>> I updated everything on my computer to the latest, GNU
>> Radio 3.7.10, UHD 3.9.3 and downloaded the latest
>> firmware image and fpga source to the radios. Running on
>> Ubuntu 14.04.
>>
>> Rich
>>
>> The RFFE chip (AD9361) requires a *lot* longer to change
>> frequencies, and Ettus R&D have worked fairly hard to reduce
>> this as much as possible--not sure if there are other
>> optimizations available in the code-base.
>>
>> Not sure there's much more that can be done--the AD9361
>> wasn't really designed for fast frequency-hopping, changing
>> frequencies requires
>> a *bunch* of things to be setup inside the chip, not just
>> the synthesizer.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/14f7c662/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 14 Apr 2016 18:59:12 -0700
From: Richard Bell <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<CAMMoi3vpKTDbeyoVtep=0=jn5wgodnxrp6acjzsvdpmaofz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Alright thanks for the feedback Marcus.
Rich
On Thu, Apr 14, 2016 at 6:58 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/14/2016 09:54 PM, Richard Bell wrote:
>
> I tried both the WBX and the SBX, they showed very similar times.
>
> Yes, that's expected--they both use the same synthesizer chip.
>
>
>
> On Thu, Apr 14, 2016 at 6:52 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 04/14/2016 09:47 PM, Richard Bell wrote:
>>
>> Does it make sense to you that the B100 would outperform the B200 in this
>> domain by an order of magnitude?
>>
>> Rich
>>
>> 3msec is pretty good for the AD9361.
>>
>> What card did you have in the B100?
>>
>>
>>
>> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've been testing the frequency hopping capabilities of the N210 and
>>>> B100 the past few weeks and just started playing with the B200. I'm finding
>>>> that calls to set_center_freq(target_freq) on the N210 and B100 take in the
>>>> hundreds of microsecond range of time to return from while the B200 takes 3
>>>> milliseconds to return from that call, an order of magnitude longer. Is
>>>> this expected or is there a bug in the B200 code?
>>>>
>>>> I updated everything on my computer to the latest, GNU Radio 3.7.10,
>>>> UHD 3.9.3 and downloaded the latest firmware image and fpga source to the
>>>> radios. Running on Ubuntu 14.04.
>>>>
>>>> Rich
>>>>
>>>> The RFFE chip (AD9361) requires a *lot* longer to change frequencies,
>>> and Ettus R&D have worked fairly hard to reduce this as much as
>>> possible--not sure if there are other optimizations available in the
>>> code-base.
>>>
>>> Not sure there's much more that can be done--the AD9361 wasn't really
>>> designed for fast frequency-hopping, changing frequencies requires
>>> a *bunch* of things to be setup inside the chip, not just the
>>> synthesizer.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/a08c3c81/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 14 Apr 2016 21:07:38 -0500
From: Kevin McGuire <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: get_rx_sensor exceptions
Message-ID:
<CACVSex==-syvqztv-dud-kkxkvtbkuuxhzpztw22unx-_tz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Jan 29, 2016 at 12:17 PM, Michael West via USRP-users <
[email protected]> wrote:
> Hi tilla,
>
> Unlike the socket buffer for the data streams, the socket buffer for the
> control packets is not resized by UHD. There can be up to 64 control
> transactions in flight for each of the 2 radios at any given time. Each of
> those results in an ACK packet that is only ~58 bytes, but some drivers
> will allocate enough memory from the socket buffer to hold an entire MTU.
> If your MTU size is 9000, then you will need a default buffer that is at
> least 1,152,000 bytes (9000 bytes x 64 ACKs x 2 radios). Another option is
> to reduce the MTU size to 1500.
>
> Regards,
> Michael
>
> On Fri, Jan 29, 2016 at 8:49 AM, <[email protected]> wrote:
>
>> The only thing that doesnt make sense is re-arranging the threading does
>> not change the workload on the ethernet segment, we still run at the same
>> sample rate, we just dont simultaneously retune tx and rx...
>>
>> I am not going to lose any sleep over this cuz the application works with
>> the updated architecture :), but it still a bit perplexing...
>>
>> ------------------------------
>> *From: *"Michael West" <[email protected]>
>> *To: *"Marcus D. Leech" <[email protected]>
>> *Cc: *[email protected], "usrp-users" <[email protected]>
>> *Sent: *Thursday, January 28, 2016 6:34:21 PM
>>
>> *Subject: *Re: [USRP-users] get_rx_sensor exceptions
>>
>> Hi tilla,
>>
>> The assertion failure of "packet_info.packet_count == (seq_to_ack &
>> 0xfff)" indicates a control packet was dropped. We have seen this caused
>> by the default socket buffer size being too small. Try increasing the
>> default socket buffer size to a minimum of 2 MB (sudo sysctl
>> net.core.rmem_default=2097152.
>>
>> Regards,
>> Michael
>>
>
Users,
I have the same error using the B200. I am not sure what model the original
author in this thread was using; however, I do believe it may have been one
of the models that communicates over a Ethernet type network while mine
communicates over USB 2.0 specifically.
I may be able to dig into the source code and find this, but I wanted to
throw it out there and perhaps if anyone has any information or insight
into the issue I would be very graced to hear of it. I am currently having
the issue when using GNU Radio and doing a few top_block *lock* and
*unlock* calls
in very tight sequence. It takes about 4 back to back sets of lock and
unlock calls to trigger it.
*It may be that I simply have to produce some latency between the calls.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/07ecad83/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 14 Apr 2016 19:08:39 -0700
From: Ian Buckley <[email protected]>
To: Richard Bell <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Richard.
B100 and N210 are both using classic daughter cards built from RF discrete
parts. Hopping is largely a function of a retune of the discrete synthesizer.
IQ imbalance correction is done via a pre-calibrated table.
B200 uses an integrated radio. Hopping also involves a synthesizer retune, but
in this case on the fly recalibration is also performed depending on the
distance of the retune including IQ imbalance correction.
The second approach just has to do more for each retuning event.
-Ian
On Apr 14, 2016, at 6:54 PM, Richard Bell via USRP-users
<[email protected]> wrote:
> I tried both the WBX and the SBX, they showed very similar times.
>
> On Thu, Apr 14, 2016 at 6:52 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/14/2016 09:47 PM, Richard Bell wrote:
>> Does it make sense to you that the B100 would outperform the B200 in this
>> domain by an order of magnitude?
>>
>> Rich
> 3msec is pretty good for the AD9361.
>
> What card did you have in the B100?
>
>
>>
>> On Thu, Apr 14, 2016 at 6:35 PM, Marcus D. Leech via USRP-users
>> <[email protected]> wrote:
>> On 04/14/2016 09:17 PM, Richard Bell via USRP-users wrote:
>> Hi all,
>>
>> I've been testing the frequency hopping capabilities of the N210 and B100
>> the past few weeks and just started playing with the B200. I'm finding that
>> calls to set_center_freq(target_freq) on the N210 and B100 take in the
>> hundreds of microsecond range of time to return from while the B200 takes 3
>> milliseconds to return from that call, an order of magnitude longer. Is this
>> expected or is there a bug in the B200 code?
>>
>> I updated everything on my computer to the latest, GNU Radio 3.7.10, UHD
>> 3.9.3 and downloaded the latest firmware image and fpga source to the
>> radios. Running on Ubuntu 14.04.
>>
>> Rich
>>
>> The RFFE chip (AD9361) requires a *lot* longer to change frequencies, and
>> Ettus R&D have worked fairly hard to reduce this as much as possible--not
>> sure if there are other optimizations available in the code-base.
>>
>> Not sure there's much more that can be done--the AD9361 wasn't really
>> designed for fast frequency-hopping, changing frequencies requires
>> a *bunch* of things to be setup inside the chip, not just the synthesizer.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160414/151f6c45/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 15 Apr 2016 07:54:11 +0200
From: Sylvain Munaut <[email protected]>
Cc: Richard Bell <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping with B200 Issue?
Message-ID:
<cahl+j099qtgdpvewx3xjbmwwp9desf+j5dbm5znzhbacpqt...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
Note that the ADI chip also has a "fast re-tune" function for frequency hopping.
It's not usable via the standard UHD API because it doesn't fit the
model, you have to "pre-learn" the frequencies you want to tune to,
and ideally they also have to fit in the same ADI frequency band (so
you don't have to change the gain table). Search the archives, it's
been discussed many times.
Cheers,
Sylvain
PS: Also for the B100/N210, isn't the tune command just "set and
forget" ? (i.e. it doesn't wait for the tune to actually have
happenned, it just returns as soon as the command is sent). That's
what I remember, but I might be mistaken.
------------------------------
Message: 13
Date: Fri, 15 Apr 2016 13:22:58 +0100
From: Keith <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] "deaf" WBX daughterboard
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi all,
I've recently had returned to my possession an N210 with WBX and GPSDO
that I bought in 2011 and it's been around the world since then and has
done a fine job allowing us to demo community GSM.
Unfortunately, I found while running some basic tests that it couldn't
see (hear) anything at all on the spectrum.
It could see however, 5W from a handset on VHF as long as it was less
than 8-10 meters away, yes. five watts!
I was also able to get it to receive one of those little car cigarette
lighter FM transmitters at up to 1 metre with an antenna connected.
It makes no difference which antenna was selected or which port the
antenna was actually connected to, In all combinations, removing the
antenna deafened the WBX to that FM signal.
Then I found this from a few years ago where Marcus D. Leech wrote in a
thread:
> Both WBX use the same 31.5dB step attenuator in the receive path.
>
> Is it possible that your "old" WBX has a damaged LNA, and so it's
> somewhat deaf?
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-September/010746.html
I'm wondering is that the case. As I said, this board has been around
and has had all kinds of things connected to it, including those chinese
GSM repeater black boxes, although I have observed it working well for
some time after that happened. I don't know what else it's been through
in the last 3 years.
My question to the list is, is there any possibility that this could be
software related?
And another question, then; Would any of the good folks at Ettus be able
to offer a solution in terms of repair?
I wonder is the LNA, (if that is indeed the problem), part of the GDB? -
although I remember from 2011 considering a hardware modification and
asking ettus if I could purchase the GDB seperately and they responded
that not really, IIRC
Or is the only thing for it to purchase a new daughterboard?
Many thanks!
Keith.
------------------------------
Message: 14
Date: Fri, 15 Apr 2016 09:00:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] "deaf" WBX daughterboard
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/15/2016 08:22 AM, Keith via USRP-users wrote:
> Hi all,
>
> I've recently had returned to my possession an N210 with WBX and GPSDO
> that I bought in 2011 and it's been around the world since then and has
> done a fine job allowing us to demo community GSM.
>
> Unfortunately, I found while running some basic tests that it couldn't
> see (hear) anything at all on the spectrum.
> It could see however, 5W from a handset on VHF as long as it was less
> than 8-10 meters away, yes. five watts!
> I was also able to get it to receive one of those little car cigarette
> lighter FM transmitters at up to 1 metre with an antenna connected.
> It makes no difference which antenna was selected or which port the
> antenna was actually connected to, In all combinations, removing the
> antenna deafened the WBX to that FM signal.
>
> Then I found this from a few years ago where Marcus D. Leech wrote in a
> thread:
>> Both WBX use the same 31.5dB step attenuator in the receive path.
>>
>> Is it possible that your "old" WBX has a damaged LNA, and so it's
>> somewhat deaf?
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-September/010746.html
>
> I'm wondering is that the case. As I said, this board has been around
> and has had all kinds of things connected to it, including those chinese
> GSM repeater black boxes, although I have observed it working well for
> some time after that happened. I don't know what else it's been through
> in the last 3 years.
>
> My question to the list is, is there any possibility that this could be
> software related?
>
> And another question, then; Would any of the good folks at Ettus be able
> to offer a solution in terms of repair?
>
> I wonder is the LNA, (if that is indeed the problem), part of the GDB? -
> although I remember from 2011 considering a hardware modification and
> asking ettus if I could purchase the GDB seperately and they responded
> that not really, IIRC
> Or is the only thing for it to purchase a new daughterboard?
>
> Many thanks!
>
> Keith.
>
>
If you have access to someone with SMD re-work skills and equipment,
replacing the LNA chip on the GDB should be fairly straightforward,
and is very-likely the cause of your grief.
The LNA is an MGA-62563, available through DigiKey and other on-line
electronics retailers. It's also possible that it's the 2nd-stage
LNA, on the main board, an MGA-82563.
The early WBX boards (yours) didn't have TVS protection diodes on them,
so were more susceptible to ESD and high-input power
damage issues.
I blew up my own WBX input last week (an early WBX) via a mechanism that
was not immediately obvious, even to someone who has been
mucking-about in radio since forever.
Otherwise, replacement of the WBX daughtercard is the only other
reasonable option.
------------------------------
Message: 15
Date: Fri, 15 Apr 2016 13:13:27 +0000
From: "Swanson, Craig" <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Martin,
I am running a B210 with my windows 7 computer running Virtualbox Ubuntu 14.04
and when I try to run this off the shelf flowgraph from your website tutorials
called gr-tutorial-spec-an.grc, I get the following error:
Executing: /usr/bin/python2 -u /home/craig/jida/gr-jida/examples/top_block.py
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
-- Detected Device: B210
-- Operating over USB 2.
Traceback (most recent call last):
File "/home/craig/jida/gr-jida/examples/top_block.py", line 162, in <module>
main()
File "/home/craig/jida/gr-jida/examples/top_block.py", line 150, in main
tb = top_block_cls()
File "/home/craig/jida/gr-jida/examples/top_block.py", line 78, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
122, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
2249, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: AssertionError: accum_timeout < _timeout
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235?
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/3e6ebf9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gr-tutorial-simple-spec-an.grc
Type: application/octet-stream
Size: 27173 bytes
Desc: gr-tutorial-simple-spec-an.grc
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/3e6ebf9e/attachment-0001.grc>
------------------------------
Message: 16
Date: Fri, 15 Apr 2016 11:27:56 -0400
From: James Humphries <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID:
<CAEwGFhW7=cgBETjZmTN41W=kaaHPmbHXo6Am-yUQRLoH0=c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
Have you had any luck previously using the VM under Virtualbox? Can you do
a uhd_usrp_probe or uhd_find_devices without error?
It seems like the OS is not getting a response from the B210 in time. VM
can be hit or miss, I have used VMWare successfully, but haven't tried
virtual box yet with USRP hardware.
-Trip
On Fri, Apr 15, 2016 at 9:13 AM, Swanson, Craig via USRP-users <
[email protected]> wrote:
> Martin,
>
> I am running a B210 with my windows 7 computer running Virtualbox Ubuntu
> 14.04 and when I try to run this off the shelf flowgraph from your website
> tutorials called gr-tutorial-spec-an.grc, I get the following error:
>
>
>
> Executing: /usr/bin/python2 -u
> /home/craig/jida/gr-jida/examples/top_block.py
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
>
> -- Detected Device: B210
> -- Operating over USB 2.
> Traceback (most recent call last):
> File "/home/craig/jida/gr-jida/examples/top_block.py", line 162, in
> <module>
> main()
> File "/home/craig/jida/gr-jida/examples/top_block.py", line 150, in main
> tb = top_block_cls()
> File "/home/craig/jida/gr-jida/examples/top_block.py", line 78, in
> __init__
> channels=range(1),
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2249, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: AssertionError: accum_timeout < _timeout
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235?
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/608c90ae/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 68, Issue 16
******************************************
