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: full-scale range on B210 (Sivan Toledo)
2. B210 theory (Dmitry Dmitry)
3. Timed out waiting for consecutive locks on sensor "lo_locked"
(Daniel Pascual)
4. Re: How to stop "usrp_spectrum_sense.py"? (Syed Aqeel Raza)
5. Re: Timed out waiting for consecutive locks on sensor
"lo_locked" (Ben Hilburn)
6. Re: B210 theory (Ben Hilburn)
7. USRP B210 schematic (Knee, Peter A)
8. Re: USRP B210 schematic (Marcus D. Leech)
9. Call for Proposals for GRCon14: Extended 1 Week (Michael Dickens)
10. Re: USRP n210 sram type (Matt Ettus)
11. Re: USRP n210 sram type (BHASKAR BANERJEE)
12. Re: How to stop "usrp_spectrum_sense.py"? (Martin Braun)
13. Re: full-scale range on B210 (Martin Braun)
14. Re: full-scale range on B210 (Sivan Toledo)
15. Re: B210 theory (Dmitry Dmitry)
16. B210 - FLASH on board? (Ralph A. Schmid, dk5ras)
17. Issue with changing the X3xx's IP Address (Robert Palumbo)
18. Re: Issue with changing the X3xx's IP Address (Nicholas Corgan)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Apr 2014 20:09:56 +0300
From: Sivan Toledo <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] full-scale range on B210
Message-ID:
<CAOL_ruE=_mrornvv8acuhwko2vrvzu6bub2lp6yagbpntup...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sure, I will record waveforms and send you. I did not look at the code;
what I see is that my code increases gain more and more (because it thought
that 9930 is far from full range) and the max stays at 9930. I'll record
the waveforms and share them.
Sivan
On Mon, Apr 7, 2014 at 5:53 PM, Ian Buckley <[email protected]> wrote:
> OK 2 issues here:
>
> First the concept that Mike introduced that the size of the ADC bus
> determines he maximum sample magnitude before overflow will occur. Because
> we use a range of converters and integrated radios from 12 through 16bits
> across products and also try to re-use the same FPGA modules, we have for
> usrp2 and usrp3 generations, standardized on the use of a complex sample
> data type that uses 16bits each for I and Q values, and these values are
> two's complement signed format. When a converter is smaller than 16bits we
> LEFT JUSTIFY the same smaller bus, in other words we use the MSB bits and
> truncate (or zero pad for Rx) the LSB's. Thus code becomes more portable
> between USRPs. So broadly speaking Sivan is correct to state that -32768 ->
> 32767 is the expected maximum dynamic range.
>
> Now the issue of Sivan's B210 overflowing with a 9930 sample magnitude.
> That is unexpected, I have myself recently encountered some B210 overflow
> issues at approx 85% of 32768, but nothing as low as this. We do apply a
> gain value internally to compensate for the algorithmic gain of the CORDIC
> algorithm, so that's one possible area we need to check. The waveform you
> see this on is of interest..is it possible you can share this flow graph
> with us? In general we do recommend people reserve some headroom when
> setting there scaling gain for the samples but not this much.
>
> -Ian
>
> On Apr 7, 2014, at 7:21 AM, Sivan Toledo <[email protected]> wrote:
>
> Thanks a lot Mike. The strange thing is that the N200, which is also not
> 16 bits but 14, delivers values that range from -32767 to +32767, so I
> guess some scaling is taking place in the N200's FPGA. It seems that the
> B210 is doing this differently.
>
> It would be good to specify the full scale values (perhaps using a UHD
> call), because it is required for AGC algorithms. This is where I bot
> bitten.
>
>
> On Mon, Apr 7, 2014 at 3:26 PM, Mike Jameson <[email protected]> wrote:
>
>> See page 3, paragraph 2.2.4 of the following paper I just discovered
>> which explains that the number is doubled due to complex sampling:
>>
>> http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p61.pdf
>>
>> Mike
>>
>>
>> --
>> Mike Jameson M0MIK BSc MIET
>> Email: [email protected]
>> Web: http://scanoo.com
>>
>>
>> On Mon, Apr 7, 2014 at 1:20 PM, Mike Jameson <[email protected]> wrote:
>>
>>> I clearly needed another coffee! The negative values are included in the
>>> full scale ADC range so I can only assume the value is doubled due to
>>> complex sampling taking place:
>>>
>>> http://www.ni.com/white-paper/3016/en/#toc5
>>>
>>> Mike
>>>
>>> --
>>> Mike Jameson M0MIK BSc MIET
>>> Email: [email protected]
>>> Web: http://scanoo.com
>>>
>>>
>>> On Mon, Apr 7, 2014 at 1:00 PM, Mike Jameson <[email protected]> wrote:
>>>
>>>> Sivan,
>>>>
>>>> The ADC in a N200 is 14-bit (2**14 = 16384) and the ADC in a B210 is
>>>> 12-bit (2**12 = 4096).
>>>>
>>>> If you multiply the number of quantisation points by two, to include
>>>> negative values (in the time domain), it looks close to what you are
>>>> seeing.
>>>>
>>>> Mike
>>>>
>>>> --
>>>> Mike Jameson M0MIK BSc MIET
>>>> Email: [email protected]
>>>> Web: http://scanoo.com
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 8:29 AM, Sivan Toledo <[email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I run the same UHD code on both the N200 and the B210. On the N200,
>>>>> full scale receive output (ADC is saturated) is 32767. On the B210, full
>>>>> scale appears to be 9930. This is at both 4MHz and 8MHz sample rate. The
>>>>> UHD code is identical.
>>>>>
>>>>> Is the full-scale range of the B210 indeed 9930? If not, is there a
>>>>> likely reason that I don't see higher values?
>>>>>
>>>>> Thanks, Sivan
>>>>>
>>>>> _______________________________________________
>>>>> 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/20140407/addd4d1b/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 04 Apr 2014 15:04:58 +0400
From: Dmitry Dmitry <[email protected]>
To: [email protected]
Subject: [USRP-users] B210 theory
Message-ID: <[email protected]>
Content-Type: text/plain
Hello,
Sorry for the stupid subject. I need some theoretical inquiry into the
structural scheme. At this moment I dont have a B210 platform, but I need to
know which part of this system controls the analog elements of the AD9361 and
where its located. For example, I need to change Rx_LO frequency. What elements
of the system, signal pass through. (PC->UHD FPGA->SPI bus->AD9361 SPI Regs?)
Sorry for my english, Its my second language.
Best Regards.
------------------------------
Message: 3
Date: Mon, 7 Apr 2014 12:32:09 +0200
From: Daniel Pascual <[email protected]>
To: [email protected]
Subject: [USRP-users] Timed out waiting for consecutive locks on
sensor "lo_locked"
Message-ID:
<cajzqpxa7xyzmrxjxw3vwozdemfu14zwauz4bwl8mkukzxvm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi. I get the next error when trying to receive with a DBSRX2 in USRPX310:
"timed out waiting for consecutive locks on sensor "lo_locked". For example
I use this command:
"rx_samples_to_file --file C:\usrp_samples.dat --type double --nsamps
10000000 --rate 25000000 --freq 1575420000 --gain 20 --bw 40000000 "
The driver version is UHD_003.007.000-1-stable. I increased the waiting
time with the "setup" option but it does not lock anyway. The program
"test_dboard_corecion" show no errors in tuning and locking. I also tried
different frequencies and to use an external 10 MHz signal.
The problem is the same for the 8 DBSRX2 and 4 USRPX310 in any possible
combination. I also have a USRPN210 which works well with the same
daughterboards. I also have a SBX-120 which seems to work well on the
USRPX310.
The strange thing is that the REF led on the front panel of the USRPX310
remains on even if there is no external reference signal.
Any idea on where the problem is? Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140407/152a62f9/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 7 Apr 2014 10:51:24 +0800
From: Syed Aqeel Raza <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to stop "usrp_spectrum_sense.py"?
Message-ID:
<CAGa9iCA6tRA0PNDcTUQV5C0=zuew5u2gqbnvav-jziyv8kk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin,
Good Day !!!
I somehow able to run the program and it successfully switches in between
of relay mode to sensing mode with respect to the mentioned time frame.
However, the program terminates by its own after switching two times from
relay mode to sensing mode and vice versa. I have been encountered with the
following error message:
"RuntimeError: boost::thread_resource_error: Resource temporarily
unavailable"
For detailed information about this error message, see the attached file.
Waiting for your reply, thanks.
Regards,
Syed Aqeel Raza
> Date: Fri, 04 Apr 2014 09:30:34 +0200
> From: Martin Braun <[email protected]>
> To: [email protected], "[email protected]"
> <[email protected]>
> Subject: Re: [USRP-users] How to stop "usrp_spectrum_sense.py"?
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 04/04/2014 04:33 AM, Syed Aqeel Raza wrote:
> > Hi Martin,
> >
> > Thanks for your email. Basically I want to program the usrp N200 in a
> > way that it should switch in between of relay mode and scanning mode
> > with respect to time. For that purpose, following are the tasks:
> >
> > 1. Integrate the two programs (i.e. tx_rx.py (relay mode) and
> > usrp_spectrum_sense.py) as an object into a new program.
> >
> > 2. Define the time frame for switching between the two objects program.
> > For example, in a minute 50 seconds are reserved for relaying mode while
> > the remaining 10 seconds for sensing mode.
> >
> > These are the two most important tasks out of many others. Right now, I
> > am able to switch from relay mode to sensing mode but once the program
> > start with the sensing mode then it won't be returned to relay mode.
>
> You might want to write a block that outputs data on two different
> paths, instead of reconnecting blocks or using message queues.
>
> > Yes, the delete_head() call block is remain a mystery for me yet. I am
> > trying to resolve the issue but if anyone has any suggestions then let
> > me know. Waiting for positive response.
>
> I recommend not to use it at all (see comment above).
>
> Also, you might get more results for these GNU Radio-specific questions
> on the GNU Radio mailing list.
>
> Cheers,
> Martin
>
> >
> > Regards,
> > Syed Aqeel Raza
> >
> >
> >
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 31 Mar 2014 18:03:38 +0200
> > From: Martin Braun <[email protected]
> > <mailto:[email protected]>>
> > To: [email protected] <mailto:[email protected]>
> > Subject: Re: [USRP-users] How to stop "usrp_spectrum_sense.py"?
> > Message-ID: <[email protected]
> > <mailto:[email protected]>>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Syed,
> >
> > It looks like you're not shutting down the receiver thread correctly.
> > Also, remember the the delete_head() call blocks.
> >
> > What are you trying to achieve? Do you want to switch off the rx
> > completely? Maybe for half duplex?
> >
> > If not, I suggest you continue emptying the rx queue, and simply
> discard
> > the information.
> >
> > Martin
> >
> > On 03/30/2014 10:25 AM, Syed Aqeel Raza wrote:
> > > Hi Everyone,
> > >
> > > The "usrp_spectrum_sense.py" program is used to sense the defined
> > > spectrum range. Now, I want to stop it for a period of five second
> > time
> > > (e.g. from 55 to 59 seconds). For that purpose, I wrote the
> following
> > > lines in python.
> > >
> > > ================================================
> > > import usrp_spectrum_sense_updated
> > >
> > > import time
> > >
> > >
> > >
> > > class main_class():
> > >
> > >
> > > # calling the 'usrp_spectrum_sense.py' program
> > >
> > >
> > > def relay_func(self, tb):
> > >
> > > while 1:
> > >
> > >
> > > curr_time = time.strftime('%S',time.localtime())
> > >
> > >
> > > if int(curr_time)>=55:
> > >
> > > print 'Hello World"
> > >
> > > else:
> > >
> > > t = usrp_spectrum_sense_updated.ThreadClass()
> > >
> > > t.start()
> > >
> > >
> > > tb = usrp_spectrum_sense_updated.my_top_block()
> > >
> > > try:
> > >
> > > tb.start()
> > >
> > > usrp_spectrum_sense_updated.main_loop(tb)
> > >
> > >
> > > except KeyboardInterrupt:
> > >
> > > pass
> > >
> > > if __name__ == '__main__':
> > >
> > > tb = main_class()
> > >
> > > tb.relay_func(tb)
> > >
> > > ================================================
> > >
> > >
> > > In the above program, I tried to stop sensing for the duration of 5
> > > seconds (i.e. 55 ---- 59 seconds). The program works fine whenever
> I
> > > execute it in between of the mentioned time and it shift
> automatically
> > > to the sensing mode at time=0 second; but once it start sensing
> > then it
> > > never be returned to the print message 'hello world' even when the
> > > condition is matched.
> > >
> > > Earliest and kind response is highly appreciated. Thanks.
> > >
> > > Regards,
> > > Syed Aqeel Raza
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > [email protected] <mailto:[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/20140407/02c1a7ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Resource Temporarily Unavilable.png
Type: image/png
Size: 1869657 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140407/02c1a7ff/attachment-0001.png>
------------------------------
Message: 5
Date: Mon, 7 Apr 2014 15:05:59 -0700
From: Ben Hilburn <[email protected]>
To: Daniel Pascual <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timed out waiting for consecutive locks on
sensor "lo_locked"
Message-ID:
<CAOEVZk+uyCkK6VOKtpcevoowYPbWbCGhzwj6sPs6jtxkE+so=q...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Daniel -
The DBSRX2 (and some other older daughterboards) do not currently work with
the X3xx. The clock rate passed up to the daughterboards (200 MHz) is too
high.
We are working on a new driver feature that will allow you to use these
older daughterboards. Given your need for it, we will make it a priority.
I'll keep you updated.
Cheers,
Ben
On Mon, Apr 7, 2014 at 3:32 AM, Daniel Pascual <[email protected]> wrote:
> Hi. I get the next error when trying to receive with a DBSRX2 in USRPX310:
> "timed out waiting for consecutive locks on sensor "lo_locked". For example
> I use this command:
>
> "rx_samples_to_file --file C:\usrp_samples.dat --type double --nsamps
> 10000000 --rate 25000000 --freq 1575420000 --gain 20 --bw 40000000 "
>
> The driver version is UHD_003.007.000-1-stable. I increased the waiting
> time with the "setup" option but it does not lock anyway. The program
> "test_dboard_corecion" show no errors in tuning and locking. I also tried
> different frequencies and to use an external 10 MHz signal.
>
> The problem is the same for the 8 DBSRX2 and 4 USRPX310 in any possible
> combination. I also have a USRPN210 which works well with the same
> daughterboards. I also have a SBX-120 which seems to work well on the
> USRPX310.
>
> The strange thing is that the REF led on the front panel of the USRPX310
> remains on even if there is no external reference signal.
>
> Any idea on where the problem is? Thanks in advance.
>
>
>
> _______________________________________________
> 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/20140407/8b486d47/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 7 Apr 2014 15:16:46 -0700
From: Ben Hilburn <[email protected]>
To: Dmitry Dmitry <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 theory
Message-ID:
<CAOEVZk+_Efr4NniTGqyB6FRFbAo=nnBAktsyduLyU-Q0=CY=k...@mail.gmail.com>
Content-Type: text/plain; charset="koi8-r"
Hi Dmitry -
Can you share with us what you are trying to accomplish? It would help us
focus our answers on the information that would be most helpful to you.
Cheers,
Ben
On Fri, Apr 4, 2014 at 4:04 AM, Dmitry Dmitry <[email protected]> wrote:
> Hello,
>
> Sorry for the stupid subject. I need some theoretical inquiry into the
> structural scheme. At this moment I dont have a B210 platform, but I need
> to know which part of this system controls the analog elements of the
> AD9361 and where its located. For example, I need to change Rx_LO
> frequency. What elements of the system, signal pass through. (PC->UHD
> FPGA->SPI bus->AD9361 SPI Regs?)
> Sorry for my english, Its my second language.
>
> Best Regards.
>
> _______________________________________________
> 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/20140407/47861712/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 7 Apr 2014 23:48:17 +0000
From: "Knee, Peter A" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP B210 schematic
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
All,
Does anyone have the USRP B210 schematic? We're trying to identify minimum
detectable signal levels and would like some more information on layouts and
such to help in coming up with this value.
Thanks in advance,
Peter Knee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140407/fb1d345b/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 07 Apr 2014 19:57:26 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 schematic
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/07/2014 07:48 PM, Knee, Peter A wrote:
>
> All,
>
> Does anyone have the USRP B210 schematic? We're trying to identify
> minimum detectable signal levels and would like some more information
> on layouts and such to help in coming up with this value.
>
> Thanks in advance,
>
> Peter Knee
>
>
http://files.ettus.com/schematics/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140407/98674fee/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 7 Apr 2014 20:33:47 -0400
From: Michael Dickens <[email protected]>
To: USRP Users Discussion List <[email protected]>, GNU Radio
Discussion List <[email protected]>
Subject: [USRP-users] Call for Proposals for GRCon14: Extended 1 Week
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Greetings GNU Radio and USRP Communities,
We're received quite a few entries for the GNU Radio Conference 2014 (GRCon14)
already [*]; thank you to those who have already submitted your abstract! Due
to hectic schedules on our end, we will keep accepting submissions through
Tuesday, April 15. We will announce the selected presentations on April 21.
Best Regards,
Michael Dickens
GNU Radio Conference 2014 Co-Organizer (one of a few)
* GRCon14 Call For Presentations
http://gnuradio.squarespace.com/grc2014-call-for-presentations/
------------------------------
Message: 10
Date: Mon, 7 Apr 2014 18:01:00 -0700
From: Matt Ettus <[email protected]>
To: BHASKAR BANERJEE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP n210 sram type
Message-ID:
<CAN=1kn9ghgnm0g5kbl_6jyaydzxw14nrxasnpvptz2xt6gr...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Bhaskar,
The N210 uses a ZBT (aka NoBL) SRAM, which is a type of single data rate.
Matt
On Mon, Apr 7, 2014 at 2:20 AM, BHASKAR BANERJEE <
[email protected]> wrote:
> Hi
>
> I wanted to know the sram in USRP n210 is a single data rate ram or a
> double data data rate ram.
>
> Thanks
> Bhaskar Banerjee
>
> _______________________________________________
> 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/20140407/38b82eb2/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 8 Apr 2014 10:07:48 +0530
From: BHASKAR BANERJEE <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP n210 sram type
Message-ID:
<CAB=xdsmji6scv5o3o1ajf2vfy5_nfrgeskntzfbma2gtksa...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Matt
Bhaskar
On Tue, Apr 8, 2014 at 6:31 AM, Matt Ettus <[email protected]> wrote:
>
> Bhaskar,
>
> The N210 uses a ZBT (aka NoBL) SRAM, which is a type of single data rate.
>
> Matt
>
>
> On Mon, Apr 7, 2014 at 2:20 AM, BHASKAR BANERJEE <
> [email protected]> wrote:
>
>> Hi
>>
>> I wanted to know the sram in USRP n210 is a single data rate ram or a
>> double data data rate ram.
>>
>> Thanks
>> Bhaskar Banerjee
>>
>> _______________________________________________
>> 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/20140408/a7090cdb/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 08 Apr 2014 08:58:29 +0200
From: Martin Braun <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] How to stop "usrp_spectrum_sense.py"?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/07/2014 04:51 AM, Syed Aqeel Raza wrote:
> Hi Martin,
>
> Good Day !!!
>
> I somehow able to run the program and it successfully switches in
> between of relay mode to sensing mode with respect to the mentioned time
> frame. However, the program terminates by its own after switching two
> times from relay mode to sensing mode and vice versa. I have been
> encountered with the following error message:
>
> "RuntimeError: boost::thread_resource_error: Resource temporarily
> unavailable"
>
> For detailed information about this error message, see the attached
> file. Waiting for your reply, thanks.
Syed,
at this point, it's impossible to help you any further without seeing
the code. Also, you would probably get more responses on the GNU Radio
mailing list, which I've added.
Another note: It's usually better to post the error message (if short,
in an email, if long, on a pasting service such as pastebin) than to
post a screenshot.
Martin
------------------------------
Message: 13
Date: Tue, 08 Apr 2014 09:00:31 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] full-scale range on B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/07/2014 07:09 PM, Sivan Toledo wrote:
> Sure, I will record waveforms and send you. I did not look at the code;
> what I see is that my code increases gain more and more (because it
> thought that 9930 is far from full range) and the max stays at 9930.
> I'll record the waveforms and share them.
Also, what did you do to saturate the ADC?
Martin
------------------------------
Message: 14
Date: Tue, 8 Apr 2014 10:09:30 +0300
From: Sivan Toledo <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] full-scale range on B210
Message-ID:
<caol_ruf_rb-hcygzzxqpqj6ouit9qzj6vvxlju4m1-ymqhg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I transmit short bursts at 434MHz 10mW from integrated transceivers. If
they are close enough (in teh same room) and the USRP is set to high gain,
it gets saturated. I have lots of experience with that setup on the N200
and the behavior there with respect to full scale values.
On Tue, Apr 8, 2014 at 10:00 AM, Martin Braun <[email protected]>wrote:
> On 04/07/2014 07:09 PM, Sivan Toledo wrote:
> > Sure, I will record waveforms and send you. I did not look at the code;
> > what I see is that my code increases gain more and more (because it
> > thought that 9930 is far from full range) and the max stays at 9930.
> > I'll record the waveforms and share them.
>
> Also, what did you do to saturate the ADC?
>
> Martin
>
>
> _______________________________________________
> 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/20140408/defb8366/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 08 Apr 2014 11:49:24 +0400
From: Dmitry Dmitry <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 theory
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140408/aedf5ed6/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 8 Apr 2014 13:35:09 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] B210 - FLASH on board?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
As I may buy a B210 soon, is there some FLASH on board, to allow nice things
like autoloading the FPGA and the like? I love this feature of my bladeRF :)
AFAIK the FX3 firmware is able to pump the content of the SPI FLASH into the
FPGA.
The bladeRF with its FX3 works great on my USB3 port, so I assume this will
be the same with the B210, using a similar controller. Latest UHD and
gnuradio are installed, I think it almost would be a matter of plug'n'play
getting the thing up and running...
Ralph.
------------------------------
Message: 17
Date: Tue, 8 Apr 2014 10:11:39 -0400
From: Robert Palumbo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Issue with changing the X3xx's IP Address
Message-ID:
<cakwzk9w_h2s-epo-f+gx2hwqzfzs1jon2k_3xhjy0psmaca...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
FYI, the instructions for changing the IP address of the X300 appears to
have a typo (
http://files.ettus.com/uhd_docs/manual/html/usrp_x3x0.html#change-the-usrp-s-ip-address
).
I believe you need to specify a number following the key, i.e. "ip-addrN",
where N=0,1,2,3, depending on what link type (1G/10G, eth0/1) you are using.
Can anyone confirm this? It works on my X300 (stock build from master,
3/25/14).
Rob
--
Robert A Palumbo
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140408/e4affcfb/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 8 Apr 2014 07:40:25 -0700
From: Nicholas Corgan <[email protected]>
To: Robert Palumbo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Issue with changing the X3xx's IP Address
Message-ID:
<cagcyn2mubrrtgy2qjju1royaxdoxc6ykm9x7x7dxudj+f5b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
You are correct. This documentation has been fixed in more recent versions
of master, and the online documentation will be changed accordingly.
On Tue, Apr 8, 2014 at 7:11 AM, Robert Palumbo <[email protected]> wrote:
> FYI, the instructions for changing the IP address of the X300 appears to
> have a typo (
> http://files.ettus.com/uhd_docs/manual/html/usrp_x3x0.html#change-the-usrp-s-ip-address
> ).
>
> I believe you need to specify a number following the key, i.e. "ip-addrN",
> where N=0,1,2,3, depending on what link type (1G/10G, eth0/1) you are using.
>
> Can anyone confirm this? It works on my X300 (stock build from master,
> 3/25/14).
>
> Rob
>
> --
> Robert A Palumbo
> [email protected]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Nicholas Corgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140408/92019361/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 44, Issue 8
*****************************************
