Send USRP-users mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via , send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Question on set_rx_bandwidth (Dario Fertonani)
2. Re: Question on set_rx_bandwidth (Marcus D. Leech)
3. Re: Question on set_rx_bandwidth (Ian Buckley)
4. Re: Question on set_rx_bandwidth (Ian Buckley)
5. Re: Question on set_rx_bandwidth (Marcus D. Leech)
6. Re: Question on set_rx_bandwidth (Dario Fertonani)
7. X3x0 Multi-Box Host IP Setup (Joe Leech)
8. Re: X3x0 Multi-Box Host IP Setup (Marcus D. Leech)
9. Re: X3x0 Multi-Box Host IP Setup (Marcus M?ller)
10. Re: X3x0 Multi-Box Host IP Setup (Marcus M?ller)
11. Minimum Clock Frequency (E100 + WBX 40) (Thierry Guichon)
12. UHD Driver behavior (Thierry Guichon)
13. Re: X3x0 Multi-Box Host IP Setup (Ian Buckley)
14. Re: Minimum Clock Frequency (E100 + WBX 40) (Marcus D. Leech)
15. Re: Minimum Clock Frequency (E100 + WBX 40) (Ian Buckley)
16. Re: UHD Driver behavior (Philip Balister)
17. Re: UHD Driver behavior (Marcus D. Leech)
18. UHD Error: recv packet demuxer unexpected sid (Luke Berndt)
19. Re: B210 Power Port broken - can this be fixed? (Soumen Banerjee)
20. Calibration: IQ imbalance and DC offset (Khalid Jamil)
21. Re: B210 Power Port broken - can this be fixed? (Marcus M?ller)
22. USRP N210+WBX: Problem to receive GPS-Signal in
MATLAB/Simulink (ffellner)
23. Re: B210 Power Port broken - can this be fixed? (Soumen Banerjee)
24. Re: USRP N210+WBX: Problem to receive GPS-Signal in
MATLAB/Simulink (Mike McLernon)
25. Re: Calibration: IQ imbalance and DC offset (Marcus D. Leech)
26. Corgan Labs Expands Offering with Public and Advanced Courses
(Johnathan Corgan)
27. Re: UHD Driver behavior (Martin Braun)
28. Re: Question on set_rx_bandwidth (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Feb 09:50:26 -
From: Dario Fertonani <>
To: "" <>
Subject: [USRP-users] Question on set_rx_bandwidth
Message-ID:
<>
Content-Type: text/plain; charset="iso--1"
My Ettus board is the B210 model. On the host PC I'm using UHD built from
source, all running on Ubuntu 14.10 low latency.
With the UHD version from Git (UHD_003.008.002-80-ge28d), I am able to
set the desired carrier frequency and sampling rate with set_rx_freq and
set_rx_rate. The same is not true for the Ubuntu-packaged version, which
somehow rounds those values to master-clock-friendly values.
On the other hand, the call to set_rx_bandwidth seems to be ignored by the
board, since get_rx_bandwidth always returns 56 MHz. I did check that the
requested value is within the range returned by get_rx_bandwidth_range.
In case it matters, the values of interest here are LTE values such as a
739 MHz carrier, a 15.36 MHz sampling rate and a bandwidth somewhat below
15.36 MHz. Reading 56 MHz for a signal sampled at 15.36 MHz makes me
worried. Anything I'm missing?
Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 2
Date: Tue, 17 Feb 12:59:03 -
From: "Marcus D. Leech" <>
To:
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID: <>
Content-Type: text/plain; charset="iso--1"; Format="flowed"
On 02/17/ 12:50 PM, Dario Fertonani via USRP-users wrote:
> My Ettus board is the B210 model. On the host PC I'm using UHD built
> from source, all running on Ubuntu 14.10 low latency.
>
> With the UHD version from Git (UHD_003.008.002-80-ge28d), I am
> able to set the desired carrier frequency and sampling rate
> with set_rx_freq and set_rx_rate. The same is not true for the
> Ubuntu-packaged version, which somehow rounds those values to
> master-clock-friendly values.
>
> On the other hand, the call to set_rx_bandwidth seems to be ignored by
> the board, since get_rx_bandwidth always returns 56 MHz. I did check
> that the requested value is within the range returned by
> get_rx_bandwidth_range.
> In case it matters, the values of interest here are LTE values such as
> a 739 MHz carrier, a 15.36 MHz sampling rate and a bandwidth somewhat
> below 15.36 MHz. Reading 56 MHz for a signal sampled at 15.36 MHz
> makes me worried. Anything I'm missing?
>
> Thanks,
> Dario
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Whatever sample-rate you pick *MUST* be an integer fraction of the
master-clock rate, which by default if you don't set it, is 32MHz. There
is no
fractional resampling done in the hardware.
Also, whatever sample-rate you pick to the host, and chunk of bandwidth
will be alias free. The analog and digital "guts" in the AD deliver
an alias-free
bandwidth to the FPGA, which in turn filters and decimates down the
desired bandwidth. So, no, you're not sampling 56MHz of bandwidth with a
15.36Mhz ADC. In fact, the AD samples internally at a very
high sample-rate, with fewer bits, and uses its DSP and sigma-delta
machinery to
deliver the appropriate rate as requested by the FPGA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 3
Date: Tue, 17 Feb 10:14:32 -
From: Ian Buckley <>
To: Dario Fertonani <>
Cc: "" <>
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID: <>
Content-Type: text/plain; charset="iso--1"
(On B210) Currently set_rx_bandwidth/get_rx_bandwidth is a stubbed out API call
that as you spotted does nothing useful. The underlying driver code sets the
analog baseband filters to a bandwidth thats appropriate for the full potential
bandwidth of your sample rate, attenuating power in adjacent channels (RX) and
removing converter aliasing (TX).
There is currently code in development/review that fully implements the
set_rx_bandwidth API call so that users can override these default settings of
the analog filters and reduce the filter bandwidth further, but most users will
not need this functionality except in very demanding and unusual applications.
There are people doing LTE and meeting ACLR etc requirements already just
through the many stages of digital filtering so I wouldn't be over concerned.
-Ian
On Feb 17, , at 9:50 AM, Dario Fertonani via USRP-users
<> wrote:
> My Ettus board is the B210 model. On the host PC I'm using UHD built from
> source, all running on Ubuntu 14.10 low latency.
>
> With the UHD version from Git (UHD_003.008.002-80-ge28d), I am able to
> set the desired carrier frequency and sampling rate with set_rx_freq and
> set_rx_rate. The same is not true for the Ubuntu-packaged version, which
> somehow rounds those values to master-clock-friendly values.
>
> On the other hand, the call to set_rx_bandwidth seems to be ignored by the
> board, since get_rx_bandwidth always returns 56 MHz. I did check that the
> requested value is within the range returned by get_rx_bandwidth_range.
> In case it matters, the values of interest here are LTE values such as a 739
> MHz carrier, a 15.36 MHz sampling rate and a bandwidth somewhat below 15.36
> MHz. Reading 56 MHz for a signal sampled at 15.36 MHz makes me worried.
> Anything I'm missing?
>
> Thanks,
> Dario
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 4
Date: Tue, 17 Feb 10:18:45 -
From: Ian Buckley <>
To: "Marcus D. Leech" <>
Cc:
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID: <>
Content-Type: text/plain; charset="iso--1"
On Feb 17, , at 9:59 AM, Marcus D. Leech via USRP-users
<> wrote:
> On 02/17/ 12:50 PM, Dario Fertonani via USRP-users wrote:
>> My Ettus board is the B210 model. On the host PC I'm using UHD built from
>> source, all running on Ubuntu 14.10 low latency.
>>
>> With the UHD version from Git (UHD_003.008.002-80-ge28d), I am able to
>> set the desired carrier frequency and sampling rate with set_rx_freq and
>> set_rx_rate. The same is not true for the Ubuntu-packaged version, which
>> somehow rounds those values to master-clock-friendly values.
>>
>> On the other hand, the call to set_rx_bandwidth seems to be ignored by the
>> board, since get_rx_bandwidth always returns 56 MHz. I did check that the
>> requested value is within the range returned by get_rx_bandwidth_range.
>> In case it matters, the values of interest here are LTE values such as a 739
>> MHz carrier, a 15.36 MHz sampling rate and a bandwidth somewhat below 15.36
>> MHz. Reading 56 MHz for a signal sampled at 15.36 MHz makes me worried.
>> Anything I'm missing?
>>
>> Thanks,
>> Dario
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Whatever sample-rate you pick *MUST* be an integer fraction of the
> master-clock rate, which by default if you don't set it, is 32MHz. There is
> no
> fractional resampling done in the hardware.
>
> Also, whatever sample-rate you pick to the host, and chunk of bandwidth will
> be alias free. The analog and digital "guts" in the AD deliver an
> alias-free
> bandwidth to the FPGA, which in turn filters and decimates down the desired
> bandwidth. So, no, you're not sampling 56MHz of bandwidth with a
> 15.36Mhz ADC. In fact, the AD samples internally at a very high
> sample-rate, with fewer bits, and uses its DSP and sigma-delta machinery to
> deliver the appropriate rate as requested by the FPGA.
>
Marcus,
Herr Braun has recently introduced code that attempts to intelligently pick
appropriate master_clock_rates for the requested sample rate when it's not
explicitly specified. I believe thats in the public repo now.
-Ian
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 5
Date: Tue, 17 Feb 13:21:20 -
From: "Marcus D. Leech" <>
To: Ian Buckley <>
Cc:
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID: <>
Content-Type: text/plain; charset=ISO--1; format=flowed
On 02/17/ 01:18 PM, Ian Buckley wrote:
> Marcus,
> Herr Braun has recently introduced code that attempts to intelligently
> pick appropriate master_clock_rates for the requested sample rate when
> it's not explicitly specified. I believe thats in the public repo now.
> -Ian
>
Ah, I missed that, but had been thinking for a couple of years that kind
of thing makes sense for master-clock-agile USRPs.
------------------------------
Message: 6
Date: Tue, 17 Feb 10:21:26 -
From: Dario Fertonani <>
To: Ian Buckley <>
Cc: "" <>
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID:
<>
Content-Type: text/plain; charset="iso--1"
Thank you Ian. I didn't realize that, despite the value returned by
get_rx_bandwidth
being constant, the actual bandwidth changes according to the requested
sampling rate.
Best regards,
Dario
On Tue, Feb 17, at 10:14 AM, Ian Buckley <> wrote:
> (On B210) Currently set_rx_bandwidth/get_rx_bandwidth is a stubbed out API
> call that as you spotted does nothing useful. The underlying driver code
> sets the analog baseband filters to a bandwidth thats appropriate for the
> full potential bandwidth of your sample rate, attenuating power in adjacent
> channels (RX) and removing converter aliasing (TX).
>
> There is currently code in development/review that fully implements the
> set_rx_bandwidth API call so that users can override these default settings
> of the analog filters and reduce the filter bandwidth further, but most
> users will not need this functionality except in very demanding and unusual
> applications. There are people doing LTE and meeting ACLR etc requirements
> already just through the many stages of digital filtering so I wouldn't be
> over concerned.
>
> -Ian
>
> On Feb 17, , at 9:50 AM, Dario Fertonani via USRP-users <
> > wrote:
>
> My Ettus board is the B210 model. On the host PC I'm using UHD built from
> source, all running on Ubuntu 14.10 low latency.
>
> With the UHD version from Git (UHD_003.008.002-80-ge28d), I am able to
> set the desired carrier frequency and sampling rate with set_rx_freq and
> set_rx_rate. The same is not true for the Ubuntu-packaged version, which
> somehow rounds those values to master-clock-friendly values.
>
> On the other hand, the call to set_rx_bandwidth seems to be ignored by the
> board, since get_rx_bandwidth always returns 56 MHz. I did check that the
> requested value is within the range returned by get_rx_bandwidth_range.
> In case it matters, the values of interest here are LTE values such as a
> 739 MHz carrier, a 15.36 MHz sampling rate and a bandwidth somewhat below
> 15.36 MHz. Reading 56 MHz for a signal sampled at 15.36 MHz makes me
> worried. Anything I'm missing?
>
> Thanks,
> Dario
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 7
Date: Tue, 17 Feb 15:01:38 -
From: Joe Leech <>
To: "" <>
Subject: [USRP-users] X3x0 Multi-Box Host IP Setup
Message-ID: <>
Content-Type: text/plain; charset="iso--1"
Hello,
I am trying to connect 2 USRP X300 boxes onto the same PC host in Linux. I have
the Intel 10GbE NIC that is recommended on the Ettus website. I read over the
documentation, but I don't see a way of changing the host static IP. I think
maybe it is due to my limited knowledge in this area... but here goes:
Hardware:
- I connect box0 to port1 on the box (for 10GbE), and on the NIC I connect to
port1.
- box1 also has connection from port 1 (again, for 10GbE) to NIC's port2.
I cannot set up both ports on the NIC to the same host static IP (192.168.40.1)
because only 1 will be active.
X300 Box0: host static IP is 192.168.40.1, box IP: 192.168.40.2.
X300 Box1: host static IP is 192.168.40.1, box IP: 192.168.40.3. <-- I used the
usrp_burn_mb_eeprom to change the box IP.
However, only box0 will ping back (it's the first one that grabbed the host
static IP). So I think now I need a way to change the host static IP on Box1,
but there's not eeprom field for the host static IP.
NOTE: If this is not the optimal way to connect 2 boxes, what is? I am trying
to sync the 2 boxes via the 10MHz reference and the PPS clock. Is there a
better way of doing it? Or, what am I doing wrong? Thanks in advance!
Best Regards,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 8
Date: Tue, 17 Feb 18:29:06 -
From: "Marcus D. Leech" <>
To:
Subject: Re: [USRP-users] X3x0 Multi-Box Host IP Setup
Message-ID: <>
Content-Type: text/plain; charset="iso--1"; Format="flowed"
On 02/17/ 06:01 PM, Joe Leech via USRP-users wrote:
> Hello,
>
> I am trying to connect 2 USRP X300 boxes onto the same PC host in
> Linux. I have the Intel 10GbE NIC that is recommended on the Ettus
> website. I read over the documentation, but I don't see a way of
> changing the host static IP. I think maybe it is due to my limited
> knowledge in this area... but here goes:
>
> Hardware:
> - I connect box0 to port1 on the box (for 10GbE), and on the NIC I
> connect to port1.
> - box1 also has connection from port 1 (again, for 10GbE) to NIC's port2.
>
> I cannot set up both ports on the NIC to the same host static IP
> (192.168.40.1) because only 1 will be active.
>
> X300 Box0: host static IP is 192.168.40.1, box IP: 192.168.40.2.
> X300 Box1: host static IP is 192.168.40.1, box IP: 192.168.40.3. <-- I
> used the usrp_burn_mb_eeprom to change the box IP.
>
> However, only box0 will ping back (it's the first one that grabbed the
> host static IP). So I think now I need a way to change the host static
> IP on Box1, but there's not eeprom field for the host static IP.
>
> NOTE: If this is not the optimal way to connect 2 boxes, what is? I am
> trying to sync the 2 boxes via the 10MHz reference and the PPS clock.
> Is there a better way of doing it? Or, what am I doing wrong? Thanks
> in advance!
>
> Best Regards,
> Joe
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The two ports on your NIC will necessarily need IP addresses on
different subnets, so one of your two USRPs will also need to be on the
same subnet
as it. This isn't really USRP-specific, just generic TCP/IP
networking stuff.
If you use ifconfig on your dual-port 10Gb NICs, you'll see (or should
see) different IP subnets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 9
Date: Wed, 18 Feb 00:31:29 +
From: Marcus M?ller <>
To:
Subject: Re: [USRP-users] X3x0 Multi-Box Host IP Setup
Message-ID: <>
Content-Type: text/plain; charset="windows-"
Hi Joe,
you can't assign the same IP address to two different network card ports
(but you can assign two IP addresses to a single one).
I recommend using two ip addresses from two different subnets for each
ports. For example
NIC port 0: 192.168.40.1, network mask 255.255.255.0; USRP0: 192.168.40.2
NIC port 0: 192.168.41.1, network mask 255.255.255.0; USRP1: 192.168.41.2
This way, the operating system knows for every packet which NIC port it
should use.
You can then use a multi_usrp device with adress string
"addr0=192.168.40.2,addr1=192.168.41.2" to get an unified interface to
both devices.
After that, it's simply a matter of using
set_time_unknown_pps(time_spec_t()) on the mutlti_usrp object[1].
Greetings,
Marcus
[1]
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abf3aea4a8ea2d268b4a3b390e9
On 02/18/ 12:01 AM, Joe Leech via USRP-users wrote:
> Hello,
>
> I am trying to connect 2 USRP X300 boxes onto the same PC host in
> Linux. I have the Intel 10GbE NIC that is recommended on the Ettus
> website. I read over the documentation, but I don't see a way of
> changing the host static IP. I think maybe it is due to my limited
> knowledge in this area... but here goes:
>
> Hardware:
> - I connect box0 to port1 on the box (for 10GbE), and on the NIC I
> connect to port1.
> - box1 also has connection from port 1 (again, for 10GbE) to NIC's port2.
>
> I cannot set up both ports on the NIC to the same host static IP
> (192.168.40.1) because only 1 will be active.
>
> X300 Box0: host static IP is 192.168.40.1, box IP: 192.168.40.2.
> X300 Box1: host static IP is 192.168.40.1, box IP: 192.168.40.3. <-- I
> used the usrp_burn_mb_eeprom to change the box IP.
>
> However, only box0 will ping back (it's the first one that grabbed the
> host static IP). So I think now I need a way to change the host static
> IP on Box1, but there's not eeprom field for the host static IP.
>
> NOTE: If this is not the optimal way to connect 2 boxes, what is? I am
> trying to sync the 2 boxes via the 10MHz reference and the PPS clock.
> Is there a better way of doing it? Or, what am I doing wrong? Thanks
> in advance!
>
> Best Regards,
> Joe
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 10
Date: Wed, 18 Feb 00:32:44 +
From: Marcus M?ller <>
To:
Subject: Re: [USRP-users] X3x0 Multi-Box Host IP Setup
Message-ID: <>
Content-Type: text/plain; charset="windows-"
Oh, and don't forget to set the clock source to external!
On 02/18/ 12:31 AM, Marcus M?ller wrote:
> Hi Joe,
>
> you can't assign the same IP address to two different network card
> ports (but you can assign two IP addresses to a single one).
> I recommend using two ip addresses from two different subnets for each
> ports. For example
> NIC port 0: 192.168.40.1, network mask 255.255.255.0; USRP0: 192.168.40.2
> NIC port 0: 192.168.41.1, network mask 255.255.255.0; USRP1: 192.168.41.2
> This way, the operating system knows for every packet which NIC port
> it should use.
> You can then use a multi_usrp device with adress string
> "addr0=192.168.40.2,addr1=192.168.41.2" to get an unified interface to
> both devices.
> After that, it's simply a matter of using
> set_time_unknown_pps(time_spec_t()) on the mutlti_usrp object[1].
>
> Greetings,
> Marcus
> [1]
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abf3aea4a8ea2d268b4a3b390e9
> On 02/18/ 12:01 AM, Joe Leech via USRP-users wrote:
>> Hello,
>>
>> I am trying to connect 2 USRP X300 boxes onto the same PC host in
>> Linux. I have the Intel 10GbE NIC that is recommended on the Ettus
>> website. I read over the documentation, but I don't see a way of
>> changing the host static IP. I think maybe it is due to my limited
>> knowledge in this area... but here goes:
>>
>> Hardware:
>> - I connect box0 to port1 on the box (for 10GbE), and on the NIC I
>> connect to port1.
>> - box1 also has connection from port 1 (again, for 10GbE) to NIC's port2.
>>
>> I cannot set up both ports on the NIC to the same host static IP
>> (192.168.40.1) because only 1 will be active.
>>
>> X300 Box0: host static IP is 192.168.40.1, box IP: 192.168.40.2.
>> X300 Box1: host static IP is 192.168.40.1, box IP: 192.168.40.3. <--
>> I used the usrp_burn_mb_eeprom to change the box IP.
>>
>> However, only box0 will ping back (it's the first one that grabbed
>> the host static IP). So I think now I need a way to change the host
>> static IP on Box1, but there's not eeprom field for the host static IP.
>>
>> NOTE: If this is not the optimal way to connect 2 boxes, what is? I
>> am trying to sync the 2 boxes via the 10MHz reference and the PPS
>> clock. Is there a better way of doing it? Or, what am I doing wrong?
>> Thanks in advance!
>>
>> Best Regards,
>> Joe
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 11
Date: Tue, 17 Feb 19:51:00 -
From: "Thierry Guichon" <>
To: "'USRP Mailing List'" <>
Subject: [USRP-users] Minimum Clock Frequency (E100 + WBX 40)
Message-ID:
Content-Type: text/plain; charset="us-ascii"
Hello,
I would like to the use the system at a clock frequency of 19,660,800 MHz.
with a resulting output sample rate of sps.
I can program the system to that frequency. So far so good.
Should I anticipate some performance degradation from the ADC/DAC or other
part of the system due to this low system clock frequency?
Thank you
Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 12
Date: Tue, 17 Feb 19:59:14 -
From: "Thierry Guichon" <>
To: "'USRP Mailing List'" <>
Subject: [USRP-users] UHD Driver behavior
Message-ID: <68DDF451DFEC81FEE7@Tristan>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am interested to better understand the interaction between the IQ packets
received on the line (between the FPGA and the host) and the buffer that the
application provides to the driver.
Does the UHD driver buffers data until the user provides a buffer? If yes,
how big is that buffer?
After the rx_stream->recv function returns, how long can the user wait
before providing another buffer?
Thanks
Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 13
Date: Tue, 17 Feb 17:01:11 -
From: Ian Buckley <>
To: Marcus M?ller <>
Cc:
Subject: Re: [USRP-users] X3x0 Multi-Box Host IP Setup
Message-ID: <>
Content-Type: text/plain; charset="windows-"
Joe,
One more thing, I get the impression from your original question that you had
the impression that the USRP may have been programmed with a hard coded address
for the host it is to communicate with?
It doesn't work this way ?the USRP remains initially idle and is "discovered"
by the host?it then just replies to the host that discovered (and claimed) it.
The host can have any arbitrary IP address within the same subnet.
-Ian
On Feb 17, , at 3:31 PM, Marcus M?ller via USRP-users
<> wrote:
> Hi Joe,
>
> you can't assign the same IP address to two different network card ports (but
> you can assign two IP addresses to a single one).
> I recommend using two ip addresses from two different subnets for each ports.
> For example
> NIC port 0: 192.168.40.1, network mask 255.255.255.0; USRP0: 192.168.40.2
> NIC port 0: 192.168.41.1, network mask 255.255.255.0; USRP1: 192.168.41.2
> This way, the operating system knows for every packet which NIC port it
> should use.
> You can then use a multi_usrp device with adress string
> "addr0=192.168.40.2,addr1=192.168.41.2" to get an unified interface to both
> devices.
> After that, it's simply a matter of using set_time_unknown_pps(time_spec_t())
> on the mutlti_usrp object[1].
>
> Greetings,
> Marcus
> [1]
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abf3aea4a8ea2d268b4a3b390e9
> On 02/18/ 12:01 AM, Joe Leech via USRP-users wrote:
>> Hello,
>>
>> I am trying to connect 2 USRP X300 boxes onto the same PC host in Linux. I
>> have the Intel 10GbE NIC that is recommended on the Ettus website. I read
>> over the documentation, but I don't see a way of changing the host static
>> IP. I think maybe it is due to my limited knowledge in this area... but here
>> goes:
>>
>> Hardware:
>> - I connect box0 to port1 on the box (for 10GbE), and on the NIC I connect
>> to port1.
>> - box1 also has connection from port 1 (again, for 10GbE) to NIC's port2.
>>
>> I cannot set up both ports on the NIC to the same host static IP
>> (192.168.40.1) because only 1 will be active.
>>
>> X300 Box0: host static IP is 192.168.40.1, box IP: 192.168.40.2.
>> X300 Box1: host static IP is 192.168.40.1, box IP: 192.168.40.3. <-- I used
>> the usrp_burn_mb_eeprom to change the box IP.
>>
>> However, only box0 will ping back (it's the first one that grabbed the host
>> static IP). So I think now I need a way to change the host static IP on
>> Box1, but there's not eeprom field for the host static IP.
>>
>> NOTE: If this is not the optimal way to connect 2 boxes, what is? I am
>> trying to sync the 2 boxes via the 10MHz reference and the PPS clock. Is
>> there a better way of doing it? Or, what am I doing wrong? Thanks in advance!
>>
>> Best Regards,
>> Joe
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 14
Date: Tue, 17 Feb 20:07:33 -
From: "Marcus D. Leech" <>
To:
Subject: Re: [USRP-users] Minimum Clock Frequency (E100 + WBX 40)
Message-ID: <>
Content-Type: text/plain; charset="iso--1"; Format="flowed"
On 02/17/ 07:51 PM, Thierry Guichon via USRP-users wrote:
>
> Hello,
>
> I would like to the use the system at a clock frequency of 19,660,800
> MHz. with a resulting output sample rate of sps.
>
> I can program the system to that frequency. So far so good.
>
> Should I anticipate some performance degradation from the ADC/DAC or
> other part of the system due to this low system clock frequency?
>
> Thank you
>
> Thierry
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
http://files.ettus.com/manual/page_usrp_e1x0.html#e1x0_mcr
Rates between 32Mhz and 64Mhz are supported.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 15
Date: Tue, 17 Feb 17:17:04 -
From: Ian Buckley <>
To:
Cc: 'USRP Mailing List' <>
Subject: Re: [USRP-users] Minimum Clock Frequency (E100 + WBX 40)
Message-ID: <>
Content-Type: text/plain; charset="windows-"
Thierry,
The WBX-40 has analog low pass filters centered on DC with a complex 3dB
bandwidth of approx 40MHz (20MHz either side of DC).
With the converters running at ~19.6MHz there is potential for signals in
different Nyquist zones to alias onto each other on RX.
On TX it *might* be OK because I think the codec used on this device up-samples
and interpolates again by either 2x or 4x before the DAC?but I'm not sure
because the schematic fails to call out the exact part.
-Ian
On Feb 17, , at 4:51 PM, Thierry Guichon via USRP-users
<> wrote:
> Hello,
>
> I would like to the use the system at a clock frequency of 19,660,800 MHz.
> with a resulting output sample rate of sps.
> I can program the system to that frequency. So far so good.
>
> Should I anticipate some performance degradation from the ADC/DAC or other
> part of the system due to this low system clock frequency?
>
>
> Thank you
>
>
> Thierry
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 16
Date: Tue, 17 Feb 17:38:21 -
From: Philip Balister <>
To: , 'USRP Mailing List'
<>
Subject: Re: [USRP-users] UHD Driver behavior
Message-ID: <>
Content-Type: text/plain; charset=windows-
On 02/17/ 04:59 PM, Thierry Guichon via USRP-users wrote:
> Hello,
>
>
>
>
>
> I am interested to better understand the interaction between the IQ packets
> received on the line (between the FPGA and the host) and the buffer that the
> application provides to the driver.
>
>
>
> Does the UHD driver buffers data until the user provides a buffer? If yes,
> how big is that buffer?
>
> After the rx_stream->recv function returns, how long can the user wait
> before providing another buffer?
Basically, after you start streaming, data is filling a buffer in the
kernel. Each time you call recv, uhd takes the integer data from the
buffer, converts to complex float and writes to the buffer you provide
and returns. You can call recv at anytime, if there is no data the call
will block until there is data.
https://github.com/balister/linux-omap-philip/blob/e100-3.0-pm-2-bugfixes/drivers/misc/usrp_e.c
Looks like the TX and RX buffers are 1MBytes each.
I worked on this and my memory is getting fuzzy :)
Philip
>
>
>
>
>
> Thanks
>
>
>
>
>
> Thierry
>
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Tue, 17 Feb 20:54:28 -
From: "Marcus D. Leech" <>
To:
Subject: Re: [USRP-users] UHD Driver behavior
Message-ID: <>
Content-Type: text/plain; charset=ISO--1; format=flowed
On 02/17/ 08:38 PM, Philip Balister via USRP-users wrote
> Basically, after you start streaming, data is filling a buffer in the
> kernel. Each time you call recv, uhd takes the integer data from the
> buffer, converts to complex float and writes to the buffer you provide
> and returns. You can call recv at anytime, if there is no data the call
> will block until there is data.
>
> https://github.com/balister/linux-omap-philip/blob/e100-3.0-pm-2-bugfixes/drivers/misc/usrp_e.c
>
> Looks like the TX and RX buffers are 1MBytes each.
>
> I worked on this and my memory is getting fuzzy :)
>
> Philip
I should point out that in the general case, rather than the E1xx case
(and now the E3xx case), it's a hard question to answer, since Ettus doesn't
control the underlying operating system network stack or USB stack,
so answering "how much buffering is between my application and that deluge
of data coming out of the USRP device" has no precise answer, in the
network-stack case, it's more complicated since there's a buffer pool in the
kernel network stack that is shared among all processes currently
using network services. It's very dynamic.
In the *specific* case of the E1xx, and E3xx, since Ettus wrote the
very-custom-interface drivers, it's an easier to answer question.
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> Thierry
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 18
Date: Tue, 17 Feb 21:53:51 -
From: Luke Berndt <>
To:
Subject: [USRP-users] UHD Error: recv packet demuxer unexpected sid
Message-ID: <>
Content-Type: text/plain; charset=utf-8
Hi - I have been running into the "UHD Error: recv packet demuxer unexpected
sid? error. I have checked in the archives, and while I have seen other people
digging into, I couldn?t find a solution.
I get the error message after roughly 45 minutes or so. I am doing a fair
number of lock()/unlock() to reconfigure the graph, perhaps ~150 over that time
period. If I switch to a method that doesn?t have use lock/unlock, this error
never comes up.
I believe I am running the latest version of GnuRadio, UHD & Ubuntu. I have
installed everything using PyBombs. Any pointers would be great!
Diagnostics
-------------------------
I am running a B200 on an I7 Mac Mini that is running Ubuntu 14.04.1.
The USB Controller is:
USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI
Host Controller (rev 04)
I am setting it to 8Msps in C++, using:
gr::uhd::usrp_source::sptr usrp_src;
usrp_src = gr::uhd::usrp_source::make(device,uhd::stream_args_t("fc32"));
usrp_src->set_samp_rate(rate);
Here is the results from running uhd_probe:
luke@min-luke:/usr/local/share$ uhd_usrp_probe
linux; GNU C++ version 4.8.2; Boost_; UHD_003.008.002-91-g7d97ab60
-- Loading firmware image:
/home/luke/gr3.7/share/uhd/images/usrp_b200_fw.hex... done
-- Loading FPGA image: /home/luke/gr3.7/share/uhd/images/usrp_b200_fpga.bin...
done
-- Operating over USB 3.
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32. MHz...
-- Actually got clock rate 32. MHz.
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
_____________________________________________________
/
| Device: B-Series Device
| _____________________________________________________
| /
| | Mboard: B200
| | revision: 4
| | product: 1
| | serial: E68
| | FW Version: 7.0
| | FPGA Version: 4.0
| |
| | Time sources: none, internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -16.000 to 16.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: FE-RX2
| | | | Antennas: TX/RX, RX2
| | | | Sensors: lo_locked, temp, rssi
| | | | Freq range: 50.000 to .000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: B200 RX dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -16.000 to 16.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: FE-TX2
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, temp
| | | | Freq range: 50.000 to .000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: B200 TX dual DAC
| | | | Gain Elements: None
------------------------------
Message: 19
Date: Wed, 18 Feb 09:17:28 +
From: Soumen Banerjee <>
To: "Ralph A. Schmid dk5ras" <>
Cc: "" <>
Subject: Re: [USRP-users] B210 Power Port broken - can this be fixed?
Message-ID:
Content-Type: text/plain; charset="iso--1"
Hi,
In addition, did I mark the correct end of L601 in my picture? I dont want
to end up soldering on the wrong end if I can help it :) Ive attached it
again for reference. Once Im sure on this one(and the choice of fuse), I'd
just go ahead and try to make this work by using my own fuse with it.
Would the status light glow a different color on external power? I mostly
use it on bus power, so I dont know if there is a different color. I found
a description for the green version of the board though and it mentioned
that it glows green on external power. Does that hold for my(white) board
as well?
Regards,
Soumen
On Tue, Feb 17, at 8:55 PM, Soumen Banerjee <> wrote:
> Hi,
> Im not sure how to procure the fuse you mention in India. Can I use
> another fuse with the 4 amp rating? Does the fast action matter a whole
> lot? Perhaps I could use a lower rating, say 2A and get away with it?
> Regards,
> Soumen
> On 17-Feb- 8:28 pm, "Ralph A. Schmid, dk5ras" <>
> wrote:
>
>> A fuse is always a good idea, mostly against a wrong power supply with
>> excessive voltage or reversed polarity.
>>
>>
>>
>> Ralph.
>>
>>
>>
>> *From:* Marcus M?ller [mailto:]
>> *Sent:* Tuesday, February 17, 3:49 PM
>> *To:* Soumen Banerjee; Ralph A. Schmid, dk5ras
>> *Cc:* usrp-users
>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>
>>
>>
>> Hi Soumen,
>>
>> the idea that you could glue back the connector in place was really just
>> about the connector having a place to sit. The positive contacts can't be
>> saved.
>>
>> I'd have to stick with Sylvain here (sorry, Ralph), but the wire
>> shouldn't be very thin. But yes, the idea is to lead the current from the
>> connetor through a fuse to L601. Now, F100 is the right fuse to do that,
>> but it's so tiny that you'll have a hard time soldering any cable to it, no
>> matter how thin, thus my approach to use your own fuse, and solder to L601
>> directly.
>>
>> Regarding why F100 is there:
>> a) it's an external power supply. You simply protect such inputs by
>> principle alone :)
>> b) Whilst you're right, and a blown fuse would usually be related to a
>> rather drastic board failure somewhere else, it still protects the board --
>> for example, anything that falls onto the board might shorten supply
>> voltage to ground, which would destroy the PCB, if it wasn't for the fuse.
>> Also, the power converter semiconductors, inductors and capacitors are
>> designed with quite a bit of headroom, if the overload situation doesn't
>> last too long or doesn't exceed a certain voltage.
>>
>> Greetings,
>> Marcus
>>
>> On 02/17/ 03:16 PM, Soumen Banerjee wrote:
>>
>> Hi,
>>
>>
>>
>> The ground pad is actually available on the board. It is the positive
>> pads that have been ripped off.
>>
>>
>>
>> I'm a little unsure of what you guys are suggesting with respect to
>> glueing the power jack back onto the board. If I did that, I could easily
>> re-establish the connection with the ground pad but Im not sure about the
>> positive pad. Are you suggesting I take a thin lead out of the power jack,
>> and solder it before the F100? The F100 is so small, Im not sure that can
>> be done with a micro-tip soldering iron. If you are suggesting something
>> else, I could use a little further clarification.
>>
>>
>>
>> Also, I was wondering why we have the fuse at all. If the fuse were to
>> get blown, wouldnt it mean that the board was, for all intents and purposes
>> fried? Unless of course if the fuse is replaceable. Is it?
>>
>>
>>
>> Regards,
>>
>> Soumen
>>
>>
>>
>> On Tue, Feb 17, at 7:00 PM, Ralph A. Schmid, dk5ras via USRP-users <
>> > wrote:
>>
>> Yep, those warnings really should be considered. BTST :)
>>
>>
>>
>> Ralph.
>>
>>
>>
>> *From:* Marcus M?ller [mailto:]
>> *Sent:* Tuesday, February 17, 2:19 PM
>> *To:* Ralph A. Schmid, dk5ras; 'usrp-users'
>>
>>
>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>
>>
>>
>> Hey Ralph,
>>
>> glueing in the connector at the old position sounds like a solution for
>> the "where to actually connect the external power supply" problem that I
>> haven't tackled :)
>> Two words of warning:
>> 1) ripping out might have damaged isolation, so make sure you don't
>> accidentally glue the connector in in a way that shorts the positive pins
>> to ground; clearance between the supply voltage pads and the ground plane
>> is rather small, both carrying low voltage.
>> 2) when using a cable, make triple sure board edges don't scratch of
>> isolation. That usually gives you the kind of short circuit that -- in the
>> best case -- kills your power supply, but might fry your PCB if the
>> resulting current melts the cable, which then flies around, and touches
>> anything that doesn't like the voltage (been there, done that with PCB
>> designs of my own).
>>
>> Greetings,
>> Marcus
>>
>> On 02/17/ 02:05 PM, Ralph A. Schmid, dk5ras wrote:
>>
>> I would glue the connector in place again, and then connect both ground
>> and + with thin (!) wires (enameled copper wire, 0.1mm or so) to the
>> positions where they belong, not circumventing any filtering. So this would
>> ground, and be F100 or the connection between L600 and C601. Using thin
>> wires will increase chances that the board will survive a second incident
>> of this kind. I had to do this with the Nuand BladeRF MicroUSB3.0
>> connector. After having it all in place I sealed the surroundings with
>> two-component epoxy glue.
>>
>>
>>
>> I can send photos later this day if anyone is interested.
>>
>>
>>
>> Those SMD mounted external connectors are really a PITA, I wish they all
>> were good old through hole mount, what is more durable and usually easier
>> to repair when damaged.
>>
>>
>>
>> Ralph.
>>
>>
>>
>> *From:* USRP-users [mailto:
>> <>] *On Behalf Of *Marcus M?ller via
>> USRP-users
>> *Sent:* Tuesday, February 17, 11:54 AM
>> *To:*
>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>
>>
>>
>> Hi Soumen,
>>
>> Disclaimer first: this is not an official maintenance/repair instruction,
>> but just a description of what I see in your photo:
>> The fall broke off a large chunk of ground plane, along with the pads
>> that connect the power supply ground. Whilst this is ugly, I think it won't
>> fatally damage your B210; you'll just have to find another suitable ground
>> connection to attach your supply's ground to. I'm happy that the power
>> connector is the only thing that seems to have taken damage :)
>>
>> Worse is that it cleanly pulled the positive pads of your board; there's
>> no way you'll be able to re-solder the connector to the same position.
>> Having a look at the B210/B200 schematics [1], you'll notice that there
>> is T600, which you *could* directly feed with external supply voltage, but
>> I'd like to point out that you'd lose all power "sanitation" that happens
>> between J601 and T600, which is a bad thing.
>>
>> You could either duplicate the protection/hf choke/capacitor buffering
>> circuit consisting of F100, L601 and C600-C602 and attach the output as
>> directly as possible to T600, or you could locate the input side of F100
>> and try to solder on a cable that you then might connect to your power
>> supply somehow.
>> The first option is more complicated, but attaching power to a test
>> point/pin header hole might be much more reliable than trying to solder
>> something to a package, and reliability of power is possibly the cause
>> you'd want to use an external power supply in the first place. You could
>> also try to do a compromise: solder a lead to the F100-side of L601 (which
>> is much much larger), and use your own 4A fast response fuse. I really like
>> the Ettus hardware, so I'd ask you not to use an external power supply
>> without a fuse.
>>
>> Best regards, and I hope your board gets well soon,
>> Marcus
>>
>> [1] http://files.ettus.com/schematics/
>>
>> On 02/17/ 11:18 AM, Soumen Banerjee via USRP-users wrote:
>>
>> Hi,
>>
>> The board fell off the table and the power port has come off the board.
>> Can this be fixed in any way? I've attached an image of the board to the
>> .
>>
>>
>>
>> Thanks,
>>
>> Soumen
>>
>>
>>
>>
>> _______________________________________________
>>
>> USRP-users mailing list
>>
>>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CloseUp.jpg
Type: image/jpeg
Size: bytes
Desc: not available
URL:
------------------------------
Message: 20
Date: Wed, 18 Feb 10:45:31 +
From: Khalid Jamil <>
To:
Subject: [USRP-users] Calibration: IQ imbalance and DC offset
Message-ID:
Content-Type: text/plain; charset="utf-8"
Hi,
I was wondering if anyone knows how to calibrate X310 for IQ imbalance and
DC offset. And how to apply these calibration coefficients inside the FPGA.
Thanks
Khalid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 21
Date: Wed, 18 Feb 13:01:31 +
From: Marcus M?ller <>
To: Soumen Banerjee <>
Cc: "" <>
Subject: Re: [USRP-users] B210 Power Port broken - can this be fixed?
Message-ID: <>
Content-Type: text/plain; charset="windows-"
Hi Soumen,
yes, that end looks fine; notice the little trace that runs from the pad
of L601 straight down to F100 in your photo.
Greetings,
Marcus
On 02/18/ 04:47 AM, Soumen Banerjee wrote:
> Hi,
>
> In addition, did I mark the correct end of L601 in my picture? I dont
> want to end up soldering on the wrong end if I can help it :) Ive
> attached it again for reference. Once Im sure on this one(and the
> choice of fuse), I'd just go ahead and try to make this work by using
> my own fuse with it.
>
> Would the status light glow a different color on external power? I
> mostly use it on bus power, so I dont know if there is a different
> color. I found a description for the green version of the board though
> and it mentioned that it glows green on external power. Does that hold
> for my(white) board as well?
>
> Regards,
> Soumen
>
> On Tue, Feb 17, at 8:55 PM, Soumen Banerjee <
> > wrote:
>
> Hi,
> Im not sure how to procure the fuse you mention in India. Can I
> use another fuse with the 4 amp rating? Does the fast action
> matter a whole lot? Perhaps I could use a lower rating, say 2A and
> get away with it?
> Regards,
> Soumen
>
> On 17-Feb- 8:28 pm, "Ralph A. Schmid, dk5ras"
> <> wrote:
>
> A fuse is always a good idea, mostly against a wrong power
> supply with excessive voltage or reversed polarity.
>
>
>
> Ralph.
>
>
>
> *From:*Marcus M?ller [mailto:
> ]
> *Sent:* Tuesday, February 17, 3:49 PM
> *To:* Soumen Banerjee; Ralph A. Schmid, dk5ras
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] B210 Power Port broken - can this
> be fixed?
>
>
>
> Hi Soumen,
>
> the idea that you could glue back the connector in place was
> really just about the connector having a place to sit. The
> positive contacts can't be saved.
>
> I'd have to stick with Sylvain here (sorry, Ralph), but the
> wire shouldn't be very thin. But yes, the idea is to lead the
> current from the connetor through a fuse to L601. Now, F100 is
> the right fuse to do that, but it's so tiny that you'll have a
> hard time soldering any cable to it, no matter how thin, thus
> my approach to use your own fuse, and solder to L601 directly.
>
> Regarding why F100 is there:
> a) it's an external power supply. You simply protect such
> inputs by principle alone :)
> b) Whilst you're right, and a blown fuse would usually be
> related to a rather drastic board failure somewhere else, it
> still protects the board -- for example, anything that falls
> onto the board might shorten supply voltage to ground, which
> would destroy the PCB, if it wasn't for the fuse. Also, the
> power converter semiconductors, inductors and capacitors are
> designed with quite a bit of headroom, if the overload
> situation doesn't last too long or doesn't exceed a certain
> voltage.
>
> Greetings,
> Marcus
>
> On 02/17/ 03:16 PM, Soumen Banerjee wrote:
>
> Hi,
>
>
>
> The ground pad is actually available on the board. It is
> the positive pads that have been ripped off.
>
>
>
> I'm a little unsure of what you guys are suggesting with
> respect to glueing the power jack back onto the board. If
> I did that, I could easily re-establish the connection
> with the ground pad but Im not sure about the positive
> pad. Are you suggesting I take a thin lead out of the
> power jack, and solder it before the F100? The F100 is so
> small, Im not sure that can be done with a micro-tip
> soldering iron. If you are suggesting something else, I
> could use a little further clarification.
>
>
>
> Also, I was wondering why we have the fuse at all. If the
> fuse were to get blown, wouldnt it mean that the board
> was, for all intents and purposes fried? Unless of course
> if the fuse is replaceable. Is it?
>
>
>
> Regards,
>
> Soumen
>
>
>
> On Tue, Feb 17, at 7:00 PM, Ralph A. Schmid, dk5ras
> via USRP-users <
> > wrote:
>
> Yep, those warnings really should be considered. BTST :)
>
>
>
> Ralph.
>
>
>
> *From:*Marcus M?ller [mailto:
> ]
> *Sent:* Tuesday, February 17, 2:19 PM
> *To:* Ralph A. Schmid, dk5ras; 'usrp-users'
>
>
> *Subject:* Re: [USRP-users] B210 Power Port broken -
> can this be fixed?
>
>
>
> Hey Ralph,
>
> glueing in the connector at the old position sounds
> like a solution for the "where to actually connect the
> external power supply" problem that I haven't tackled :)
> Two words of warning:
> 1) ripping out might have damaged isolation, so make
> sure you don't accidentally glue the connector in in a
> way that shorts the positive pins to ground; clearance
> between the supply voltage pads and the ground plane
> is rather small, both carrying low voltage.
> 2) when using a cable, make triple sure board edges
> don't scratch of isolation. That usually gives you the
> kind of short circuit that -- in the best case --
> kills your power supply, but might fry your PCB if the
> resulting current melts the cable, which then flies
> around, and touches anything that doesn't like the
> voltage (been there, done that with PCB designs of my
> own).
>
> Greetings,
> Marcus
>
> On 02/17/ 02:05 PM, Ralph A. Schmid, dk5ras wrote:
>
> I would glue the connector in place again, and
> then connect both ground and + with thin (!) wires
> (enameled copper wire, 0.1mm or so) to the
> positions where they belong, not circumventing any
> filtering. So this would ground, and be F100 or
> the connection between L600 and C601. Using thin
> wires will increase chances that the board will
> survive a second incident of this kind. I had to
> do this with the Nuand BladeRF MicroUSB3.0
> connector. After having it all in place I sealed
> the surroundings with two-component epoxy glue.
>
>
>
> I can send photos later this day if anyone is
> interested.
>
>
>
> Those SMD mounted external connectors are really a
> PITA, I wish they all were good old through hole
> mount, what is more durable and usually easier to
> repair when damaged.
>
>
>
> Ralph.
>
>
>
> *From:*USRP-users
> [mailto:] *On
> Behalf Of *Marcus M?ller via USRP-users
> *Sent:* Tuesday, February 17, 11:54 AM
> *To:*
>
> *Subject:* Re: [USRP-users] B210 Power Port broken
> - can this be fixed?
>
>
>
> Hi Soumen,
>
> Disclaimer first: this is not an official
> maintenance/repair instruction, but just a
> description of what I see in your photo:
> The fall broke off a large chunk of ground plane,
> along with the pads that connect the power supply
> ground. Whilst this is ugly, I think it won't
> fatally damage your B210; you'll just have to find
> another suitable ground connection to attach your
> supply's ground to. I'm happy that the power
> connector is the only thing that seems to have
> taken damage :)
>
> Worse is that it cleanly pulled the positive pads
> of your board; there's no way you'll be able to
> re-solder the connector to the same position.
> Having a look at the B210/B200 schematics [1],
> you'll notice that there is T600, which you
> *could* directly feed with external supply
> voltage, but I'd like to point out that you'd lose
> all power "sanitation" that happens between J601
> and T600, which is a bad thing.
>
> You could either duplicate the protection/hf
> choke/capacitor buffering circuit consisting of
> F100, L601 and C600-C602 and attach the output as
> directly as possible to T600, or you could locate
> the input side of F100 and try to solder on a
> cable that you then might connect to your power
> supply somehow.
> The first option is more complicated, but
> attaching power to a test point/pin header hole
> might be much more reliable than trying to solder
> something to a package, and reliability of
> power is possibly the cause you'd want to use an
> external power supply in the first place. You
> could also try to do a compromise: solder a lead
> to the F100-side of L601 (which is much much
> larger), and use your own 4A fast response fuse. I
> really like the Ettus hardware, so I'd ask you not
> to use an external power supply without a fuse.
>
> Best regards, and I hope your board gets well soon,
> Marcus
>
> [1] http://files.ettus.com/schematics/
>
> On 02/17/ 11:18 AM, Soumen Banerjee via
> USRP-users wrote:
>
> Hi,
>
> The board fell off the table and the power
> port has come off the board. Can this be fixed
> in any way? I've attached an image of the
> board to the .
>
>
>
> Thanks,
>
> Soumen
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
>
>
>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
>
>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 22
Date: Wed, 18 Feb 14:53:00 +
From: ffellner <>
To: <>
Subject: [USRP-users] USRP N210+WBX: Problem to receive GPS-Signal in
MATLAB/Simulink
Message-ID: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello,
I have problem to receive any GPS-Signal with the USRP N210.
I would like store the baseband GPS signal with a sample frequency of
5MHz.
An active antenna is connected to RF1. On the computer (Win7 SP1) is
following installed:
* MATLAB: 8.3.0.532 (Ra)
* Communications System Toolbox: Version 5.6
* DSP System Toolbox: Version 8.6
* Signal Processing Toolbox: Version 6.21
Now I?m using the Simulink Block ?SDRu Receiver? with these Parameters:
*USRP IP address 192.168.10.2
*Centerfrequency (Hz) 1.e9
*LO offset (Hz): 0
*Gain (dB): 32
*Decimation: 20
*Not Enable overrun output port
*Sample Time: 1/5e6
*Output data type: double
*Frame length:
*Buffering: Not Enable burst mode
Indicating device values are same, except with LO offset (-.09). Is
this normal?
When I open the Simulink-Receiver I get a variable called ?monoFM? in
the Workspace of Matlab.
I tried to track satellites with the MATLAB script of the book ?A
Software-Defined GPS and Galileo Receiver? and with GNSS-SDR (UNIX).
With GnuRadio I managed to record GPS signals and evaluating
successful.
Is there an mistakes in the settings from Simulink-Receiver?
Thanks,
Ferdinand
------------------------------
Message: 23
Date: Wed, 18 Feb 19:43:15 +
From: Soumen Banerjee <>
To: Marcus M?ller <>
Cc: "" <>
Subject: Re: [USRP-users] B210 Power Port broken - can this be fixed?
Message-ID:
<>
Content-Type: text/plain; charset="iso--1"
Thanks a lot guys. I'm going to try putting this together right away and
see if it works.
Regards,
Soumen
On 18-Feb- 5:31 pm, "Marcus M?ller" <> wrote:
> Hi Soumen,
>
> yes, that end looks fine; notice the little trace that runs from the pad
> of L601 straight down to F100 in your photo.
>
> Greetings,
> Marcus
>
>
> On 02/18/ 04:47 AM, Soumen Banerjee wrote:
>
> Hi,
>
> In addition, did I mark the correct end of L601 in my picture? I dont
> want to end up soldering on the wrong end if I can help it :) Ive attached
> it again for reference. Once Im sure on this one(and the choice of fuse),
> I'd just go ahead and try to make this work by using my own fuse with it.
>
> Would the status light glow a different color on external power? I
> mostly use it on bus power, so I dont know if there is a different color. I
> found a description for the green version of the board though and it
> mentioned that it glows green on external power. Does that hold for
> my(white) board as well?
>
> Regards,
> Soumen
>
> On Tue, Feb 17, at 8:55 PM, Soumen Banerjee <>
> wrote:
>
>> Hi,
>> Im not sure how to procure the fuse you mention in India. Can I use
>> another fuse with the 4 amp rating? Does the fast action matter a whole
>> lot? Perhaps I could use a lower rating, say 2A and get away with it?
>> Regards,
>> Soumen
>> On 17-Feb- 8:28 pm, "Ralph A. Schmid, dk5ras" <>
>> <> wrote:
>>
>>> A fuse is always a good idea, mostly against a wrong power supply with
>>> excessive voltage or reversed polarity.
>>>
>>>
>>>
>>> Ralph.
>>>
>>>
>>>
>>> *From:* Marcus M?ller [mailto:]
>>> *Sent:* Tuesday, February 17, 3:49 PM
>>> *To:* Soumen Banerjee; Ralph A. Schmid, dk5ras
>>> *Cc:* usrp-users
>>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>>
>>>
>>>
>>> Hi Soumen,
>>>
>>> the idea that you could glue back the connector in place was really just
>>> about the connector having a place to sit. The positive contacts can't be
>>> saved.
>>>
>>> I'd have to stick with Sylvain here (sorry, Ralph), but the wire
>>> shouldn't be very thin. But yes, the idea is to lead the current from the
>>> connetor through a fuse to L601. Now, F100 is the right fuse to do that,
>>> but it's so tiny that you'll have a hard time soldering any cable to it, no
>>> matter how thin, thus my approach to use your own fuse, and solder to L601
>>> directly.
>>>
>>> Regarding why F100 is there:
>>> a) it's an external power supply. You simply protect such inputs by
>>> principle alone :)
>>> b) Whilst you're right, and a blown fuse would usually be related to a
>>> rather drastic board failure somewhere else, it still protects the board --
>>> for example, anything that falls onto the board might shorten supply
>>> voltage to ground, which would destroy the PCB, if it wasn't for the fuse.
>>> Also, the power converter semiconductors, inductors and capacitors are
>>> designed with quite a bit of headroom, if the overload situation doesn't
>>> last too long or doesn't exceed a certain voltage.
>>>
>>> Greetings,
>>> Marcus
>>>
>>> On 02/17/ 03:16 PM, Soumen Banerjee wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> The ground pad is actually available on the board. It is the positive
>>> pads that have been ripped off.
>>>
>>>
>>>
>>> I'm a little unsure of what you guys are suggesting with respect to
>>> glueing the power jack back onto the board. If I did that, I could easily
>>> re-establish the connection with the ground pad but Im not sure about the
>>> positive pad. Are you suggesting I take a thin lead out of the power jack,
>>> and solder it before the F100? The F100 is so small, Im not sure that can
>>> be done with a micro-tip soldering iron. If you are suggesting something
>>> else, I could use a little further clarification.
>>>
>>>
>>>
>>> Also, I was wondering why we have the fuse at all. If the fuse were to
>>> get blown, wouldnt it mean that the board was, for all intents and purposes
>>> fried? Unless of course if the fuse is replaceable. Is it?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Soumen
>>>
>>>
>>>
>>> On Tue, Feb 17, at 7:00 PM, Ralph A. Schmid, dk5ras via USRP-users <
>>> > wrote:
>>>
>>> Yep, those warnings really should be considered. BTST :)
>>>
>>>
>>>
>>> Ralph.
>>>
>>>
>>>
>>> *From:* Marcus M?ller [mailto:]
>>> *Sent:* Tuesday, February 17, 2:19 PM
>>> *To:* Ralph A. Schmid, dk5ras; 'usrp-users'
>>>
>>>
>>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>>
>>>
>>>
>>> Hey Ralph,
>>>
>>> glueing in the connector at the old position sounds like a solution for
>>> the "where to actually connect the external power supply" problem that I
>>> haven't tackled :)
>>> Two words of warning:
>>> 1) ripping out might have damaged isolation, so make sure you don't
>>> accidentally glue the connector in in a way that shorts the positive pins
>>> to ground; clearance between the supply voltage pads and the ground plane
>>> is rather small, both carrying low voltage.
>>> 2) when using a cable, make triple sure board edges don't scratch of
>>> isolation. That usually gives you the kind of short circuit that -- in the
>>> best case -- kills your power supply, but might fry your PCB if the
>>> resulting current melts the cable, which then flies around, and touches
>>> anything that doesn't like the voltage (been there, done that with PCB
>>> designs of my own).
>>>
>>> Greetings,
>>> Marcus
>>>
>>> On 02/17/ 02:05 PM, Ralph A. Schmid, dk5ras wrote:
>>>
>>> I would glue the connector in place again, and then connect both ground
>>> and + with thin (!) wires (enameled copper wire, 0.1mm or so) to the
>>> positions where they belong, not circumventing any filtering. So this would
>>> ground, and be F100 or the connection between L600 and C601. Using thin
>>> wires will increase chances that the board will survive a second incident
>>> of this kind. I had to do this with the Nuand BladeRF MicroUSB3.0
>>> connector. After having it all in place I sealed the surroundings with
>>> two-component epoxy glue.
>>>
>>>
>>>
>>> I can send photos later this day if anyone is interested.
>>>
>>>
>>>
>>> Those SMD mounted external connectors are really a PITA, I wish they all
>>> were good old through hole mount, what is more durable and usually easier
>>> to repair when damaged.
>>>
>>>
>>>
>>> Ralph.
>>>
>>>
>>>
>>> *From:* USRP-users [mailto:
>>> <>] *On Behalf Of *Marcus M?ller via
>>> USRP-users
>>> *Sent:* Tuesday, February 17, 11:54 AM
>>> *To:*
>>> *Subject:* Re: [USRP-users] B210 Power Port broken - can this be fixed?
>>>
>>>
>>>
>>> Hi Soumen,
>>>
>>> Disclaimer first: this is not an official maintenance/repair
>>> instruction, but just a description of what I see in your photo:
>>> The fall broke off a large chunk of ground plane, along with the pads
>>> that connect the power supply ground. Whilst this is ugly, I think it won't
>>> fatally damage your B210; you'll just have to find another suitable ground
>>> connection to attach your supply's ground to. I'm happy that the power
>>> connector is the only thing that seems to have taken damage :)
>>>
>>> Worse is that it cleanly pulled the positive pads of your board; there's
>>> no way you'll be able to re-solder the connector to the same position.
>>> Having a look at the B210/B200 schematics [1], you'll notice that there
>>> is T600, which you *could* directly feed with external supply voltage, but
>>> I'd like to point out that you'd lose all power "sanitation" that happens
>>> between J601 and T600, which is a bad thing.
>>>
>>> You could either duplicate the protection/hf choke/capacitor buffering
>>> circuit consisting of F100, L601 and C600-C602 and attach the output as
>>> directly as possible to T600, or you could locate the input side of F100
>>> and try to solder on a cable that you then might connect to your power
>>> supply somehow.
>>> The first option is more complicated, but attaching power to a test
>>> point/pin header hole might be much more reliable than trying to solder
>>> something to a package, and reliability of power is possibly the cause
>>> you'd want to use an external power supply in the first place. You could
>>> also try to do a compromise: solder a lead to the F100-side of L601 (which
>>> is much much larger), and use your own 4A fast response fuse. I really like
>>> the Ettus hardware, so I'd ask you not to use an external power supply
>>> without a fuse.
>>>
>>> Best regards, and I hope your board gets well soon,
>>> Marcus
>>>
>>> [1] http://files.ettus.com/schematics/
>>>
>>> On 02/17/ 11:18 AM, Soumen Banerjee via USRP-users wrote:
>>>
>>> Hi,
>>>
>>> The board fell off the table and the power port has come off the board.
>>> Can this be fixed in any way? I've attached an image of the board to the
>>> .
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Soumen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> USRP-users mailing list
>>>
>>>
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 24
Date: Wed, 18 Feb 14:14:07 +
From: Mike McLernon <>
To: ffellner <>
Cc: "" <>
Subject: Re: [USRP-users] USRP N210+WBX: Problem to receive GPS-Signal
in MATLAB/Simulink
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
Hi Ferdinand,
The reported LO offset value is not a sign of a problem. Sometimes that value
is nonzero if it is needed to achieve your requested center frequency.
The 'monoFM' variable is a structure that is used to drive the mono FM example
in MATLAB or Simulink. Did you run that example prior to doing your GPS work?
What behavior did you see in the Simulink model when you tried to capture the
GPS signal?
Best,
Mike
-----Original Message-----
From: USRP-users [mailto:] On Behalf Of
ffellner via USRP-users
Sent: Wednesday, February 18, 8:53 AM
To:
Subject: [USRP-users] USRP N210+WBX: Problem to receive GPS-Signal in
MATLAB/Simulink
Hello,
I have problem to receive any GPS-Signal with the USRP N210.
I would like store the baseband GPS signal with a sample frequency of 5MHz.
An active antenna is connected to RF1. On the computer (Win7 SP1) is following
installed:
* MATLAB: 8.3.0.532 (Ra)
* Communications System Toolbox: Version 5.6
* DSP System Toolbox: Version 8.6
* Signal Processing Toolbox: Version 6.21
Now I?m using the Simulink Block ?SDRu Receiver? with these Parameters:
*USRP IP address 192.168.10.2
*Centerfrequency (Hz) 1.e9
*LO offset (Hz): 0
*Gain (dB): 32
*Decimation: 20
*Not Enable overrun output port
*Sample Time: 1/5e6
*Output data type: double
*Frame length:
*Buffering: Not Enable burst mode
Indicating device values are same, except with LO offset (-.09). Is this
normal?
When I open the Simulink-Receiver I get a variable called ?monoFM? in the
Workspace of Matlab.
I tried to track satellites with the MATLAB script of the book ?A
Software-Defined GPS and Galileo Receiver? and with GNSS-SDR (UNIX).
With GnuRadio I managed to record GPS signals and evaluating successful.
Is there an mistakes in the settings from Simulink-Receiver?
Thanks,
Ferdinand
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 25
Date: Wed, 18 Feb 10:12:01 -
From: "Marcus D. Leech" <>
To:
Subject: Re: [USRP-users] Calibration: IQ imbalance and DC offset
Message-ID: <>
Content-Type: text/plain; charset="iso--1"; Format="flowed"
On 02/18/ 02:45 AM, Khalid Jamil via USRP-users wrote:
>
> Hi,
>
> I was wondering if anyone knows how to calibrate X310 for IQ imbalance
> and DC offset. And how to apply these calibration coefficients inside
> the FPGA.
>
> Thanks
>
> Khalid.
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Use:
uhd_cal_rx_iq_balance
uhd_cal_tx_iq_balance
uhd_cal_tx_dc_offset
The resulting coefficients will be stored in ~/.uhd arranged by serial
number of the daughterboard being calibrated.
By default, UHD will lookup these coefficients and apply them when you
open a session to the card.
http://files.ettus.com/manual/page_calibration.html#calibration_self
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 26
Date: Wed, 18 Feb 07:45:43 -
From: Johnathan Corgan <>
To: "" <>
Subject: [USRP-users] Corgan Labs Expands Offering with Public and
Advanced Courses
Message-ID: <>
Content-Type: text/plain; charset="utf-8"
View this in your browser
Corgan Labs, a leading provider of SDR training and consulting
solutions, and a preferred partner of Ettus Research, is proud to
announce expanded course offerings. These courses are built upon
methods that are proven to make users more productive with GNU Radio and
USRP products quickly. Our new offerings include:
Public Course - Introduction to SDR with GNU Radio and USRP
Corgan Labs will be hosting several two-day introductory courses, which
are ideal for individuals or small teams that are new to GNU Radio.
Each attendee will receive a USRP B200
that will be used for
hands-on lessons during the course.
* US East Coast - Reston, VA, 26th March
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: bytes
Desc: not available
URL:
------------------------------
Message: 27
Date: Wed, 18 Feb 16:49:05 +
From: Martin Braun <>
To:
Subject: Re: [USRP-users] UHD Driver behavior
Message-ID: <>
Content-Type: text/plain; charset=windows-
On 02/18/ 01:59 AM, Thierry Guichon via USRP-users wrote:
> Hello,
>
> I am interested to better understand the interaction between the IQ
> packets received on the line (between the FPGA and the host) and the
> buffer that the application provides to the driver.
>
> Does the UHD driver buffers data until the user provides a buffer? If
> yes, how big is that buffer?
>
> After the rx_stream->recv function returns, how long can the user wait
> before providing another buffer?
Let me just add some info to what Phil and Marcus have said:
For flow control reasons, we 'define' a kernel buffer size when the RX
streamers are created. Depending on the device, you can actually
influence that size using the 'recv_frame_size' parameter (see the
transport notes manual page:
http://files.ettus.com/manual/page_transport.html). As Marcus points
out, this is all very device-dependent.
When you empty your buffer, flow control info is sent back to the FPGA
-- this way, the device always knows how much space there is left in the
host buffer.
When your app is too slow emptying the buffer, the device will stop
producing samples when this buffer is full -- that's when you see the
"O"s on your output.
M
------------------------------
Message: 28
Date: Wed, 18 Feb 16:57:38 +
From: Martin Braun <>
To:
Subject: Re: [USRP-users] Question on set_rx_bandwidth
Message-ID: <>
Content-Type: text/plain; charset=windows-
Just to be sure we're all on the same page here:
- *_rx_bandwidth() currently do nothing useful, but will do so soon
- Until then, the actual analog bandwidth is not changed when you use
these calls
- When you change the sampling rate, it auto-selects a *clock rate*.
The analog bandwidth is still unchanged.
Note this is a feature on master, but not on maint (i.e. in the stable
releases)
Cheers,
M
On 02/17/ 07:21 PM, Dario Fertonani via USRP-users wrote:
> Thank you Ian. I didn't realize that, despite the value returned
> by get_rx_bandwidth being constant, the actual bandwidth changes
> according to the requested sampling rate.
>
> Best regards,
> Dario
>
> On Tue, Feb 17, at 10:14 AM, Ian Buckley <
> > wrote:
>
> (On B210) Currently set_rx_bandwidth/get_rx_bandwidth is a stubbed
> out API call that as you spotted does nothing useful. The underlying
> driver code sets the analog baseband filters to a bandwidth thats
> appropriate for the full potential bandwidth of your sample rate,
> attenuating power in adjacent channels (RX) and removing converter
> aliasing (TX).
>
> There is currently code in development/review that fully implements
> the set_rx_bandwidth API call so that users can override these
> default settings of the analog filters and reduce the filter
> bandwidth further, but most users will not need this functionality
> except in very demanding and unusual applications. There are people
> doing LTE and meeting ACLR etc requirements already just through the
> many stages of digital filtering so I wouldn't be over concerned.
>
> -Ian
>
> On Feb 17, , at 9:50 AM, Dario Fertonani via USRP-users
> < > wrote:
>
>> My Ettus board is the B210 model. On the host PC I'm using UHD
>> built from source, all running on Ubuntu 14.10 low latency.
>>
>> With the UHD version from Git (UHD_003.008.002-80-ge28d), I am
>> able to set the desired carrier frequency and sampling rate
>> with set_rx_freq and set_rx_rate. The same is not true for the
>> Ubuntu-packaged version, which somehow rounds those values to
>> master-clock-friendly values.
>>
>> On the other hand, the call to set_rx_bandwidth seems to be
>> ignored by the board, since get_rx_bandwidth always returns 56
>> MHz. I did check that the requested value is within the range
>> returned by get_rx_bandwidth_range.
>> In case it matters, the values of interest here are LTE values
>> such as a 739 MHz carrier, a 15.36 MHz sampling rate and a
>> bandwidth somewhat below 15.36 MHz. Reading 56 MHz for a signal
>> sampled at 15.36 MHz makes me worried. Anything I'm missing?
>>
>> Thanks,
>> Dario
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 54, Issue 18
******************************************
> You can do that (obviously, it works!), but I'd recommend you just use
> a channelizer with N=125 instead of 117! Your channel map can be used
> to ignore the channels you don't need (which seem to be the 4 upper and
> lower "edge" ones), and by only increasing the workload of the PFB ever
> so slightly (probably even actually decreasing it, because an 125=5³-
> FFT is likely to be much more efficient than an 117=3²·13-FFT), you get
> rid of the rational resampler, which not only brings more CPU load, but
> also a resampling filter response that might have ripple and aliases.
With competitive price and timely delivery, Highmesh sincerely hope to be your supplier and partner.
Thanks for that suggestion, Marcus! I have the resampler version
running right now but will change to use the channel count idea instead.
John
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
First, thanks for catching the typo in the channel map. There was no
plan to skip any channels; the goal is to get each channel in frequency
order (out0 = 540 kHz; out116 = kHz).
I did an experiment using a signal generator feeding the Red Pitaya
receiver and testing various channels. I started at the center channel,
kHz, and found there was zero offset from nominal. I then went 1,
2, and 3 channels both lower and higher and came up with this map:
+2.05 kHz
+1.37 kHz
+0.68 kHz
0.00 kHz
-0.68 kHz
-1.37 kHz
-2.05 kHz
If you want to learn more, please visit our website HM USRP B Series.
Now, the sample rate coming out of the channelizer (hardware sample rate
of 1.25 msps divided by 117) is ~10.683 ksps. Gee, that 683 is pretty
close to the per-channel offset.
I didn't test further, but I strongly suspect this offset of ~680
Hz/channel continues in both directions, so that the signal has moved
far from the expected point as you get further away.
So, I think this tells me that the sample rate going into the PFB,
divided by the number of channels, needs to match the channel spacing.
That means a rational resampler going into the PFB to change 1.25 msps
to 1.17 msps.
I don't think I've ever read anything before that the sample_in rate has
to equal (channel_num x channel_spacing). It makes perfect sense when
you think about it, though. Your reference to the "channel raster" was
enough to make the light bulb turn on for me, and thanks very much for that!
Now to test with the resampler... Thanks much for helping me work
through this!
John
----
On 11/29/ 01:20 PM, Müller, Marcus (CEL) wrote:
> Hi John,
>
> given the fact that the frequency shifting of the individual sub-
> filters is actually done via a DFT implemented by an FFT, and that
> should have negligible phase accumulation error for benign FFT length
> (i.e. channel numbers, let's say <1e6), hm.
>
> First gut feeling, and easiest to check:
>
>> The output channels seem to have an offset in the range > of 400 to
> 700 Hz versus the unchannelized input.
>
> Make double sure that (sampling rate going into the channelizer) / 117
> is actually exactly the raster you want.
>
> If I interpret your file correctly, there's 1.25 MHz going into the
> channelizer, so channel raster is / 117 kHz = 10.684 kHz. Hope
> that's right!
>
> What I could imagine are artifacts due to the non-perfect filter phase
> linearity; but that would actually be a pretty intense speculation;
> unless we're leaving the areas where our floating point numbers are
> accurate enough, there shouldn't be non-linear (i.e. frequency-
> shifting) behaviour.
>
> I just threw together this:
>
> from gnuradio.filter import firdes
>
> file_sample_rate = 2.5e6
> decimation = 2
>
> pfb_taps = firdes.low_pass(2.0, file_sample_rate/decimation,,,
> firdes.WIN_HAMMING, 6.76)
>
> (pretty much lifted straight from your GRC)
>
> Inspecting pfb_taps yielded a length of 603 taps, which we'll "evenly
> as possible" have to distribute across the channels (117 of which
> exist, as your channelizer map has length 116, but is missing the 56).
>
> You could build a simple "unit test": Use a Vector source that pushes
>
> [1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 4 … 0 0 0 0 0 0 0 117
> 0 0 0 0 0 0 0 ]
>
> through a length=117*8 IFFT, and push the result (after a vector-to-
> stream) through your channelizer. You should see single tones in all
> your channels. (The different amplitudes might help telling them
> apart). Do they end up in the center of your bins?
>
> Best regards,
> Marcus
>
> On Wed, -11-29 at 10:34 -, John Ackermann N8UR wrote:
>> I'm building a ridiculous flowgraph that breaks the AM broadcast band
>> (540 - kHz in the U.S.) into 117 10 kHz wide channels and measures
>> the energy in each. The thing is working but I see a frequency offset
>> in the output channels that is not present in the data before
>> channelizing. The output channels seem to have an offset in the range
>> of 400 to 700 Hz versus the unchannelized input.
>>
>> The signal chain is:
>>
>> 2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
>> output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
>> a channel rate of 10,683....... samples per second.
>>
>> Looking at the spectrum at the output of the xlating filter, the carrier
>> frequencies are correct. Looking at the output of a channel, the
>> carriers are offset by several hundred Hertz, always high. (Given the
>> absolute frequency is in the 1 MHz range, these offsets are parts in
>> 1e3, a pretty large amount.)
>>
>> I wonder if the large number of PFB channels is causing a rounding error
>> that results in these frequency offsets. Or is there something else
>> going on?
>>
>> I can probably fudge the xlating filter frequency a bit to move the
>> carriers closer to nominal, but would like to understand what's happening.
>>
>> I'm attaching the (absurdly huge) .grc file. The canvas is pixels
>> tall, so the flowgraph is smaller than the screenshot. :-)
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If you are looking for more details, kindly visit Universal Software Radio Peripheral USRP.