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: B200 old vs. new (Neel Pandeya)
2. Re: Using the SC12 OTW format (Michael West)
3. Re: X300 configuration with SSD setting (Michael West)
4. Re: Routing IP packets to the straight into the DUC chain
(Hrishikesh Shelar)
5. Re: change the master clock rate in N2x0 (Ian Buckley)
6. Re: N210 + new WBX v3 daughterboard does not work, but with
old WBX v2 it works (OpenBTS) (Tom Tsou)
7. [UHD-3.7.3-RC1] Bugfix Release Announcement (Martin Braun)
8. Re: [UHD-3.7.3-RC1] Bugfix Release Announcement
(Ralph A. Schmid, dk5ras)
9. Re: [UHD-3.7.3-RC1] Bugfix Release Announcement (Martin Braun)
10. Re: [UHD-3.7.3-RC1] Bugfix Release Announcement (Martin Braun)
11. Re: change the master clock rate in N2x0 ([email protected])
12. X310 + 2 CBX daughtercards strange behaviour issue solved by
UHD_003_007_003_rc1! (boeglen herve)
13. Re: X310 + 2 CBX daughtercards strange behaviour issue solved
by UHD_003_007_003_rc1! (Martin Braun)
14. XADC Usage on X300?? (Robert Palumbo)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Sep 2014 09:28:33 -0700
From: Neel Pandeya <[email protected]>
To: Nir Eden <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] B200 old vs. new
Message-ID:
<CACaXmv9a7E=xw7tk_do_sdaedpbxcdketn7cxydrk8wqdpa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There was a recent thread on the email list about this:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-September/010632.html
Basically, the new rev 6 boards feature a larger USB B connector, instead
of the micro-B connector, and Rev 6 has mounting holes and the LED shows
two colors depending on whether the board is using USB bus power or wall
power.
There's also a new 10-pin GPIO connector (pins 1-8 are GPIO, and pins 9, 10
are grounded), which is physically on both the B200 and B210 boards, but is
only active with the larger FPGA on the B210. The connector is labeled J504.
Also take a look at:
http://files.ettus.com/b2x0_enclosure/
On Thu, Sep 25, 2014 at 2:46 AM, Nir Eden via USRP-users <
[email protected]> wrote:
> Hi,
>
> I own 3 weeks old USRP B200. It is the white board version. I have noticed
> that there is a newer version. What are the differences between the new and
> the white version? I have noticed the USB-B connector and the (shine its
> absence) mounting holes.
>
>
> With best regards,
> Nir
>
>
> _______________________________________________
> 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/20140925/1a34818d/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 25 Sep 2014 09:30:27 -0700
From: Michael West <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using the SC12 OTW format
Message-ID:
<CAM4xKrr-5Zbei+=VfFsAoyTZQ+Zdy0AwoSGFQCqW76=skdi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, sc12 is only implemented on B2xx and only the converters between sc12
and fc32 were implemented. There are currently no plans to augment the
converters for sc12 or implement the format on other devices, but we could
always be convinced to do it if there was a significant enough need and
opportunity. We do have the sc8 format fully implemented and available for
reduced transport bandwidth applications. Sadly, the sc12 format is just
the awkward middle child that never gets enough love and attention.
Regards,
Michael
On Thu, Sep 25, 2014 at 7:56 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> SC12 is only available, as far as I know, on B2xx.
>
>
>
> Not sure about plans to augment the converters.
>
>
>
>
>
>
>
>
> On 2014-09-25 10:46, Robert Kossler via USRP-users wrote:
>
> Hi,
> I have a B210 and just started to experiment with the 'sc12' wire format
> for receiving data (where the data values are packed into 3 bytes/sample
> rather than 4 bytes/sample). This seems to work fine with the
> benchmark_rate and rx_samples_to_file sample programs as long as the CPU
> format is 'fc32'. If the CPU format is 'sc16', UHD generates an error
> saying essentially that there is no converter defined for going from 'sc12'
> to 'sc16'. I am wondering if there are any plans to add this converter.
>
> I'm also wondering if this 'sc12' OTW format can be used with other
> devices like X310. I realize that there will be a slight loss of
> precision when packing the data into 12-bit values, but the increased
> bandwidth may make it worthwhile. I am thinking in particular about a use
> case where I would be using the 1GbE port rather than the 10GbE in a
> portable setup where I have a laptop rather than a desktop PC. It seems I
> would be able to get nearly 20MS/s (2 channel) transfer rates using this
> OTW format.
>
> Rob
>
> _______________________________________________
> USRP-users mailing
> [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/20140925/40f7661c/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 25 Sep 2014 09:41:07 -0700
From: Michael West <[email protected]>
To: Jack Yang <[email protected]>
Cc: Jack Yang via USRP-users <[email protected]>
Subject: Re: [USRP-users] X300 configuration with SSD setting
Message-ID:
<CAM4xKrr=aweeyaunbo2d27rgnf1oq7z+os3joadsiq0qxrs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jack,
At 200 MSPS on a single RX stream, you are well within the bounds of 10
GbE. Over the wire, the samples are sc16 format, not fc32. They are
converted to fc32 on the host. So, each sample on the wire is 4 bytes and
the total rate is ~800 MB/s. You will only be over the 10 GbE limit if you
try to stream 2 RX channels at that rate.
Regards,
Michael
On Thu, Sep 25, 2014 at 8:15 AM, Jack Yang via USRP-users <
[email protected]> wrote:
> Hello, Marcus
>
> Many thanks for your mail. I have some questions regarding the sampling
> rate and data stream speed.
>
> 1. When data stream is setting in complex float 32, the raw data rate
> 1.6GB/s will be over single 10Gigabit Ethernet cable ability, isn't it?
> One thing confuses me is the ADC resolutions is 14 bits ( ~ 2Byte, I and Q
> channel for totally 4Byte). Hence, why we can have complex float 32 for
> each sample( I and Q for totally 8Byte)?, is it from auto gain control
> assistance for making widely range?
>
> 2. Currently, I am using only one 10Gigabit cable in x300. Do you mean
> that in dual channel receiver, I need to set up two 10Gigabit cable ? I saw
> some information indicating that the two 10 Gigabit cable interface setting
> is not finishing yet? In addition, When I am running uhd_fft at sampling
> 200MS in single cable, I didn't see any overflow or dropping warning
> message. Why this speed don't break the limitation of single 10Gigabit
> cable? (I am using INTEL 10Gigabit Ethernet card)
>
>
> Again, really thanks for your answering and time
>
> All Best,
> Jack
>
>
>
>
>
>
> On Thu, Sep 25, 2014 at 6:58 AM, Marcus M?ller <[email protected]>
> wrote:
>
>> Hi Jack,
>> In afraid this is something not inherently related to usrp usage, so this
>> might not be the best place to ask. Usually, Ubuntu has community forums
>> and a wiki that contain a lot of information, and also a rather active irc
>> channel on freenode. Be sure to use a raid controller that really takes off
>> as much load as possible from the cpu, which means that you'll want to have
>> a hardware raid; configuration of that probably will include controller
>> specific steps, so you'll need to google information on your specific
>> device.
>>
>> As a side note: a raid of two fast ssds might sound impressive, but the
>> raw data rate of a dual channel 100MS/s stream in complex int16 is 800MB/s
>> (1.6GB/s for GNU radio's default complex float32), and you'll need to make
>> sure your storage system is sufficiently oversized to not only offer a high
>> average rate but guarantee this rate in a worst case scenario as well as
>> being able to catch up if for some reason your os needs to suspend storage
>> to do something else. Also, there is significant file system overhead, both
>> with respect to storage speed and cpu load, so you'll definitely need a
>> rather beefy computer to handle all this.
>>
>> Greetings,
>> Marcus
>>
>> On September 24, 2014 11:30:10 AM EDT, Jack Yang via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> I have one X300 USRP and would like to do the dual receiver development
>>> (coherent receiver for signal processing). I would like to record a data
>>> for baseband bandwidth arounnd 66.66Mhz or 100Mhz. Therefore, I plan to use
>>> two Samsung 850 Pro SSD to storage the data stream under 66.66Mhz or 100Mhz
>>> sampling rate for two receiver by using File Sink block in
>>> gnuradio-companing. My computer is using ubuntu 14.04.
>>>
>>> My question is how to set up SSD for this scenario? I guess I need to
>>> use RAID 0 to set up this two SSD, but not for sure how to do it. Can
>>> anyone give me some direction for this?
>>>
>>> Many thanks for that.
>>>
>>> All Best,
>>> Jack
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
>
>
> --
> Chou-Chang Yang
>
> Graduate Research Assistant
> Network Security Lab
> Electrical Engineering
> University of Washington
>
> _______________________________________________
> 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/20140925/9163e85b/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 25 Sep 2014 09:55:33 -0700
From: Hrishikesh Shelar <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Routing IP packets to the straight into the
DUC chain
Message-ID:
<cacm6m_c6zvcpxarr40k21xpvcxh6wxtol+yqnpwf-7cvwgr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
Thanks for your help so far, I think I have got a clear path forward based
on your advice. I am going to use the secondary interface to route my
traffic so I don't interfere with the normal USRP interfacing route. It
seems as though I will not have to make a lot of changes to eth_dispatch; I
see that there is unused logic for routing based on destination ip address.
So I am going to just write the "my ip" address SR accordingly, create an
extra case for routing that traffic to the XO port and maybe hard program
the 'forward_ndest' and 'forward_bcast' bits to be 0. Then I will add a
modified fifo that will drop packets if the downstream (DUC chain) logic is
tied up and only accept packets if there is enough space in the buffer to
ingress an entire packet. The MTU will be set on the host side to not break
this limit. I am not that worried about future proofing the code as it is a
one off deal.
I am going to drop all notions of flow control from my custom DUC to the
host computer and let TCP/IP negotiate the flow. DDC chain isn't
implemented yet but it is the reverse of the DUC (obviously ha).
Thanks again,
Hrishikesh
On Tue, Sep 23, 2014 at 5:22 PM, Ian Buckley <[email protected]> wrote:
> Hrishikesh,
> You're diving deep into the USRP internals here so very few folks will be
> able to help you.
> I'm going to assume we are talking about X300 here.
>
> > If I rewired the crossover output from the secondary eth interface
> straight into my custom logic in the DUC chain then all broadcast and
> non-USRP destined MAC addresses will get routed into the DUC chain, correct?
>
> Not with the default programming. Whilst that functionality exists in H/W,
> the device setup clears the "forward_ndest" and "forward_bcast" bits in the
> eth_dispatch so that all packets not addressed to the local MAC address are
> dropped. Likewise broadcast packets are only sent to the ZPU.
> If you enable those bits by changing UHD then you are going to have to
> deal with all manor of unknown and unexpected traffic and make sure it
> never back pressures up into the eth_dispatch which will very quickly cause
> the entire USRP to lock up.
> >
> > Say my custom logic then gated the traffic only with MAC addresses equal
> to X. Then I would manually add some IP address associated with MAC address
> X, to my host computer ARP table under the interface used to communicate
> with the secondary eth interface on the USRP. This would effectively create
> a ghost device that resides within the USRP. Hence I still use the ZPU to
> respond to the ARP requests but then I will address the ghost MAC in my
> application.
>
> So my advice to you here is don't try to be to clever with playing games
> with ARP etc, work within the paradigms of the protocols and the
> configuration and structures that are already provided largely for free in
> the USRP. If you really want to parse entire packets yourself in H/W then
> use a unique UDP socket and make some modest edits to eth_dispatch so that
> it classifies your packets (white-list rather than wild card) and sends
> them into your logic. For the time being you could use the XO port if the
> life time of your project is relatively short term, however if its a long
> term project then you should plan on future UHD versions enabling and
> actively using the XO path when the support of X300 daisy chaining is
> introduced in the future. Thus if you are future proofing then create
> another egress port from eth_dispatch and add more setting regs in unused
> address space using the existing code as a blue print. There are unlikely
> to be RTL changes from upstream to this module at this point as it's stable
> and complete so you are unlikely to need to do tricky merges in the future.
> It is very easy to use the ZPU peek/poke interface to program settings
> registers in this address space and set up your custom logic.
>
> If the volume of your ethernet traffic is low enough then consider just
> memory mapping your custom logic into the ZPU's buses and using the
> PEEK/POKE API via UDP?its incredibly simple to use.
>
> >
> > So my question is how does the flow control in the simple_gemac_wrapper
> work? Do you simply enable the logic then assign a value to rx_fifo_space
> and pause_tresh values? I plan to use this feature to throttle the IP
> packets that will be fed to the DUC chain.
>
> The simple rule is to NEVER back pressure the ethernet MAC's (1G or 10G),
> it will immediately interfere with USRP operation, potentially create
> packet fragments in the pipeline, and perhaps leave the H/W in a bad
> state. You must design all your H/W to be able to gracefully sink the
> maximum possible ethernet packet rate (even if you are just discarding
> packets to meet this rule). Ettus make no use of PAUSE frames within
> ethernet and there use will again interfere with normal USRP operation. All
> Ettus flow control algorithms are implemented above the UDP level in the
> network stack.
>
> As a general rule when designing for ethernet, expect the worst, indeed
> the impossible (i.e packets that are illegal by the spec)?traffic will
> arrive in unexpected bursts even for data streams that have average data
> rates far lower than the wire speed?whatever your host OS and network H/W,
> you will be SPAMmed by packets of no interest to you.
> -Ian
>
> >
> > Thanks,
> > Hrishikesh
> > _______________________________________________
> > 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/20140925/8f6b96e0/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 25 Sep 2014 10:43:55 -0700
From: Ian Buckley <[email protected]>
To: Chenfei Gao <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] change the master clock rate in N2x0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Chenfay,
In fact it's the other way around all USRP's EXCEPT the B2x0 (and X3x0) have a
fixed sample/clock rate.
Amongst other reasons, the specification of the anti-alias analog filtering on
the all the daughter cards is determined by the sample clock?the filter logic
is not programmable hence a flexible sample rate is of limited use.
B2x0 can do this because it has a very new and unique radio with programable
analog filters.
LTE radios built on N2x0 are quite possible and work well, you just have to
resample to a LTE related rate.
-Ian
On Sep 25, 2014, at 8:08 AM, Chenfei Gao via USRP-users
<[email protected]> wrote:
> Hi,
>
> I would like to run openLTE project on USRP N2x0 but it doesn't work due to
> the fixed 100MHz clock rate in N2X0.
>
> I am wondering if there is a way to change the clock rate in N2XO. As we
> know, B2x0 has configurable clock rate, but N2x0 has fixed rate.
> I can't make sense why N2x0 should be set to fixed clock rate. All other
> products are possible to change the clock rate except N2x0.
>
> Any answers would be appreciated.
>
> Best,
> Chenfay
> _______________________________________________
> 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/20140925/cef88c55/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 25 Sep 2014 10:45:02 -0700
From: Tom Tsou <[email protected]>
To: Martin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 + new WBX v3 daughterboard does not
work, but with old WBX v2 it works (OpenBTS)
Message-ID:
<caatym+yulfl_10n0whb6t-f+ibscdiz0uj85uzrqnotjcug...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 25, 2014 at 4:31 AM, Martin via USRP-users
<[email protected]> wrote:
> I seem to have found the problem.
> I had to lower the rxgain dramaticly.
>
> With old WBX v2 an rxgain of 47 would work fine. Even with phones as close
> as 1.5 meter from the USRP receive antenna.
> With WBX v3 I had to lower the rxgain to 10 to get it to work at this
> distance.
I can't explain the exact differences between WBX v2 and v3 and the
effect on handling different GSM signal levels, but I will say that
the default OpenBTS configuration can cause handsets to RACH at high
power levels. Depending on the operating band and device class, the
initial power level can be in excess of 30 dBm. During testing I've
measured RACH bursts through an antenna at levels around 10 dBm. With
receive gain at maximum, this is a bad combination.
Some device combinations might work better than others in the
max-rx-gain/max-tx-gain case. But, it doesn't surprise me that any
device combination might, at some point, become unpredictable in this
scenario.
-TT
------------------------------
Message: 7
Date: Thu, 25 Sep 2014 12:07:52 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi everyone,
we'll soon be releasing another bugfix release (3.7.3) and are putting
out a release candidate for now. It is tagged at
https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
Users working off of the 'maint' branch will be automatically updated if
you run a 'git pull'.
Note: This RC includes new images, so do run uhd_images_downloader if
you update. There is no warning or error if you don't update the images
(because they are still compatible), but you won't benefit from the
stability changes we introduced.
This RC mainly includes stability issues and bugfixes. The biggest
change is for the FPGA code, which is now easier to build.
Enjoy!
Martin
3.7.3-RC1 Changelog:
* Fixed examples
* Removed compiler warnings
* Fixed CBX LO settings (FRAC truncation)
* Fixed build issues for out-of-tree tools for some distros
* Fixed some logging strings (SBX, GPSDO)
* Improved logging (speedups, removed unnecessary cycles)
* Added output sync for DAC reference clocks on X300
------------------------------
Message: 8
Date: Thu, 25 Sep 2014 21:32:47 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
Will this also deal with the b210 issue discussed during the last days?
Thank you for all the continuous work on the code!
Ralph.
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Martin Braun via USRP-users
> Sent: Thursday, 25 September, 2014 21:08
> To: '[email protected]'
> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>
> Hi everyone,
>
> we'll soon be releasing another bugfix release (3.7.3) and are putting out a
> release candidate for now. It is tagged at
> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
>
> Users working off of the 'maint' branch will be automatically updated if you
> run a 'git pull'.
> Note: This RC includes new images, so do run uhd_images_downloader if you
> update. There is no warning or error if you don't
> update the images (because they are still compatible), but you won't benefit
> from the stability changes we introduced.
>
> This RC mainly includes stability issues and bugfixes. The biggest change is
> for the FPGA code, which is now easier to build.
>
> Enjoy!
>
> Martin
>
> 3.7.3-RC1 Changelog:
> * Fixed examples
> * Removed compiler warnings
> * Fixed CBX LO settings (FRAC truncation)
> * Fixed build issues for out-of-tree tools for some distros
> * Fixed some logging strings (SBX, GPSDO)
> * Improved logging (speedups, removed unnecessary cycles)
> * Added output sync for DAC reference clocks on X300
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140925/05b99892/attachment-0001.sig>
------------------------------
Message: 9
Date: Thu, 25 Sep 2014 12:42:32 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
My apologies, the tag is actually to be found here:
https://github.com/EttusResearch/uhd/tree/003_007_003_rc1
Cheers,
Martin
On 25.09.2014 12:07, Martin Braun wrote:
> Hi everyone,
>
> we'll soon be releasing another bugfix release (3.7.3) and are putting
> out a release candidate for now. It is tagged at
> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
>
> Users working off of the 'maint' branch will be automatically updated if
> you run a 'git pull'.
> Note: This RC includes new images, so do run uhd_images_downloader if
> you update. There is no warning or error if you don't update the images
> (because they are still compatible), but you won't benefit from the
> stability changes we introduced.
>
> This RC mainly includes stability issues and bugfixes. The biggest
> change is for the FPGA code, which is now easier to build.
>
> Enjoy!
>
> Martin
>
> 3.7.3-RC1 Changelog:
> * Fixed examples
> * Removed compiler warnings
> * Fixed CBX LO settings (FRAC truncation)
> * Fixed build issues for out-of-tree tools for some distros
> * Fixed some logging strings (SBX, GPSDO)
> * Improved logging (speedups, removed unnecessary cycles)
> * Added output sync for DAC reference clocks on X300
------------------------------
Message: 10
Date: Thu, 25 Sep 2014 12:44:41 -0700
From: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 25.09.2014 12:32, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> Will this also deal with the b210 issue discussed during the last days?
If you're talking about the disconnect issues: As far as we know, they
only occur on the master branch, so the maint branch should be
unaffected. However, we're also working on that issue at the moment.
> Thank you for all the continuous work on the code!
You're very welcome! Expect more improvements in the future!
Cheers,
Martin
>
> Ralph.
>
>> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On Behalf Of
>> Martin Braun via USRP-users
>> Sent: Thursday, 25 September, 2014 21:08
>> To: '[email protected]'
>> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>>
>> Hi everyone,
>>
>> we'll soon be releasing another bugfix release (3.7.3) and are putting out a
>> release candidate for now. It is tagged at
>> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
>>
>> Users working off of the 'maint' branch will be automatically updated if you
>> run a 'git pull'.
>> Note: This RC includes new images, so do run uhd_images_downloader if you
>> update. There is no warning or error if you don't
>> update the images (because they are still compatible), but you won't benefit
>> from the stability changes we introduced.
>>
>> This RC mainly includes stability issues and bugfixes. The biggest change is
>> for the FPGA code, which is now easier to build.
>>
>> Enjoy!
>>
>> Martin
>>
>> 3.7.3-RC1 Changelog:
>> * Fixed examples
>> * Removed compiler warnings
>> * Fixed CBX LO settings (FRAC truncation)
>> * Fixed build issues for out-of-tree tools for some distros
>> * Fixed some logging strings (SBX, GPSDO)
>> * Improved logging (speedups, removed unnecessary cycles)
>> * Added output sync for DAC reference clocks on X300
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Thu, 25 Sep 2014 20:51:44 +0000
From: <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] change the master clock rate in N2x0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
Exactly. If you check the code for the LTE_fdd_dl_scan utility
(LTE_fdd_dl_scan_flowgraph.cc), you will see that a resample filter is used for
the USRP Nx model.
Ruben
From: USRP-users [mailto:[email protected]] On Behalf Of Ian
Buckley via USRP-users
Sent: Thursday, September 25, 2014 7:44 PM
To: Chenfei Gao
Cc: [email protected]
Subject: Re: [USRP-users] change the master clock rate in N2x0
Chenfay,
In fact it's the other way around all USRP's EXCEPT the B2x0 (and X3x0) have a
fixed sample/clock rate.
Amongst other reasons, the specification of the anti-alias analog filtering on
the all the daughter cards is determined by the sample clock?the filter logic
is not programmable hence a flexible sample rate is of limited use.
B2x0 can do this because it has a very new and unique radio with programable
analog filters.
LTE radios built on N2x0 are quite possible and work well, you just have to
resample to a LTE related rate.
-Ian
On Sep 25, 2014, at 8:08 AM, Chenfei Gao via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I would like to run openLTE project on USRP N2x0 but it doesn't work due to the
fixed 100MHz clock rate in N2X0.
I am wondering if there is a way to change the clock rate in N2XO. As we know,
B2x0 has configurable clock rate, but N2x0 has fixed rate.
I can't make sense why N2x0 should be set to fixed clock rate. All other
products are possible to change the clock rate except N2x0.
Any answers would be appreciated.
Best,
Chenfay
_______________________________________________
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/20140925/60bc69d2/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 26 Sep 2014 14:26:19 +0200
From: boeglen herve <[email protected]>
To: <[email protected]>
Subject: [USRP-users] X310 + 2 CBX daughtercards strange behaviour
issue solved by UHD_003_007_003_rc1!
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all,
My preceeding posts indicated that X310 's RF1 (second
CBX) didn't work properly (noise floor around -60dB on GRC spectrum
graph).
This was definitely a bug solved by UHD upgrade to release
003_007_003_rc1 (thank you Martin !) this morning (see attached image).
I suggest that other people using this configuration be aware of this
issue!
Best regards
Herv?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140926/b7b0c75b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x310_2CBX_UHD_003_007_003_rc1.jpg
Type: application/octet-stream
Size: 216879 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140926/b7b0c75b/attachment-0001.jpg>
------------------------------
Message: 13
Date: Fri, 26 Sep 2014 08:38:16 -0700
From: Martin Braun <[email protected]>
To: boeglen herve <[email protected]>,
[email protected]
Subject: Re: [USRP-users] X310 + 2 CBX daughtercards strange behaviour
issue solved by UHD_003_007_003_rc1!
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Herv?,
thanks a lot for reporting this back. I'm glad this has solved an issue
for you!
Cheers,
Martin
On 26.09.2014 05:26, boeglen herve wrote:
> Hi all,
>
> My preceeding posts indicated that X310 's RF1 (second CBX) didn't work
> properly (noise floor around -60dB on GRC spectrum graph).
>
> This was definitely a bug solved by UHD upgrade to release
> 003_007_003_rc1 (thank you Martin !) this morning (see attached image).
>
> I suggest that other people using this configuration be aware of this issue!
>
> Best regards
>
> Herv?
>
------------------------------
Message: 14
Date: Fri, 26 Sep 2014 11:39:10 -0400
From: Robert Palumbo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] XADC Usage on X300??
Message-ID:
<cakwzk9z4rr-w5wy9mu3oxnuuzelp-0u8g0nkmqsd254o4vg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey,
I'm trying to instantiate an XADC on my X300, to expose the build-in
temperature/voltage monitoring capabilities. However, I can't seem to get
any valid output from the module. I've never used an XADC before, but the
documentation says that on-chip voltage/temperature sensors should be
available, provided the XADC Vcc/Vaux are connected.
Has anyone out there successfully instantiated and used the XADC on the
X3xx-devices?
Thanks for any help anyone can give,
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/20140926/7ccfc0a2/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 49, Issue 25
******************************************
