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. X300 issue. (Robert McGwier via USRP-users)
2. Re: Mis-aligned data on B210 RX channels (Tom Tsou via USRP-users)
3. Re: X300 issue. (Mike Jameson via USRP-users)
4. Re: X300 issue. (Ashish Chaudhari via USRP-users)
5. Re: X300 issue. (Robert McGwier via USRP-users)
6. Re: Mis-aligned data on B210 RX channels
(Robert Kossler via USRP-users)
7. Re: B210 channel assignment (Robert Kossler via USRP-users)
8. Re: B210 channel assignment (Robert Kossler via USRP-users)
9. B210 (Dmitry Dmitry via USRP-users)
10. Re: B210 (Ian Buckley via USRP-users)
11. Re: B210 (Dmitry via USRP-users)
12. Re: Changing the USRP N210 FPGA clock frequency
(Matt Ettus via USRP-users)
13. Re: B210 channel assignment (Robert Kossler via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 May 2014 07:36:10 -0400
From: Robert McGwier via USRP-users <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>, Tim
O'Shea <[email protected]>
Subject: [USRP-users] X300 issue.
Message-ID:
<ca+k5gzdapefqycg_fx2nxbjrypp9wncnjfgm_tqfgzjyzji...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: x300
addr: 192.168.10.2
fpga: HGS
name:
serial: F4D29E
product: X300
n4hy@n4hy-FW:~/target/lib/uhd/utils$ usrp_x3xx_fpga_burner
--addr=192.168.10.2
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
Attempting to find X3x0 with IP address: 192.168.10.2
Found X300 (HGS).
Burning image: /home/n4hy/target/share/uhd/images/usrp_x300_fpga_HGS.bit
Progress: 100% (87/87 sectors)
(cold start reboot)
n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: x300
addr: 192.168.10.2
fpga: HGS
name:
serial: F4D29E
product: X300
trying to set IP address to 192.168.10.3
n4hy@n4hy-FW:~/target/lib/uhd/utils$ ./usrp_burn_mb_eeprom
--key=192.168.10.2 --val=192.168.10.3
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
Creating USRP device from address:
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Sync DAC's.
-- Performing register loopback test... pass
-- Sync DAC's.
-- Initializing clock and PPS references...
-- References initialized to internal sources
WARNING: Use of --key and --val is deprecated!
Fetching current settings from EEPROM...
Cannot find value for EEPROM[192.168.10.2]
And the IP address isn't changed.
I am sure I am doing something dumb. What is it?
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/1b93066a/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 20 May 2014 12:30:59 -0400
From: Tom Tsou via USRP-users <[email protected]>
To: Robert Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Mis-aligned data on B210 RX channels
Message-ID:
<CAATyM+ZHO=3o7L+NC-OoSA7GMcQpFBhUH5q_LxE9A=dn0ph...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, May 7, 2014 at 5:28 PM, Robert Kossler via USRP-users
<[email protected]> wrote:
> I am using a B210 to collect data from 2 RX channels simultaneously and
> saving the results to file (using a modified program based on
> "rx_samples_to_file"). As a test, I injected a multi-tone signal (400 tones
> evenly spaced across 20 MHz) into both RX ports using a 1:2 splitter. I then
> computed FFTs and compared the relative magnitude and phase of each tone
> between the two channels. The magnitude was nearly equal as expected. But,
> the phase has a linear drift with frequency. During one capture, the
> relative phase between adjacent tones (tone spacing of 50 kHz) was 79
> degrees. But, the phase slope is not constant from capture to capture.
I don't have any strict requirements for phase synchronization in my
applications, but, I decided to take a quick look at the B210 phase
profile with measurements derived from LTE reference signals. Attached
are phase plots comparing the 2 receive inputs fed by a single signal
generator and splitter. The first capture is with an external OCXO and
the second is taken with the internal reference. A small frequency
offset is added to show change.
When externally referenced to the signal generator, the phase is
constant over time and there is a fixed phase offset between receive
channels, which is expected behavior.
Running unattached, there were two notable changes. First, the slope
varies over time, which we expect due to non-synchronized symbol
timing and resulting shifts of the reference signal. Second, perhaps
more notably, there was a loss of the strict inter-channel phase
offset. I don't know to what extent that behavior is expected or not.
It doesn't affect me, so I haven't bothered to look into it.
FWIW, those were my observations.
-TT
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b210_phase_ext.png
Type: image/png
Size: 36062 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/432015fa/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b210_phase.png
Type: image/png
Size: 38044 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/432015fa/attachment-0003.png>
------------------------------
Message: 3
Date: Tue, 20 May 2014 17:30:47 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: Robert McGwier <[email protected]>
Cc: "[email protected]" <[email protected]>, Tim
O'Shea <[email protected]>
Subject: Re: [USRP-users] X300 issue.
Message-ID:
<CAJcjmiRYJFs=sdsAJMWb+Y=NF9G=7ukb18gndb_dga--zm5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Your key field is incorrect:
./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr
--val=192.168.10.3
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: [email protected]
Web: http://ettus.com
On Tue, May 20, 2014 at 12:36 PM, Robert McGwier via USRP-users <
[email protected]> wrote:
> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: x300
> addr: 192.168.10.2
> fpga: HGS
> name:
> serial: F4D29E
> product: X300
>
>
> n4hy@n4hy-FW:~/target/lib/uhd/utils$ usrp_x3xx_fpga_burner
> --addr=192.168.10.2
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>
> Attempting to find X3x0 with IP address: 192.168.10.2
> Found X300 (HGS).
>
> Burning image: /home/n4hy/target/share/uhd/images/usrp_x300_fpga_HGS.bit
>
> Progress: 100% (87/87 sectors)
>
>
> (cold start reboot)
>
> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: x300
> addr: 192.168.10.2
> fpga: HGS
> name:
> serial: F4D29E
> product: X300
>
>
> trying to set IP address to 192.168.10.3
>
> n4hy@n4hy-FW:~/target/lib/uhd/utils$ ./usrp_burn_mb_eeprom
> --key=192.168.10.2 --val=192.168.10.3
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>
> Creating USRP device from address:
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO.... No GPSDO found
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Sync DAC's.
> -- Performing register loopback test... pass
> -- Sync DAC's.
> -- Initializing clock and PPS references...
> -- References initialized to internal sources
>
> WARNING: Use of --key and --val is deprecated!
> Fetching current settings from EEPROM...
> Cannot find value for EEPROM[192.168.10.2]
>
>
> And the IP address isn't changed.
>
>
>
> I am sure I am doing something dumb. What is it?
>
>
>
> --
> Bob McGwier
> Co-Owner and Technical Director, Federated Wireless, LLC
> Professor Virginia Tech
> Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
> Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
>
> _______________________________________________
> 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/20140520/4c897c32/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 20 May 2014 09:37:28 -0700
From: Ashish Chaudhari via USRP-users <[email protected]>
To: Mike Jameson <[email protected]>
Cc: "[email protected]" <[email protected]>, Tim
O'Shea <[email protected]>
Subject: Re: [USRP-users] X300 issue.
Message-ID:
<caozxt+cjne+3aoachfkxpx_fvuw5v7pnlvrunonx_yyjpvc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Mike is right, the key is incorrect. However, for the X300 there is more
than one IP address:
http://files.ettus.com/uhd_docs/manual/html/usrp_x3x0.html#setup-networking
It looks like you are using the device over 1Gigabit Ethernet so in your
case you want to change *ip-addr0*
./usrp_burn_mb_eeprom --args=<optional device args> --key=*ip-addr0*
--val=192.168.10.3
Ashish
On Tue, May 20, 2014 at 9:30 AM, Mike Jameson via USRP-users <
[email protected]> wrote:
> Your key field is incorrect:
>
> ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr
> --val=192.168.10.3
>
>
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: [email protected]
> Web: http://ettus.com
>
>
> On Tue, May 20, 2014 at 12:36 PM, Robert McGwier via USRP-users <
> [email protected]> wrote:
>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> --------------------------------------------------
>> -- UHD Device 0
>> --------------------------------------------------
>> Device Address:
>> type: x300
>> addr: 192.168.10.2
>> fpga: HGS
>> name:
>> serial: F4D29E
>> product: X300
>>
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ usrp_x3xx_fpga_burner
>> --addr=192.168.10.2
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> Attempting to find X3x0 with IP address: 192.168.10.2
>> Found X300 (HGS).
>>
>> Burning image: /home/n4hy/target/share/uhd/images/usrp_x300_fpga_HGS.bit
>>
>> Progress: 100% (87/87 sectors)
>>
>>
>> (cold start reboot)
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> --------------------------------------------------
>> -- UHD Device 0
>> --------------------------------------------------
>> Device Address:
>> type: x300
>> addr: 192.168.10.2
>> fpga: HGS
>> name:
>> serial: F4D29E
>> product: X300
>>
>>
>> trying to set IP address to 192.168.10.3
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ ./usrp_burn_mb_eeprom
>> --key=192.168.10.2 --val=192.168.10.3
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> Creating USRP device from address:
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO.... No GPSDO found
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Sync DAC's.
>> -- Performing register loopback test... pass
>> -- Sync DAC's.
>> -- Initializing clock and PPS references...
>> -- References initialized to internal sources
>>
>> WARNING: Use of --key and --val is deprecated!
>> Fetching current settings from EEPROM...
>> Cannot find value for EEPROM[192.168.10.2]
>>
>>
>> And the IP address isn't changed.
>>
>>
>>
>> I am sure I am doing something dumb. What is it?
>>
>>
>>
>> --
>> Bob McGwier
>> Co-Owner and Technical Director, Federated Wireless, LLC
>> Professor Virginia Tech
>> Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
>> Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/91bf26eb/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 20 May 2014 13:01:40 -0400
From: Robert McGwier via USRP-users <[email protected]>
To: Mike Jameson <[email protected]>
Cc: "[email protected]" <[email protected]>, Tim
O'Shea <[email protected]>
Subject: Re: [USRP-users] X300 issue.
Message-ID:
<CA+K5gzdDKCSMddttob2ov7=1KYBFv0Yt+L=jjzxadtw8koo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks. I got both USRP x300's now talking 10GigE to my dual hose 10GigE
card.
They are both online sweeping huge amounts of RF bandwidth. I love it.
On Tue, May 20, 2014 at 12:30 PM, Mike Jameson <[email protected]>wrote:
> Your key field is incorrect:
>
> ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr
> --val=192.168.10.3
>
>
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: [email protected]
> Web: http://ettus.com
>
>
> On Tue, May 20, 2014 at 12:36 PM, Robert McGwier via USRP-users <
> [email protected]> wrote:
>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> --------------------------------------------------
>> -- UHD Device 0
>> --------------------------------------------------
>> Device Address:
>> type: x300
>> addr: 192.168.10.2
>> fpga: HGS
>> name:
>> serial: F4D29E
>> product: X300
>>
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ usrp_x3xx_fpga_burner
>> --addr=192.168.10.2
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> Attempting to find X3x0 with IP address: 192.168.10.2
>> Found X300 (HGS).
>>
>> Burning image: /home/n4hy/target/share/uhd/images/usrp_x300_fpga_HGS.bit
>>
>> Progress: 100% (87/87 sectors)
>>
>>
>> (cold start reboot)
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ uhd_find_devices
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> --------------------------------------------------
>> -- UHD Device 0
>> --------------------------------------------------
>> Device Address:
>> type: x300
>> addr: 192.168.10.2
>> fpga: HGS
>> name:
>> serial: F4D29E
>> product: X300
>>
>>
>> trying to set IP address to 192.168.10.3
>>
>> n4hy@n4hy-FW:~/target/lib/uhd/utils$ ./usrp_burn_mb_eeprom
>> --key=192.168.10.2 --val=192.168.10.3
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-58-g81f25fca
>>
>> Creating USRP device from address:
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO.... No GPSDO found
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Sync DAC's.
>> -- Performing register loopback test... pass
>> -- Sync DAC's.
>> -- Initializing clock and PPS references...
>> -- References initialized to internal sources
>>
>> WARNING: Use of --key and --val is deprecated!
>> Fetching current settings from EEPROM...
>> Cannot find value for EEPROM[192.168.10.2]
>>
>>
>> And the IP address isn't changed.
>>
>>
>>
>> I am sure I am doing something dumb. What is it?
>>
>>
>>
>> --
>> Bob McGwier
>> Co-Owner and Technical Director, Federated Wireless, LLC
>> Professor Virginia Tech
>> Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
>> Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/8b0ab949/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 20 May 2014 17:48:34 -0400
From: Robert Kossler via USRP-users <[email protected]>
To: Stefan Ereth <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Mis-aligned data on B210 RX channels
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Yes, each capture requires a restart of the program and writing a new file (as
the program is currently written).
I will respond to your ?channel assignment? request on its original thread.
Rob
From: Stefan Ereth [mailto:[email protected]]
Sent: Tuesday, May 20, 2014 4:08 AM
To: Robert Kossler
Cc: [email protected]; Ben Hilburn
Subject: Re: [USRP-users] Mis-aligned data on B210 RX channels
Hi Robert,
I have a similar problem with the B210. What do you mean with the phase slope
is not constant from caputre to capture? Do you mean after restarting your
programm and writing a new file? I find out, that by my setup the channel
assignment differs after retuning b210/restarting program?
Could you please test, if the channel assignment is right? Connect your signal
to one channel and let the other open. Try this for at least 20 times.
Regards,
Stefan
----- Original Message -----
From: "Robert Kossler via USRP-users"
<[email protected]<mailto:[email protected]>>
To: "Ben Hilburn" <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Sent: Monday, May 19, 2014 7:01:54 PM GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [USRP-users] Mis-aligned data on B210 RX channels
Sorry, for the delay ? I have been away for a week or so. Here is the
attachment. Has anyone seen a similar linear phase versus frequency behavior?
Rob
From: Ben Hilburn [mailto:[email protected]]
Sent: Wednesday, May 14, 2014 5:16 PM
To: Robert Kossler
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Mis-aligned data on B210 RX channels
Hi Robert -
It looks like your attachments may have gotten stripped. Can you try re-sending
them?
Cheers,
Ben
On Wed, May 7, 2014 at 2:28 PM, Robert Kossler via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I am using a B210 to collect data from 2 RX channels simultaneously and saving
the results to file (using a modified program based on "rx_samples_to_file").
As a test, I injected a multi-tone signal (400 tones evenly spaced across 20
MHz) into both RX ports using a 1:2 splitter. I then computed FFTs and
compared the relative magnitude and phase of each tone between the two
channels. The magnitude was nearly equal as expected. But, the phase has a
linear drift with frequency. During one capture, the relative phase between
adjacent tones (tone spacing of 50 kHz) was 79 degrees. But, the phase slope is
not constant from capture to capture.
For the capture where I measured 79 degrees between adjacent tones, I
calculated that this amount of linear phase versus frequency corresponds to a
channel-to-channel time delay of about 4.39 us, which in turn corresponds to
about 110 samples at my sampling rate of 25 MS/s. Indeed, when I purposely
shift one of the channels by 110 samples, the linear phase versus frequency
disappears.
I am wondering if anyone has seen similar behavior. I fully expect that the
problem is some type of configuration problem or some problem in interpreting /
saving the incoming data streams but I can't seem to find it.
Attached is my "rx_samples_to_file_2" code which is a combination of the
"rx_samples_to_file" and "benchmark_rate" examples programs.
Rob Kossler
_______________________________________________
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/20140520/ff504dbb/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 20 May 2014 18:21:39 -0400
From: Robert Kossler via USRP-users <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 channel assignment
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Martin Braun via USRP-users
> Sent: Wednesday, May 14, 2014 5:51 AM
> To: [email protected]
> Subject: Re: [USRP-users] B210 channel assignment
>
> On 13.05.2014 11:03, Stefan Ereth via USRP-users wrote:
> > Hi all, I try to capture samples of both channels from a B210 and save
> > them in separate files. The Problem is that the channel assignment is
> > different after retuning. I connected a signal generator to channel 1
> > and let channel 2 open. Normally the file "measure0" should always
> > contain my signal and "measure1" noise. But out of 20 times the signal
> > is 17 times in "measure0" and 3 times in "measure1". I appreciate any
> > advice on resolving or further debugging this issue. Stefan
>
> Hi Stefan,
>
> do you mean you restart your app 20 times, and sometimes it switches?
> Also, what makes you think this is due to re-tuning?
>
> Do you have access to GNU Radio (or something similar)? If so, you could try
> observing the output of the individual ports of a UHD Source (like
> this: http://imgur.com/tJO4nOo). I just ran this at least 20 times, and the
> output is reliably mapped to the same port every time.
>
> Martin
I was able to duplicate Stefan's results using both a modified
"rx_samples_to_file" program as well as a simple GRC flow graph. Attached are
3 files:
1) TwoChanFFT.py: simple flow graph which plots FFT of each channel
2) rx_samples_to_file_2.cpp: modified version of "rx_samples_to_file.cpp" so
that it can collect 2 channels and write each to its own file
3) rx_samps_to_file_output.txt: example output from modified program (this
shows the command line arguments I used)
Test Setup
- Multi-tone signal (signal modulation is not really important) at 2412 MHz,
-40 dBm, injected into "RF A: Rx 2" ("RF B: Rx 2" was left unconnected)
Test Procedure / Results
- Using the modified "rx_samples_to_file_2.cpp" program, I ran the program
numerous times (> 40), each time generating a new data file. I then read the
files into Matlab and plotted the FFT for both channels (I realize that taking
an FFT was not needed if I only wanted to determine if signal was present or
not, but that was the tool I had available). On about 5 occasions, the signal
switched to the normally "noise" channel. I did not include my Matlab code in
this email because it is probably not needed given that I was able to duplicate
the behavior in a GRC flow graph as described below.
- Using the GRC flow graph (attached), I ran the flow graph and looked to see
if the signal showed up on the top or the bottom FFT plot. Next, I stopped the
flow graph. Then, I repeated this numerous times (> 30). Most of the time,
the signal showed on the bottom FFT plot, but 2 or 3 times it showed up on the
top FFT plot.
Rob
------------------------------
Message: 8
Date: Tue, 20 May 2014 18:27:32 -0400
From: Robert Kossler via USRP-users <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 channel assignment
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Robert Kossler via USRP-users
> Sent: Tuesday, May 20, 2014 6:22 PM
> To: Martin Braun
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 channel assignment
>
> > -----Original Message-----
> > From: USRP-users [mailto:[email protected]] On Behalf
> > Of Martin Braun via USRP-users
> > Sent: Wednesday, May 14, 2014 5:51 AM
> > To: [email protected]
> > Subject: Re: [USRP-users] B210 channel assignment
> >
> > On 13.05.2014 11:03, Stefan Ereth via USRP-users wrote:
> > > Hi all, I try to capture samples of both channels from a B210 and
> > > save them in separate files. The Problem is that the channel
> > > assignment is different after retuning. I connected a signal
> > > generator to channel 1 and let channel 2 open. Normally the file
> > > "measure0" should always contain my signal and "measure1" noise. But
> > > out of 20 times the signal is 17 times in "measure0" and 3 times in
> > > "measure1". I appreciate any advice on resolving or further
> > > debugging this issue. Stefan
> >
> > Hi Stefan,
> >
> > do you mean you restart your app 20 times, and sometimes it switches?
> > Also, what makes you think this is due to re-tuning?
> >
> > Do you have access to GNU Radio (or something similar)? If so, you
> > could try observing the output of the individual ports of a UHD Source
> > (like
> > this: http://imgur.com/tJO4nOo). I just ran this at least 20 times,
> > and the output is reliably mapped to the same port every time.
> >
> > Martin
>
>
> I was able to duplicate Stefan's results using both a modified
> "rx_samples_to_file" program as well as a simple GRC flow graph. Attached
> are 3 files:
> 1) TwoChanFFT.py: simple flow graph which plots FFT of each channel
> 2) rx_samples_to_file_2.cpp: modified version of "rx_samples_to_file.cpp"
> so that it can collect 2 channels and write each to its own file
> 3) rx_samps_to_file_output.txt: example output from modified program
> (this shows the command line arguments I used)
>
> Test Setup
> - Multi-tone signal (signal modulation is not really important) at 2412 MHz,
> -40
> dBm, injected into "RF A: Rx 2" ("RF B: Rx 2" was left unconnected)
>
> Test Procedure / Results
> - Using the modified "rx_samples_to_file_2.cpp" program, I ran the program
> numerous times (> 40), each time generating a new data file. I then read the
> files into Matlab and plotted the FFT for both channels (I realize that taking
> an FFT was not needed if I only wanted to determine if signal was present or
> not, but that was the tool I had available). On about 5 occasions, the signal
> switched to the normally "noise" channel. I did not include my Matlab code
> in this email because it is probably not needed given that I was able to
> duplicate the behavior in a GRC flow graph as described below.
> - Using the GRC flow graph (attached), I ran the flow graph and looked to see
> if the signal showed up on the top or the bottom FFT plot. Next, I stopped
> the flow graph. Then, I repeated this numerous times (> 30). Most of the
> time, the signal showed on the bottom FFT plot, but 2 or 3 times it showed
> up on the top FFT plot.
>
Attachments added...
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rx_samps_to_file_output.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/fe96b19b/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TwoChanFFT.py
Type: application/octet-stream
Size: 4162 bytes
Desc: TwoChanFFT.py
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/fe96b19b/attachment-0001.py>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rx_samples_to_file_2.cpp
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140520/fe96b19b/attachment-0001.cpp>
------------------------------
Message: 9
Date: Wed, 21 May 2014 12:24:59 +0400
From: Dmitry Dmitry via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] B210
Message-ID: <[email protected]>
Content-Type: text/plain
Hi,
Im using B210 with GNURadio. If I correctly understand the RX part of the B210
(after down conversion) is:
LPF1->LPF2->ADC->HB1->HB2->HB3->FIR->FPGA.
Is there a method to control the passband of the LPFs, switch on/off the HB
decimation filters and build FIR filter via GNURadio?
Thanks in advance.
Dmitry.
------------------------------
Message: 10
Date: Wed, 21 May 2014 01:52:57 -0700
From: Ian Buckley via USRP-users <[email protected]>
To: Dmitry Dmitry <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dmitry,
Pretty much all the answers to your questions currently are located in:
firmware/fx3/ad9361/lib/ad9361_impl.c
For example the methods : calibrate_baseband_rx_analog_filter() and
calibrate_rx_TIAs() control the passbands of the analog RX filtering.
The methods to program the large FIR is fairly obvious in this code, and if you
look around you'll soon see how the various filter combinations are
automatically selected based on clock frequency constraints for the converters
and the users requested master_clock_rate. To make a lot of sense of the
details in this file you'll have to obtain the AD9361 documentation which is
available publicly now, but I believe you have to register with them.
Likewise since this code still runs in the FX3 micro controller, to make custom
builds you'll need to obtain the (free) SDK from Cypress Semiconductor which
again involves registering I believe.
-Ian
On May 21, 2014, at 1:24 AM, Dmitry Dmitry via USRP-users
<[email protected]> wrote:
> Hi,
> Im using B210 with GNURadio. If I correctly understand the RX part of the
> B210 (after down conversion) is:
>
> LPF1->LPF2->ADC->HB1->HB2->HB3->FIR->FPGA.
>
> Is there a method to control the passband of the LPFs, switch on/off the HB
> decimation filters and build FIR filter via GNURadio?
>
> Thanks in advance.
>
> Dmitry.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Wed, 21 May 2014 14:47:26 +0400
From: Dmitry via USRP-users <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210
Message-ID: <[email protected]>
Content-Type: text/plain
Thanks, Ian
I.e. most parameters of filtering are depends on the variable "_baseband_bw"
which depends of the master_clock_rate? And all of this parameters is
automatically calculated when we set the master_clock_rate?
In GNURadio I use "Sample rate" field of "UHD:USRP Source" to set sample rate
in Sps). Is this a variable which used for calculation of the filtering
parameters?
Thanks
------------------------------
Message: 12
Date: Wed, 21 May 2014 13:50:30 +0200
From: Matt Ettus via USRP-users <[email protected]>
To: Jinu Jayachandran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Changing the USRP N210 FPGA clock frequency
Message-ID:
<CAN=1kn9qemkz4e9kegub6xqd1niyckckxn2sz11nktnwxdl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jinu,
I am confused as to why you need to convert the samples to a serial format.
This is not normally how radios are built.
Matt
On Mon, May 19, 2014 at 6:12 PM, Jinu Jayachandran via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am working on the Xilinx FPGA in USRP N210. I am trying to implement
> an OFDM transceiver in two different USRP FPGAs (one as transmitter and
> other as receiver).
>
> I would like to implement the module between DUC/DDC chain and VITA
> TX/RX. I am using the custom_dsp_rx.v and custom_dsp_tx.v files.
>
> I am stuck in the part where I want to convert the parallel data to
> serial. The input data received in the custom module is 16-bit I (and
> 16-bit Q) samples. So I need a clock frequency 16 times to that of base
> clock frequency (i.e 100MHz x 16 = 1.6GHz) which is not possible in the
> Spartan 3A-DSP FPGA. So is it possible to reduce the original frequency of
> FPGA from 100MHz to 10MHz, so that I can multiply this frequency by 16 for
> serial conversion ?. Or is there any other method to do the same ?
>
> Please Help
>
> Regards,
> Jinu
>
> _______________________________________________
> 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/20140521/109fd37a/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 21 May 2014 11:30:10 -0400
From: Robert Kossler via USRP-users <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 channel assignment
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Robert Kossler via USRP-users
> Sent: Tuesday, May 20, 2014 6:28 PM
> To: Martin Braun
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 channel assignment
>
> > -----Original Message-----
> > From: USRP-users [mailto:[email protected]] On Behalf
> > Of Robert Kossler via USRP-users
> > Sent: Tuesday, May 20, 2014 6:22 PM
> > To: Martin Braun
> > Cc: [email protected]
> > Subject: Re: [USRP-users] B210 channel assignment
> >
> > > -----Original Message-----
> > > From: USRP-users [mailto:[email protected]] On
> > > Behalf Of Martin Braun via USRP-users
> > > Sent: Wednesday, May 14, 2014 5:51 AM
> > > To: [email protected]
> > > Subject: Re: [USRP-users] B210 channel assignment
> > >
> > > On 13.05.2014 11:03, Stefan Ereth via USRP-users wrote:
> > > > Hi all, I try to capture samples of both channels from a B210 and
> > > > save them in separate files. The Problem is that the channel
> > > > assignment is different after retuning. I connected a signal
> > > > generator to channel 1 and let channel 2 open. Normally the file
> > > > "measure0" should always contain my signal and "measure1" noise.
> > > > But out of 20 times the signal is 17 times in "measure0" and 3
> > > > times in "measure1". I appreciate any advice on resolving or
> > > > further debugging this issue. Stefan
> > >
> > > Hi Stefan,
> > >
> > > do you mean you restart your app 20 times, and sometimes it switches?
> > > Also, what makes you think this is due to re-tuning?
> > >
> > > Do you have access to GNU Radio (or something similar)? If so, you
> > > could try observing the output of the individual ports of a UHD
> > > Source (like
> > > this: http://imgur.com/tJO4nOo). I just ran this at least 20 times,
> > > and the output is reliably mapped to the same port every time.
> > >
> > > Martin
> >
> >
> > I was able to duplicate Stefan's results using both a modified
> > "rx_samples_to_file" program as well as a simple GRC flow graph.
> > Attached are 3 files:
> > 1) TwoChanFFT.py: simple flow graph which plots FFT of each channel
> > 2) rx_samples_to_file_2.cpp: modified version of "rx_samples_to_file.cpp"
> > so that it can collect 2 channels and write each to its own file
> > 3) rx_samps_to_file_output.txt: example output from modified program
> > (this shows the command line arguments I used)
> >
> > Test Setup
> > - Multi-tone signal (signal modulation is not really important) at
> > 2412 MHz, -40 dBm, injected into "RF A: Rx 2" ("RF B: Rx 2" was left
> > unconnected)
> >
> > Test Procedure / Results
> > - Using the modified "rx_samples_to_file_2.cpp" program, I ran the
> > program numerous times (> 40), each time generating a new data file.
> > I then read the files into Matlab and plotted the FFT for both
> > channels (I realize that taking an FFT was not needed if I only wanted
> > to determine if signal was present or not, but that was the tool I had
> > available). On about 5 occasions, the signal switched to the normally
> > "noise" channel. I did not include my Matlab code in this email
> > because it is probably not needed given that I was able to duplicate the
> behavior in a GRC flow graph as described below.
> > - Using the GRC flow graph (attached), I ran the flow graph and looked
> > to see if the signal showed up on the top or the bottom FFT plot.
> > Next, I stopped the flow graph. Then, I repeated this numerous times
> > (> 30). Most of the time, the signal showed on the bottom FFT plot,
> > but 2 or 3 times it showed up on the top FFT plot.
> >
>
> Attachments added...
I just realized that I only attached the ".py" file and forgot the ".grc" file.
The latter is included here.
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TwoChanFFT.grc
Type: application/octet-stream
Size: 19024 bytes
Desc: TwoChanFFT.grc
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140521/0439e6ca/attachment-0001.grc>
------------------------------
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 45, Issue 19
******************************************
