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: RX timeout after longer inactivity (Ales Povalac)
2. Re: USRP B2xx External Reference Frequency (Ian Buckley)
3. Re: USRP B2xx External Reference Frequency (Matt Ettus)
4. Re: USRP B2xx External Reference Frequency (Jacob Gilbert)
5. can?t find USRP N210 (Ladislav Behan)
6. Re: USRP B210 Overflows (Francois Louw)
7. Re: can?t find USRP N210 (Marcus Leech)
8. Re: can?t find USRP N210 (Mike Jameson)
9. USRP B210 Channel Mapping (Knee, Peter A)
10. Re: USRP B210 Channel Mapping (Martin Braun)
11. Re: B200 master_clock_rate multiple of 2.048MHz
(Matthias P. Braendli)
12. Re: B200 master_clock_rate multiple of 2.048MHz (Marcus D. Leech)
13. Re: USRP and GNSS signal (caruiz.ext)
14. Re: can?t find USRP N210 (Linnenkamp, Nicholas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Mar 2014 17:13:04 +0100
From: Ales Povalac <[email protected]>
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] RX timeout after longer inactivity
Message-ID:
<CADyMgmwGCzK1hfuKOVmQSPtj=iarsygkzmwfta51z+9wvts...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
any news regarding the issue? Were you able to reproduce it?
Thanks,
Ales
2014-03-10 7:13 GMT+01:00 Ales Povalac <[email protected]>:
> Hi Michael,
>
> system is Windows 7 64-bit, tested on several computers. Last
> experiment was with N210 and WBX, same issue was also on N200 and
> TVRX2. Gigabit adapters are from Intel (PCIe) and Realtek (PCI).
>
> Regards,
> Ales
>
>
> 2014-03-07 1:21 GMT+01:00 Michael West <[email protected]>:
> > Ales,
> >
> > Can you provide me with some information about your set up (i.e. OS,
> type of
> > device, type of daughterboards, etc...)?
> >
> > Thanks,
> >
> > Michael E. West
> > Senior Software Design Engineer
> > Ettus Research
> > www.ettus.com
> >
> >
> > On Wed, Mar 5, 2014 at 3:58 PM, Michael West <[email protected]>
> wrote:
> >>
> >> Ales,
> >>
> >> Thanks for letting us know. We will try to reproduce the issue and
> file a
> >> bug if appropriate. I will let you know if we find a workaround or fix.
> >>
> >> Best regards,
> >> Michael E. West
> >> Senior Software Design Engineer
> >> Ettus Research
> >> www.ettus.com
> >>
> >>
> >> On Wed, Mar 5, 2014 at 6:10 AM, Ales Povalac <[email protected]> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> we have a problem with UHD RX code. If there is a delay between
> >>> get_rx_stream() and issue_stream_cmd() longer than ca. 64 seconds, the
> >>> recv() call always fails with ERROR_CODE_TIMEOUT.
> >>>
> >>> Issue can be reproduced in rx_samples_to_file example by adding a
> >>> delay of >64 seconds before stream command, diff at
> >>> http://pastebin.com/MFDNVyYy . Threshold is near 64 seconds - 60 sec
> >>> always works, 70 sec always fails with "Timeout while streaming".
> >>>
> >>> I am on maint branch of UHD, tested also on 003.005.001 with the same
> >>> result. Any ideas how to fix this issue?
> >>>
> >>> Thanks,
> >>> Ales
> >>>
> >>> _______________________________________________
> >>> 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/20140317/f7c78582/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 17 Mar 2014 09:24:41 -0700
From: Ian Buckley <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP B2xx External Reference Frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jacob,
I think you will find that all the functionality related to controlling the
operation of the clocking is contained in host based code in UHD.
Specifically in the case of what you are asking about try searching the tree
for the string "adf4001".
-Ian
On Mar 17, 2014, at 8:58 AM, Jacob Gilbert <[email protected]> wrote:
> Thank you for the response Martin.
>
> Changing the master clock rate works well for me, but I am looking to provide
> a frequency reference to the B210 (eg: J100 "10MHz") other than 10 MHz as
> Marcus mentioned. Is this possible?
>
> I would look in the firmware myself for the PLL configuration, but I am
> unable to locate/identify the firmware for the B2xx series in the UHD source.
> It looks like it isn't there (I only see the FX2, X300, octoclock and ZPU
> firmware) but maybe I am not understanding the source structure. Could you
> point me in the right direction here?
>
> Thanks,
> Jacob
>
>
> On Mon, Mar 17, 2014 at 10:25 AM, Martin Braun <[email protected]> wrote:
> On 12.03.2014 16:44, Jacob Gilbert wrote:
> Hello,
>
> Is it possible for the USRP B2xx devices to be configured to accept a
> reference signal other than 10 MHz? I see this is possible with the USRP
> 2 series (by setting the PLL R Divider in firmware) but I have not seen
> anything for the B2xx. Specifically I would like to reference lock it to
> a 30.72 MHz reference.
>
> Sure, just add the "master_clock_rate=30.72e6" parameters to the device set
> call.
>
> See also
> http://files.ettus.com/uhd_docs/manual/html/usrp_b200.html#changing-the-master-clock-rate.
>
> Martin
>
>
>
> _______________________________________________
> 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/20140317/008a2aeb/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 17 Mar 2014 11:31:03 -0500
From: Matt Ettus <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B2xx External Reference Frequency
Message-ID:
<CAN=1kn9ugbymrjy-hpanzmdegnlxfdy2pa5jzgytfd11quo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes, you can provide a reference frequency other than 10 MHz. You will
just need to change the register settings in the ADF4002 PLL. It locks the
40 MHz TCXO to the reference.
To clarify the architecture, there is an onboard 40 MHz TCXO. This TCXO
can be locked to an external 10 MHz reference or 10 MHz from an optional
on-board GPSDO, by the ADF4001. It can also free-run (the most common
case), or can be "trimmed" from the auxiliary DAC on the AD9361.
This 40 MHz, in turn is used internally by the AD9361 as a reference to 3
different PLLs. Those 3 are the RX LO, the TX LO, and the ADC/DAC clock
rate. The upside of this is that you can set your master ADC/DAC clock
rate to just about any frequency you like.
Matt
On Mon, Mar 17, 2014 at 10:58 AM, Jacob Gilbert
<[email protected]>wrote:
> Thank you for the response Martin.
>
> Changing the master clock rate works well for me, but I am looking to
> provide a frequency reference to the B210 (eg: J100 "10MHz") other than 10
> MHz as Marcus mentioned. Is this possible?
>
> I would look in the firmware myself for the PLL configuration, but I am
> unable to locate/identify the firmware for the B2xx series in the UHD
> source. It looks like it isn't there (I only see the FX2, X300, octoclock
> and ZPU firmware) but maybe I am not understanding the source structure.
> Could you point me in the right direction here?
>
> Thanks,
> Jacob
>
>
> On Mon, Mar 17, 2014 at 10:25 AM, Martin Braun <[email protected]>wrote:
>
>> On 12.03.2014 16:44, Jacob Gilbert wrote:
>>
>>> Hello,
>>>
>>> Is it possible for the USRP B2xx devices to be configured to accept a
>>> reference signal other than 10 MHz? I see this is possible with the USRP
>>> 2 series (by setting the PLL R Divider in firmware) but I have not seen
>>> anything for the B2xx. Specifically I would like to reference lock it to
>>> a 30.72 MHz reference.
>>>
>>
>> Sure, just add the "master_clock_rate=30.72e6" parameters to the device
>> set call.
>>
>> See also http://files.ettus.com/uhd_docs/manual/html/usrp_b200.
>> html#changing-the-master-clock-rate.
>>
>> Martin
>>
>>
>>
>> _______________________________________________
>> 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/20140317/eb7b4133/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 17 Mar 2014 13:26:56 -0400
From: Jacob Gilbert <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B2xx External Reference Frequency
Message-ID:
<CAC52AkDpaif7uCE-mNCSu6rrb3ekN35=ycx_foderfyuw7d...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Matt, Ian,
Thank you for the information. It looks like changing lines 104-105 in file
.../uhd/host/lib/usrp/common/adf4001_ctrl.cpp to:
adf4001_regs.ref_counter = 96;
adf4001_regs.n = 125;
will change the PLL from 10 MHz in, 40 MHz out to 30.72 MHz in, 40 MHz out.
Just to follow up on the other question (I have seen it unanswered on the
list here before) - is the firmware for the B2xx public? If not is it going
to be made public?
Jacob
On Mon, Mar 17, 2014 at 12:31 PM, Matt Ettus <[email protected]> wrote:
>
> Yes, you can provide a reference frequency other than 10 MHz. You will
> just need to change the register settings in the ADF4002 PLL. It locks the
> 40 MHz TCXO to the reference.
>
> To clarify the architecture, there is an onboard 40 MHz TCXO. This TCXO
> can be locked to an external 10 MHz reference or 10 MHz from an optional
> on-board GPSDO, by the ADF4001. It can also free-run (the most common
> case), or can be "trimmed" from the auxiliary DAC on the AD9361.
>
> This 40 MHz, in turn is used internally by the AD9361 as a reference to 3
> different PLLs. Those 3 are the RX LO, the TX LO, and the ADC/DAC clock
> rate. The upside of this is that you can set your master ADC/DAC clock
> rate to just about any frequency you like.
>
> Matt
>
>
>
> On Mon, Mar 17, 2014 at 10:58 AM, Jacob Gilbert <[email protected]
> > wrote:
>
>> Thank you for the response Martin.
>>
>> Changing the master clock rate works well for me, but I am looking to
>> provide a frequency reference to the B210 (eg: J100 "10MHz") other than 10
>> MHz as Marcus mentioned. Is this possible?
>>
>> I would look in the firmware myself for the PLL configuration, but I am
>> unable to locate/identify the firmware for the B2xx series in the UHD
>> source. It looks like it isn't there (I only see the FX2, X300, octoclock
>> and ZPU firmware) but maybe I am not understanding the source structure.
>> Could you point me in the right direction here?
>>
>> Thanks,
>> Jacob
>>
>>
>> On Mon, Mar 17, 2014 at 10:25 AM, Martin Braun <[email protected]>wrote:
>>
>>> On 12.03.2014 16:44, Jacob Gilbert wrote:
>>>
>>>> Hello,
>>>>
>>>> Is it possible for the USRP B2xx devices to be configured to accept a
>>>> reference signal other than 10 MHz? I see this is possible with the USRP
>>>> 2 series (by setting the PLL R Divider in firmware) but I have not seen
>>>> anything for the B2xx. Specifically I would like to reference lock it to
>>>> a 30.72 MHz reference.
>>>>
>>>
>>> Sure, just add the "master_clock_rate=30.72e6" parameters to the device
>>> set call.
>>>
>>> See also http://files.ettus.com/uhd_docs/manual/html/usrp_b200.
>>> html#changing-the-master-clock-rate.
>>>
>>> Martin
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140317/64bc41d9/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 16 Mar 2014 18:08:29 +0100
From: Ladislav Behan <[email protected]>
To: [email protected]
Subject: [USRP-users] can?t find USRP N210
Message-ID:
<CADNxU_ALEYzR5Wb9D9ngtv2BFeY=wsuuxrsba98asces8fb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi everybody,
I?m trying to run OpenBTS wit USRP N210. The problem is my computer
doesn?t recognize any device on the other end of ethernet cable. The set
the IP add. of my PC to 192.168.10.12 and I can?t even ping the USRP
running on IP 192.168.10.2 . I also installed the newest version of UHD
(003.007.000) but I can?t find any UHD device and the orange led
ethernet controller doesn?t even light. You can see also the printout
from terminal at the bottom of this message.
Thank you in advance for your reply.
*ifconfig eth0 192.168.10.12/24 <http://192.168.10.12/24>*
*ping 192.168.10.2*
from 192.168.10.12 icmp_seq1 Destination Host Unreacheble
*uhd_usrp_probe --args "addr=192.168.10.2*"
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.000-1-stable
Error: LookupError: KeyError: No devices found
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140316/90b34572/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 17 Mar 2014 17:24:37 +0200
From: Francois Louw <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B210 Overflows
Message-ID:
<caazi0mc-_ljqqfoqdu682q_k+mxcpa4vlec_hrjuqb-seyv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Michael,
Thanks your changes fixes the compilation error, but the runtime error
still exists.
I am running the program in the MSVC debugger and inspecting the callstack
I can see that the Access Violation is in the uhd.dll file whilst making a
call to
*uhd::usrp::multi_usrp::make(string("num_recv_frames=128,num_send_frames=128"))*
I should have mentioned it, but I am using the B210. Also when I run the
benchmark test at the same sample rate, but without the
"num_recv_frames=128" then it works, so I don't think it has anything to do
with the sample rate not being compatible.
I have downloaded the debug version of the UHD binaries, but the .pdb files
are not supplied so I cannot load symbols for the uhd.dll in order to see
where in the uhd.dll file the access violation is happening. I've tried to
compile the host code from source, but I'm running into other issues there.
One thing I did notice, however, was that the source code appears to expect
v1.36 of boost, whereas I'm running with v1.54. Could this be a problem?
Kind regards
Francois
On Sat, Mar 15, 2014 at 1:37 AM, Michael West <[email protected]>wrote:
> Francois,
>
> As for the compiler error, you can probably fix that by casting it as a
> string:
> pUSRP =
> uhd::usrp::multi_usrp::make(std::string("num_recv_frames=128,num_send_frames=128"));
>
> As for the "Access Violation", that can come from anything in the
> program. How do you know it is from that particular line of code?
>
> As for the benchmark_rate crash, the sample rate needs to be an even
> division of the master clock rate which is 100MHz for the N210. Try
> running:
>
> benchmark_rate.exe --rx_rate 25e6 --args="num_recv_frames=128"
>
> That worked fine for me.
>
> Regards,
> Michael
>
>
> On Fri, Mar 14, 2014 at 8:16 AM, Francois Louw <[email protected]>wrote:
>
>> Hi Michael,
>>
>> Thanks for the help.
>>
>> If I use your code snippet as follows:
>> pUSRP =
>> uhd::usrp::multi_usrp::make("num_recv_frames=128,num_send_frames=128");
>>
>> Then it gives a compiler error of :
>> *cannot convert parameter 1 from 'const char [40]' to 'const
>> uhd::device_addr_t &'*
>>
>> If I then use:
>> pUSRP =
>> uhd::usrp::multi_usrp::make(uhd::device_addr_t("num_recv_frames=128,num_send_frames=128"));
>> Then I get an "Access Violation" run-time error. when I run it
>>
>> If I run the benchmark test as follows:
>> benchmark_rate.exe --rx_rate 32000000
>> --args="num_recv_frames=128,num_send_frames=128"
>>
>> then it crashes. If I run it without the "--args" option then it runs
>> fine (with some overflows however).
>>
>> I am developing in Windows and using "#define UHD_VERSION_ABI_STRING
>> "3.7.0-0""
>>
>> Any ideas?
>>
>> Kind regards
>> Francois
>>
>>
>>
>> On Fri, Mar 14, 2014 at 1:18 AM, Michael West <[email protected]>wrote:
>>
>>> Hi Francois,
>>>
>>> Just add it in the device_addr_t when you call multi_usrp::make(). For
>>> example:
>>>
>>> multi_usrp::sptr usrp =
>>> multi_usrp::make("num_recv_frames=128,num_send_frames=128");
>>>
>>> For the utilities and examples provided by UHD you can add them as the
>>> --args argument. For example:
>>>
>>> /usr/local/lib/uhd/examples/benchmark_rate
>>> --args="num_recv_frames=128,num_send_frames=128"
>>>
>>> Best regards,
>>> Michael E. West
>>> Senior Software Design Engineer
>>> Ettus Research
>>> www.ettus.com
>>>
>>>
>>> On Thu, Mar 13, 2014 at 1:32 PM, Francois Louw
>>> <[email protected]>wrote:
>>>
>>>> Michael West <michael.west@...> writes:
>>>>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > Aside from tweaking system parameters and assuming your disk write
>>>> speed
>>>> is sufficient, here are 2 things you can try to add buffering of the
>>>> data to
>>>> avoid overflows:1) Increase num_recv_frames (512 is recommended). The
>>>> N2x0
>>>> uses the network socket buffer as well as the receive frames to buffer
>>>> data,
>>>> but the B2x0 only uses the frames. Increasing the number of frames will
>>>> give you more buffering.
>>>> > 2) Make separate threads for receiving the data and writing the data
>>>> to
>>>> disk with a large buffer in between.
>>>> > Regards,
>>>> > Michael E. West
>>>> > Senior Software Design Engineer
>>>> > Ettus Research
>>>> >
>>>> > www.ettus.com
>>>> >
>>>> >
>>>> > On Wed, Jan 29, 2014 at 9:30 AM, Marcus D. Leech <mleech-
>>>> [email protected]> wrote:
>>>> > On 01/29/2014 12:22 PM, Alexandru Csete wrote:
>>>> > On Wed, Jan 29, 2014 at 4:26 PM, Knee, Peter A<paknee-
>>>> [email protected]> wrote:
>>>> > Good morning all!
>>>> > I wanted to see if anybody was having similar issues with their B210.
>>>> We
>>>> > just purchased our device last week and have been benchmarking for a
>>>> data
>>>> > acquisition application. We want to see what kind of throughput to
>>>> disk
>>>> we
>>>> > can have with the new wideband bus-based device.
>>>> > We have everything compiled and are using version 3.6.2 of the UHD.
>>>> We
>>>> can
>>>> > successfully communicate with the device and such. Our issues arise
>>>> when
>>>> we
>>>> > try to start streaming the data to disk. And just to clarify right
>>>> away,
>>>> I
>>>> > don't believe this is a disk write speed issue. We have SSDs and have
>>>> > previously been able to stream 25 MHz of 16-bit I/Q data from the USRP
>>>> N210.
>>>> > First we ran the rx_samples_to_file program using the null option to
>>>> verify
>>>> > that USB 3.0 is allowing for transmission from the device to the host
>>>> with
>>>> > no issues. We were able to successfully stream 32 MHz of 16-bit I/Q
>>>> data
>>>> > when not writing to a file. When we specify an output file, we
>>>> immediately
>>>> > start seeing overflows when the data is flushed from RAM to the SSD.
>>>> Our
>>>> > best guess as to what is happening is that an interrupt is generated
>>>> when
>>>> > data is ready to be flushed from RAM, causing us to not consume data
>>>> from
>>>> > the device fast enough. The N210 overcomes this issue by having large
>>>> > amounts of shared networking memory to continue to buffer data while
>>>> we
>>>> > burst data to the disk. I haven't spent the time looking into it
>>>> yet, but
>>>> > I'm not sure that USB provides this same functionality as it is an
>>>> interrupt
>>>> > driven protocol.
>>>> > Is this the case? Or are there some USB settings to allow for
>>>> allocating
>>>> > shared memory sizes that may overcome this issue? Has anyone seen
>>>> anything
>>>> > similar and if so, how did you alleviate the problem?
>>>> >
>>>> > I had the same problem last year with a USRP1 running at 4 MHz
>>>> > bandwidth. Initially, I didn't understand what the hell was going on,
>>>> > since the throughput required to store 4 MHz raw I/Q is far below what
>>>> > the disks could handle.
>>>> > My investigations revealed that the linux kernel was configured to do
>>>> > some very aggressive caching. It would cache up to the point there was
>>>> > no more RAM, where after it would start writing huge chunks of data to
>>>> > disk causing interrupts in the USB transfer.
>>>> > I ended up messing with the virtual memory parameters:
>>>> > sysctl -w vm.swappiness=0
>>>> > sysctl -w vm.dirty_background_bytes=1048576
>>>> > sysctl -w vm.dirty_writeback_centisecs=20
>>>> > sysctl -w vm.dirty_expire_centisecs=30
>>>> > However, note that these setting will essentially disable caching and
>>>> > the computer will probably be quite useless for normal desktop use.
>>>> > See https://www.kernel.org/doc/Documentation/sysctl/vm.txt
>>>> > I also got a suggestion to use raw write instead of fwrite and that's
>>>> > what I am going to try the next time.
>>>> > Alex
>>>> > _______________________________________________
>>>> > USRP-users mailing listUSRP-users <at>
>>>> lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-
>>>> users_lists.ettus.com
>>>> >
>>>> >
>>>> > fwrite buffer in user-space--has nothing to do with kernel-layer
>>>> buffer at
>>>> all. Just standard userspace buffer in the stdio library. The default
>>>> buffer
>>>> > size for fwrites() is BUFSIZ, which is typically not that
>>>> large--8192 or
>>>> perhaps up to 32K.
>>>> >
>>>>
>>>> Hi Michael,
>>>>
>>>> I've been searching the API and all the mailing lists but cannot get
>>>> documentation on how I go about setting the num_recv_frames for the
>>>> B210.
>>>>
>>>> Please could you provide me a short code snippet on how to go about
>>>> doing
>>>> this.
>>>>
>>>> I am also running into overflow problems. I can only reliably read at
>>>> 5MSPS
>>>> without getting overflows.
>>>>
>>>> Kind regards
>>>> Francois
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20140317/a7f8eec5/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 17 Mar 2014 17:40:58 +0000 (UTC)
From: Marcus Leech <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] can?t find USRP N210
Message-ID: <336747396.154617.1395078059050.JavaMail.mail@webmail07>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140317/b1f3b9ec/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 17 Mar 2014 17:53:21 +0000
From: Mike Jameson <[email protected]>
To: Ladislav Behan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] can?t find USRP N210
Message-ID:
<cajcjmisygjv_uzejfwjtp9dljf1hjpkwseu_rvplymd91f1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Some troubleshooting tips:
1) Your computer must have a Gigabit Ethernet port if directly connected or
the N210 must be connected to a Gigabit Ethernet switch.
2) The Ethernet cable connected to the N210 must be Gigabit Ethernet
compatible.
3) Make sure that the Ethernet cable actually works.
4) Unplug the N210, wait 10 seconds and then plug it in again.
5) Test by using the GNU Radio Live DVD (
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD) to rule
out erroneous OS issues such as VMWare using a 100Mb virtual network
interface.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: [email protected]
Web: http://scanoo.com
On Sun, Mar 16, 2014 at 5:08 PM, Ladislav Behan <[email protected]
> wrote:
> Hi everybody,
>
> I?m trying to run OpenBTS wit USRP N210. The problem is my computer
> doesn?t recognize any device on the other end of ethernet cable. The set
> the IP add. of my PC to 192.168.10.12 and I can?t even ping the USRP
> running on IP 192.168.10.2 . I also installed the newest version of UHD
> (003.007.000) but I can?t find any UHD device and the orange led
> ethernet controller doesn?t even light. You can see also the printout
> from terminal at the bottom of this message.
>
> Thank you in advance for your reply.
>
> *ifconfig eth0 192.168.10.12/24 <http://192.168.10.12/24>*
> *ping 192.168.10.2*
> from 192.168.10.12 icmp_seq1 Destination Host Unreacheble
>
> *uhd_usrp_probe --args "addr=192.168.10.2*"
> linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.000-1-stable
> Error: LookupError: KeyError: No devices found
>
>
> _______________________________________________
> 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/20140317/f698bf8e/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 17 Mar 2014 19:20:59 +0000
From: "Knee, Peter A" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP B210 Channel Mapping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I'm trying to figure out how to setup and use our new B210. Due to leakage
between the TX/RX and RX2 ports on channel 1, I'd like to find a way to switch
between the two RX2 inputs on channels 1 and 2. I'm having some issues writing
a C++ wrapper for the UHD to allow for the selection of the channel to stream.
My ultimate goal is a class that allows me to set things like the channel to
stream from, sampling rate, etc. and save that data to disk.
I've looked through the rx_multi_samples program but am still not understanding
how to only stream one channel of the data. Is there a way to do this?
Any help you can provide would be appreciated.
Thanks,
Peter Knee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140317/6a7ae620/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 17 Mar 2014 21:20:18 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Channel Mapping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 03/17/2014 08:20 PM, Knee, Peter A wrote:
> I?m trying to figure out how to setup and use our new B210. Due to
> leakage between the TX/RX and RX2 ports on channel 1, I?d like to find a
> way to switch between the two RX2 inputs on channels 1 and 2. I?m
> having some issues writing a C++ wrapper for the UHD to allow for the
> selection of the channel to stream. My ultimate goal is a class that
> allows me to set things like the channel to stream from, sampling rate,
> etc. and save that data to disk.
>
> I?ve looked through the rx_multi_samples program but am still not
> understanding how to only stream one channel of the data. Is there a
> way to do this?
There are several ways to do this, and it depends a bit on your
requirements.
Off the top of my head, I guess there's two ways to do this:
- Switch subdevs between receives
- Always rx on both channels, then discard the one you don't need.
If you need time alignment, the latter method is the way to go, but it
will waste bandwidth on USB in case you need a lot of that.
Cheers,
Martin
------------------------------
Message: 11
Date: Mon, 17 Mar 2014 22:59:19 +0100
From: "Matthias P. Braendli" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 master_clock_rate multiple of 2.048MHz
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Marcus,
On 16. 03. 14 18:18, Marcus D. Leech wrote:
> We're talking clock rate differences of roughly 1PPB. That is vastly
> better than you actually need for DAB, and better than the 2PPM clock
> oscillator on the B200.
Yes, and also much better than the rest of the transmission chain, and
clearly the receivers too. With this alone we can (must) live. It looks
much less horrible once you put it into perspective.
I agree I cannot expect the actual sample rate to be equal the desired
one, I'll use a acceptable window from now on.
> If you think that you can set an "exact" frequency anywhere in the
> physical world, you're living in a state of conceptual sin.
I hope that the punishment will be conceptual too !
> For example, to routinely achieve an actual error of 1.0e-9, you'll need
> an OCXO, 1.0e-11, a Rb source, 1.0-e12, a Cs source, 1.0e-14, a hydrogen
> maser, and somewhere in there a GPSDO will fit as well. Note how
> none of these are "exact", but rather, giving you more significant digits
> closer to "exact".
>
> What you're seeing is simply rounding error, since divider registers in
> PLLs aren't infinitely wide, and IEEE-754 floating-point math isn't
> infinitely precise.
That was a bit what I expected.
How reproducible are these rounding errors across different systems ?
With identical systems (same CPU, same binary) I'd expect identical
behaviour, but what happens if different CPUs are used ? I know IEEE-754
defines rounding modes, but floating point is so much more complex than
integer math, I don't want to assume too much.
This scenario would be relevant in case we have two DAB transmitters in
a single-frequency network (with GPSDOs), there we probably would want
identical (or "identically wrong") settings in both transmitters.
Thanks for your help,
mpb
------------------------------
Message: 12
Date: Mon, 17 Mar 2014 18:53:59 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200 master_clock_rate multiple of 2.048MHz
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/17/2014 05:59 PM, Matthias P. Braendli wrote:
> Hi Marcus,
>
> On 16. 03. 14 18:18, Marcus D. Leech wrote:
>> We're talking clock rate differences of roughly 1PPB. That is vastly
>> better than you actually need for DAB, and better than the 2PPM clock
>> oscillator on the B200.
> Yes, and also much better than the rest of the transmission chain, and
> clearly the receivers too. With this alone we can (must) live. It looks
> much less horrible once you put it into perspective.
>
> I agree I cannot expect the actual sample rate to be equal the desired
> one, I'll use a acceptable window from now on.
>
>
I'll point out that the CRCDabmod folks did development using a USRP1,
which has a native clock that is 25PPM, and
it worked just fine.
> This scenario would be relevant in case we have two DAB transmitters in
> a single-frequency network (with GPSDOs), there we probably would want
> identical (or "identically wrong") settings in both transmitters.
>
> Thanks for your help,
> mpb
>
> _______________________________________________
>
In that scenario, you probably need them to be phase-coherent as well.
They'll both be set to the same frequency and sample rate if you use
a common reference.
But again, notions of "exact" are kinda wobbly in the real world.
That's why digital receivers have compensation for the "inexactness" of the
physical world of radio.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 13
Date: Tue, 18 Mar 2014 15:50:46 +0100
From: "caruiz.ext" <[email protected]>
To: hossein talaiee <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP and GNSS signal
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
I have used the USRP driver example for rebroadcast the GPS
capture data file. http://pastebin.com/BREHyNM5
I use the parameters:
* TX Rate: 5.000000 Msps
* TX Freq: 1575.420000 MHz
* TX Gain:
0.000000 dB
* TX Bandwidth: 2.000000 MHz
* Data type: float
*
Samples per buffer: 1000
* Ant: TX/RX
And it doesn't work, the GPS
receiver doesn't take position.
I've thought about doing a memory
buffer with an array of floats ---> If I use 5 Msps, then I must have an
array with 500000 floats for 200ms. It is correct?
On 13-03-2014 10:06,
hossein talaiee wrote:
> I implemented the buffer with a block of RAM
in my PC! I didn't used GNU Radio, I just write anything from scratch in
C++ using UHD drivers!
>
> I suggest that you see the
"rx_samples_to_file.cpp" and "tx_samples_from_file.cpp" examples in UHD!
>
> On Wed, Mar 12, 2014 at 11:36 PM, caruiz.ext
<[email protected]> wrote:
>
>> Mmm...
>>
>> I use Spirent 6560 to
generate the signal and I capture it with GNURadio and USRP N200 (USRP
source block to file sink block).
>>
>> After I transmit the signal
with GNURadio (file source block to USRP sink block), but GPS receiver
doesn't take position.
>>
>> I have tried with a external clock, but it
doesn't work. I will tray use a attenuator >80dB (
https://decibel.ni.com/content/docs/DOC-22178 [4] )
>>
>> Can you
explain me how you did the buffer? GNURadio?
>>
>> Thank you.
>>
>> El
12-03-2014 18:55, hossein talaiee escribi?:
>>
>>> It's not a clock
issue, I did this with USRP n200/n210 before (WBX and SBX)! I even made
a GPS signal simulator for USRP that can work like Spirent 6560 or
Spirent 6700 simulators and generates signals on the fly with 100 ms of
buffering! It work like best!
>>>
>>> On Wed, Mar 12, 2014 at 3:43 PM,
caruiz.ext <[email protected]> wrote:
>>>
>>>> Yes, you are right;
scenario 1 doesn't really work.
>>>>
>>>> I will buy an external clock
for USRP. I have seen this:
http://es.mouser.com/ProductDetail/ABRACON/AOCJY1-40000MHz/?qs=sGAEpiMZZMsC2cQJVRBSBUVTnCXPHX6IVWPaK2laDuU%3d
[5]
>>>>
>>>> Is it a good choice?
>>>>
>>>> ** I can't use in my
project a GPSDO.
>>>>
>>>> On 11-03-2014 17:54, John Malsbury wrote:
>>>>
>>>>> You need to use a significant amount of attenuation between
the USRP and the receiver (> 80 dB).
>>>>>
>>>>> Of course, there could
be a number of other issues in the system.
>>>>>
>>>>> See this for
more inspiration: https://decibel.ni.com/content/docs/DOC-22178
[4]
>>>>>
>>>>> -John
>>>>>
>>>>> On Tue, Mar 11, 2014 at 9:10 AM,
caruiz.ext <[email protected]> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm using a USRP N200 to retransmit a GPS signal. I tested two
configurations:
>>>>>>
>>>>>> 1. I connect an external GPS signal
generator to USRP RX2 port. And if I connect a GPS receiver in the TX/RX
port it works; the GPS receiver gives me the position. My config:
http://po.st/PRKNi2 [1]
>>>>>>
>>>>>> 2. I use a file source with the
GPS signal (captured generator) and I transmit signal. If I connect a
GPS receiver in the TX/RX port it doesn't work; the GPS receiver doesn't
gives me the position. My config: http://po.st/qfGMcX [2]
>>>>>>
>>>>>>
* I don't use antenna, connect the GPS receiver directly to the TX/RX
port.
>>>>>> ** The GPS data file is correct, a GPS receiver software
(GNSS-SDR) gives me the position.
>>>>>>
>>>>>> Does anyone know what
is happening?
>>>>>>
>>>>>> Thank you :)
>>>>>>
>>>>>>
_______________________________________________
>>>>>> USRP-users
mailing list
>>>>>> [email protected]
>>>>>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[3]
>>>>
>>>> _______________________________________________
>>>>
USRP-users mailing list
>>>> [email protected]
>>>>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [3]
Links:
------
[1] http://po.st/PRKNi2
[2] http://po.st/qfGMcX
[3]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[4]
https://decibel.ni.com/content/docs/DOC-22178
[5]
http://es.mouser.com/ProductDetail/ABRACON/AOCJY1-40000MHz/?qs=sGAEpiMZZMsC2cQJVRBSBUVTnCXPHX6IVWPaK2laDuU%3d
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140318/29235e04/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 18 Mar 2014 15:48:58 +0000
From: "Linnenkamp, Nicholas" <[email protected]>
To: "'Mike Jameson'" <[email protected]>, "'Ladislav Behan'"
<[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] can?t find USRP N210
Message-ID:
<f12eb16eed10e34598b8204ce060869c0ce86...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="iso-8859-1"
These are great troubleshooting tips.
6) route is a good command to run to check which interface 192.168.10.0 is
actually connected. Some example output is shown below which shows that eth0
is the output interface in which packets destined for 192.168.10.0/24 are going
to exit. If there are multiple entries for the same network only the first
will work. Usually this is dictated by the order which the interfaces became
active, with the last to become active writing the newest entry into the
routing table (first entry in the "route" table is the one always executed).
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.10.0 * 255.255.255.0 U 0 0
0 eth0
Moral of the story is that if you have multiple network interfaces configured
to communicate on 192.168.10.0/24 even if they are not connected it could cause
problems communicating with your USRP device. Generally it isn't a good idea
to have multiple network interfaces configured for the same network as it
causes all sorts of problems. This problem often occurs in our labs as
researchers try to directly connect multiple USRPs to the same machine but
don't put them on separate networks.
The ip route or route command (depending on operating system) will allow you to
diagnose these types of communication problems.
I recommend this command because you are getting the ICMP reply "Destination
Host Unreachable" which indicates that the computer has a route to
192.168.10.0/24 and is sending ICMP messages out of *an* interface but is not
getting a response. The other suggestions of making sure that the Ethernet
cable isn't bad and power cycling the USRP are both excellent ideas.
Nicholas
From: USRP-users [mailto:[email protected]] On Behalf Of Mike
Jameson
Sent: Monday, March 17, 2014 1:53 PM
To: Ladislav Behan
Cc: [email protected]
Subject: Re: [USRP-users] can?t find USRP N210
Some troubleshooting tips:
1) Your computer must have a Gigabit Ethernet port if directly connected or the
N210 must be connected to a Gigabit Ethernet switch.
2) The Ethernet cable connected to the N210 must be Gigabit Ethernet compatible.
3) Make sure that the Ethernet cable actually works.
4) Unplug the N210, wait 10 seconds and then plug it in again.
5) Test by using the GNU Radio Live DVD
(http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD) to rule
out erroneous OS issues such as VMWare using a 100Mb virtual network interface.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: [email protected]<mailto:[email protected]>
Web: http://scanoo.com
On Sun, Mar 16, 2014 at 5:08 PM, Ladislav Behan
<[email protected]<mailto:[email protected]>> wrote:
Hi everybody,
I?m trying to run OpenBTS wit USRP N210. The problem is my computer
doesn?t recognize any device on the other end of ethernet cable. The set
the IP add. of my PC to 192.168.10.12 and I can?t even ping the USRP
running on IP 192.168.10.2 . I also installed the newest version of UHD
(003.007.000) but I can?t find any UHD device and the orange led
ethernet controller doesn?t even light. You can see also the printout
from terminal at the bottom of this message.
Thank you in advance for your reply.
ifconfig eth0 192.168.10.12/24<http://192.168.10.12/24>
ping 192.168.10.2
from 192.168.10.12 icmp_seq1 Destination Host Unreacheble
uhd_usrp_probe --args "addr=192.168.10.2"
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.000-1-stable
Error: LookupError: KeyError: No devices found
_______________________________________________
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/20140318/978d7f8f/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 43, Issue 18
******************************************
