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. Keep transmitted signal in USRP to overcome the limited host
sample rate of E100/E110 (Jack)
2. UHD Apps freeze with USRPB210 (Banerjee, Soumen)
3. Connect USRP to OSMO board (Carlos Alberto Ruiz Naranjo)
4. Re: Connect USRP to OSMO board (Ian Buckley)
5. Re: UHD Apps freeze with USRPB210 (Hans Van Ingelgom)
6. Most performant way to save samples to disk from a B200?
(Hans Van Ingelgom)
7. Re: Most performant way to save samples to disk from a B200?
(Marcus D. Leech)
8. Re: Most performant way to save samples to disk from a B200?
(Hans Van Ingelgom)
9. Re: UHD Apps freeze with USRPB210 (Ralph A. Schmid, dk5ras)
10. Re: Most performant way to save samples to disk from a B200?
(Ian Buckley)
11. Re: Most performant way to save samples to disk from a B200?
(Martin Braun)
12. Re: UHD Apps freeze with USRPB210 (Banerjee, Soumen)
13. UBX daughter board (Luong Tan Phong)
14. Re: Keep transmitted signal in USRP to overcome the limited
host sample rate of E100/E110 (Marcus M?ller)
15. Re: N210 Stops Transmitting (Liwei)
16. Re: N210 Stops Transmitting (Marcus D. Leech)
17. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Urban Hakansson)
18. Re: Boost Requirements (Was: 3.8.0 build issues on centos 6)
(Ben ROBERT)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Oct 2014 16:38:06 +0900
From: Jack <[email protected]>
To: [email protected]
Subject: [USRP-users] Keep transmitted signal in USRP to overcome the
limited host sample rate of E100/E110
Message-ID:
<CAHoWzP0wo38Ea6fmLfr=swuvygrmm5ki3d_hr-k3tfs__f-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi -
As you know, embedded series, E100/E110, has the limited host sample rate,
just only 4MS/s. But I want to send bigger signal bandwidth (ex. 20Mhz).
My idea to overcome this issue is to keep the transmitted signal inside
FPGA. But I have not started to work on this yet. Have anyone tried to do
so? Could you share your experience? Is it possible? Simple work? or
Complicated work?
Best Regards,
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141017/47d03fa6/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 20 Oct 2014 04:07:42 +0000
From: "Banerjee, Soumen" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD Apps freeze with USRPB210
Message-ID:
<e80c9cb885a9d647b348a7e325e2471f1c005...@ie1aex3004.global.ds.honeywell.com>
Content-Type: text/plain; charset="us-ascii"
Greetings!
I managed to install gnuradio and uhd and it seems to be able to detect the
usrp device. It shows up in the output of lsusb.
I was trying out the simple fm radio demonstration and that one kept crashing.
No debug output, nothing. It just froze. So I thought Ill look at the basics
and tried to run the uhd_fft app (from path). I put the sampling frequency in
the FM band since I know the FM stations over here and I was able to see peaks
at the expected frequencies, but its not a continuous FFT. It just freezes
immediately after the first graph is plotted. Is there something that Im
missing? Im inclined to think that the installation went all right because the
peaks in the snapshot FFT match so well with the expected radio stations!
I noted that someone else has had this problem with a N210 before, and they
solved it by updating the OS and playing around with the Ethernet settings, but
Im connected to the B210 over USB, so that method can't be tried.
Any suggestions?
Thanks!
Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/b33c7b98/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 20 Oct 2014 14:17:22 +0200
From: Carlos Alberto Ruiz Naranjo <[email protected]>
To: [email protected]
Subject: [USRP-users] Connect USRP to OSMO board
Message-ID:
<cap2egphe9rkjmqq6xacbyy0eu+uzszg4ghjwxsfdt9apj9j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have a GPS receiver (
http://u-blox.com/images/downloads/Product_Docs/LEA-NEO-6T_ProductSummary_%28GPS.G6-HW-09020%29.pdf
) with a Osmo board ( http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps )
Can I directly connect the USRP (WBX) to the GPS receiver? (RF USRP --->
RF receiver)
Can I damage the WBX board with the antenna power supply (of RF port)?
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/bc4ac51e/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 20 Oct 2014 11:06:44 -0700
From: Ian Buckley <[email protected]>
To: Carlos Alberto Ruiz Naranjo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Connect USRP to OSMO board
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Why not just throw in an off the shelf bias-T to act as a DC block in the RF
path? For example http://www.minicircuits.com/pdfs/ZFBT-4R2G+.pdf
That way you don't have to worry about what WBX or any other signal source
might tolerate.
-Ian
On Oct 20, 2014, at 5:17 AM, Carlos Alberto Ruiz Naranjo via USRP-users
<[email protected]> wrote:
> I have a GPS receiver (
> http://u-blox.com/images/downloads/Product_Docs/LEA-NEO-6T_ProductSummary_%28GPS.G6-HW-09020%29.pdf
> ) with a Osmo board ( http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps )
>
>
> Can I directly connect the USRP (WBX) to the GPS receiver? (RF USRP ---> RF
> receiver)
> Can I damage the WBX board with the antenna power supply (of RF port)?
>
> Thank you.
> _______________________________________________
> 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/20141020/ae3a554a/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 21 Oct 2014 05:30:57 +0200
From: Hans Van Ingelgom <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Apps freeze with USRPB210
Message-ID:
<CAKMNkkM7QD=hz45i7kT6=Y1jZTmKWt8DF+PjBsFPhDOWk3K=2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Oct 20, 2014 at 6:07 AM, Banerjee, Soumen via USRP-users <
[email protected]> wrote:
>
>
> I was trying out the simple fm radio demonstration and that one kept
> crashing. No debug output, nothing. It just froze. So I thought Ill look at
> the basics and tried to run the uhd_fft app (from path). I put the sampling
> frequency in the FM band since I know the FM stations over here and I was
> able to see peaks at the expected frequencies, but its not a continuous
> FFT. It just freezes immediately after the first graph is plotted. Is there
> something that Im missing? Im inclined to think that the installation went
> all right because the peaks in the snapshot FFT match so well with the
> expected radio stations!
>
>
For that kind of troubleshooting, the first program to try is
uhd_usrp_probe. It locates the hardware, loads the fpga firmware and
reports the radio's capabilities.
A rookie mistake that I made myself is updating gnuradio and uhd without
getting the latest firmware. It caused all kinds of crazy behaviour.
Reading the output of that program will tell you what command to execute to
automatically download and install the latest firmware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/7a6805a2/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 21 Oct 2014 05:42:47 +0200
From: Hans Van Ingelgom <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Most performant way to save samples to disk from
a B200?
Message-ID:
<cakmnkkmtu0gnu5ijiwwrzptmoqwnxo-+qb_v1ypw23gky1n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I want to record samples to disk from a B200. I could make a flowgraph in
gnuradio-companion, but that will save floating point values. Is there a
more efficient way to store samples, as the raw format is only 12 bits? Any
tips on getting the most performance?
(I have been playing with this thing for a few months now, and "drinking
from a firehose" is a saying that really applies to that piece of hardware).
Thanks,
Hans Van Ingelgom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/6f314567/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Oct 2014 23:47:53 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Most performant way to save samples to disk
from a B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/20/2014 11:42 PM, Hans Van Ingelgom via USRP-users wrote:
> Hello,
>
> I want to record samples to disk from a B200. I could make a flowgraph
> in gnuradio-companion, but that will save floating point values. Is
> there a more efficient way to store samples, as the raw format is only
> 12 bits? Any tips on getting the most performance?
>
> (I have been playing with this thing for a few months now, and
> "drinking from a firehose" is a saying that really applies to that
> piece of hardware).
>
> Thanks,
> Hans Van Ingelgom
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Here's the --help output for rx_samples_to_file:
./rx_samples_to_file --help
linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
UHD_003.007.002-94-ge56809a0
UHD RX samples to file Allowed options:
--help help message
--args arg multi uhd device address args
--file arg (=usrp_samples.dat) name of the file to write binary
samples to
--type arg (=short) sample type: double, float, or short
--nsamps arg (=0) total number of samples to receive
--time arg (=0) total number of seconds to receive
--spb arg (=10000) samples per buffer
--rate arg (=1000000) rate of incoming samples
--freq arg (=0) RF center frequency in Hz
--gain arg gain for the RF chain
--ant arg daughterboard antenna selection
--subdev arg daughterboard subdevice specification
--bw arg daughterboard IF filter bandwidth in Hz
--ref arg (=internal) reference source (internal, external,
mimo)
--wirefmt arg (=sc16) wire format (sc8 or sc16)
--setup arg (=1) seconds of setup time
--progress periodically display short-term bandwidth
--stats show average bandwidth on exit
--sizemap track packet size and display
breakdown on
exit
--null run without writing to file
--continue don't abort on a bad packet
--skip-lo skip checking LO lock status
--int-n tune USRP with integer-N tuning
And, uhd_rx_cfile (A Gnu Radio app):
linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
UHD_003.007.002-94-ge56809a0
Usage: uhd_rx_cfile: [options] output_filename
Options:
-h, --help show this help message and exit
-a ARGS, --args=ARGS UHD device address args , [default=]
--spec=SPEC Subdevice of UHD device where appropriate
-A ANTENNA, --antenna=ANTENNA
select Rx Antenna where appropriate
--samp-rate=SAMP_RATE
set sample rate (bandwidth) [default=1000000.0]
-f FREQ, --freq=FREQ set frequency to FREQ
-g GAIN, --gain=GAIN set gain in dB (default is midpoint)
-s, --output-shorts output interleaved shorts instead of complex floats
-N NSAMPLES, --nsamples=NSAMPLES
number of samples to collect [default=+inf]
-v, --verbose verbose output
--lo-offset=LO_OFFSET
set daughterboard LO offset to OFFSET [default=hw
default]
--wire-format=WIRE_FORMAT
set wire format from USRP [default=sc16
--stream-args=STREAM_ARGS
set stream arguments [default=]
--show-async-msg Show asynchronous message notifications from UHD
[default=False]
linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
UHD_003.007.002-94-ge56809a0
Usage: uhd_rx_cfile: [options] output_filename
Options:
-h, --help show this help message and exit
-a ARGS, --args=ARGS UHD device address args , [default=]
--spec=SPEC Subdevice of UHD device where appropriate
-A ANTENNA, --antenna=ANTENNA
select Rx Antenna where appropriate
--samp-rate=SAMP_RATE
set sample rate (bandwidth) [default=1000000.0]
-f FREQ, --freq=FREQ set frequency to FREQ
-g GAIN, --gain=GAIN set gain in dB (default is midpoint)
-s, --output-shorts output interleaved shorts instead of complex floats
-N NSAMPLES, --nsamples=NSAMPLES
number of samples to collect [default=+inf]
-v, --verbose verbose output
--lo-offset=LO_OFFSET
set daughterboard LO offset to OFFSET [default=hw
default]
--wire-format=WIRE_FORMAT
set wire format from USRP [default=sc16
--stream-args=STREAM_ARGS
set stream arguments [default=]
--show-async-msg Show asynchronous message notifications from UHD
[default=False]
You should try them both--they both support recording data as "shorts".
Which is certainly space efficient. There is no packed-12-bit recording
format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/3e390e3e/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 21 Oct 2014 07:14:55 +0200
From: Hans Van Ingelgom <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Most performant way to save samples to disk
from a B200?
Message-ID:
<cakmnkkm3ezpdgtzjb32h7mk3wbedgmoguua7kbs24ht8gor...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just did a test with uhd_rx_cfile, but when I try to read these samples
back into grc, I stumble upon a road block: I can read samples as short,
but not complex shorts. Maybe an extension to this block is appropriate?
On Tue, Oct 21, 2014 at 5:47 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 10/20/2014 11:42 PM, Hans Van Ingelgom via USRP-users wrote:
>
> Hello,
>
> I want to record samples to disk from a B200. I could make a flowgraph
> in gnuradio-companion, but that will save floating point values. Is there a
> more efficient way to store samples, as the raw format is only 12 bits? Any
> tips on getting the most performance?
>
> (I have been playing with this thing for a few months now, and "drinking
> from a firehose" is a saying that really applies to that piece of hardware).
>
> Thanks,
> Hans Van Ingelgom
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Here's the --help output for rx_samples_to_file:
>
> ./rx_samples_to_file --help
> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
> UHD_003.007.002-94-ge56809a0
>
> UHD RX samples to file Allowed options:
> --help help message
> --args arg multi uhd device address args
> --file arg (=usrp_samples.dat) name of the file to write binary samples
> to
> --type arg (=short) sample type: double, float, or short
> --nsamps arg (=0) total number of samples to receive
> --time arg (=0) total number of seconds to receive
> --spb arg (=10000) samples per buffer
> --rate arg (=1000000) rate of incoming samples
> --freq arg (=0) RF center frequency in Hz
> --gain arg gain for the RF chain
> --ant arg daughterboard antenna selection
> --subdev arg daughterboard subdevice specification
> --bw arg daughterboard IF filter bandwidth in Hz
> --ref arg (=internal) reference source (internal, external,
> mimo)
> --wirefmt arg (=sc16) wire format (sc8 or sc16)
> --setup arg (=1) seconds of setup time
> --progress periodically display short-term bandwidth
> --stats show average bandwidth on exit
> --sizemap track packet size and display breakdown
> on
> exit
> --null run without writing to file
> --continue don't abort on a bad packet
> --skip-lo skip checking LO lock status
> --int-n tune USRP with integer-N tuning
>
> And, uhd_rx_cfile (A Gnu Radio app):
>
> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
> UHD_003.007.002-94-ge56809a0
>
> Usage: uhd_rx_cfile: [options] output_filename
>
> Options:
> -h, --help show this help message and exit
> -a ARGS, --args=ARGS UHD device address args , [default=]
> --spec=SPEC Subdevice of UHD device where appropriate
> -A ANTENNA, --antenna=ANTENNA
> select Rx Antenna where appropriate
> --samp-rate=SAMP_RATE
> set sample rate (bandwidth) [default=1000000.0]
> -f FREQ, --freq=FREQ set frequency to FREQ
> -g GAIN, --gain=GAIN set gain in dB (default is midpoint)
> -s, --output-shorts output interleaved shorts instead of complex floats
> -N NSAMPLES, --nsamples=NSAMPLES
> number of samples to collect [default=+inf]
> -v, --verbose verbose output
> --lo-offset=LO_OFFSET
> set daughterboard LO offset to OFFSET [default=hw
> default]
> --wire-format=WIRE_FORMAT
> set wire format from USRP [default=sc16
> --stream-args=STREAM_ARGS
> set stream arguments [default=]
> --show-async-msg Show asynchronous message notifications from UHD
> [default=False]
> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
> UHD_003.007.002-94-ge56809a0
>
> Usage: uhd_rx_cfile: [options] output_filename
>
> Options:
> -h, --help show this help message and exit
> -a ARGS, --args=ARGS UHD device address args , [default=]
> --spec=SPEC Subdevice of UHD device where appropriate
> -A ANTENNA, --antenna=ANTENNA
> select Rx Antenna where appropriate
> --samp-rate=SAMP_RATE
> set sample rate (bandwidth) [default=1000000.0]
> -f FREQ, --freq=FREQ set frequency to FREQ
> -g GAIN, --gain=GAIN set gain in dB (default is midpoint)
> -s, --output-shorts output interleaved shorts instead of complex floats
> -N NSAMPLES, --nsamples=NSAMPLES
> number of samples to collect [default=+inf]
> -v, --verbose verbose output
> --lo-offset=LO_OFFSET
> set daughterboard LO offset to OFFSET [default=hw
> default]
> --wire-format=WIRE_FORMAT
> set wire format from USRP [default=sc16
> --stream-args=STREAM_ARGS
> set stream arguments [default=]
> --show-async-msg Show asynchronous message notifications from UHD
> [default=False]
>
>
> You should try them both--they both support recording data as "shorts".
> Which is certainly space efficient. There is no packed-12-bit recording
> format.
>
>
>
>
> _______________________________________________
> 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/20141021/1b853221/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 21 Oct 2014 08:10:23 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Banerjee, Soumen'" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] UHD Apps freeze with USRPB210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
This sounds similar to my actual experiences. With the last release the USB
disconnect problems are gone, but especially at higher sampling rates the
system freezes after seconds up to one minute. Command line programs then
show errors like this one:
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or invalid packet length
UHD source block got error code 0xf
At the moment I have no idea what is happening, the whole thing is far from
being usable at the moment, while it operates under Windows on the same PC
for hours, so at least the hardware is OK.
OS is Kubuntu 14.04 32 bit low latency.
Unfortunately I was not able to build uhd on my Kubuntu 12 system, compile
stops with some nirio error, but I do not have the time at the moment to go
deeper into this.
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of
Banerjee, Soumen via USRP-users
Sent: Monday, October 20, 2014 6:08 AM
To: [email protected]
Subject: [USRP-users] UHD Apps freeze with USRPB210
Greetings!
I managed to install gnuradio and uhd and it seems to be able to detect the
usrp device. It shows up in the output of lsusb.
I was trying out the simple fm radio demonstration and that one kept
crashing. No debug output, nothing. It just froze. So I thought Ill look at
the basics and tried to run the uhd_fft app (from path). I put the sampling
frequency in the FM band since I know the FM stations over here and I was
able to see peaks at the expected frequencies, but its not a continuous FFT.
It just freezes immediately after the first graph is plotted. Is there
something that Im missing? Im inclined to think that the installation went
all right because the peaks in the snapshot FFT match so well with the
expected radio stations!
I noted that someone else has had this problem with a N210 before, and they
solved it by updating the OS and playing around with the Ethernet settings,
but Im connected to the B210 over USB, so that method can't be tried.
Any suggestions?
Thanks!
Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/ec525929/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 21 Oct 2014 00:05:28 -0700
From: Ian Buckley <[email protected]>
To: Hans Van Ingelgom <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Most performant way to save samples to disk
from a B200?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hans,
This is a bit of a side note to your question but don't make the assumption
that because the physical sample size that is transferred from the Radio IC to
the FPGA is 12bits in size that the 16bit samples over the USB wire always
contain 4 unused bits.
Many sampling configurations for a B200 will cause some amount of decimation to
occur within the FPGA, and this in turn will cause the effective resolution of
the signal to increase.
-Ian
On Oct 20, 2014, at 8:42 PM, Hans Van Ingelgom via USRP-users
<[email protected]> wrote:
> Hello,
>
> I want to record samples to disk from a B200. I could make a flowgraph in
> gnuradio-companion, but that will save floating point values. Is there a more
> efficient way to store samples, as the raw format is only 12 bits? Any tips
> on getting the most performance?
>
> (I have been playing with this thing for a few months now, and "drinking from
> a firehose" is a saying that really applies to that piece of hardware).
>
> Thanks,
> Hans Van Ingelgom
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Tue, 21 Oct 2014 10:17:16 +0200
From: Martin Braun <[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Most performant way to save samples to disk
from a B200?
Message-ID:
<cafoi1a7af_xyxpueslqgqu3ffygrkdde8fczy1hr6g8qzc1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I can't test it right now, but I believe the file source in GNU Radio has a
vector length option. Set this to two, and you get 'interleaved shorts',
which we use for complex shorts. There's a block 'ishort to complex' if you
want to continue working with floating point complex.
M
On 21 Oct 2014 07:15, "Hans Van Ingelgom via USRP-users" <
[email protected]> wrote:
> I just did a test with uhd_rx_cfile, but when I try to read these samples
> back into grc, I stumble upon a road block: I can read samples as short,
> but not complex shorts. Maybe an extension to this block is appropriate?
>
> On Tue, Oct 21, 2014 at 5:47 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 10/20/2014 11:42 PM, Hans Van Ingelgom via USRP-users wrote:
>>
>> Hello,
>>
>> I want to record samples to disk from a B200. I could make a flowgraph
>> in gnuradio-companion, but that will save floating point values. Is there a
>> more efficient way to store samples, as the raw format is only 12 bits? Any
>> tips on getting the most performance?
>>
>> (I have been playing with this thing for a few months now, and
>> "drinking from a firehose" is a saying that really applies to that piece of
>> hardware).
>>
>> Thanks,
>> Hans Van Ingelgom
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> Here's the --help output for rx_samples_to_file:
>>
>> ./rx_samples_to_file --help
>> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
>> UHD_003.007.002-94-ge56809a0
>>
>> UHD RX samples to file Allowed options:
>> --help help message
>> --args arg multi uhd device address args
>> --file arg (=usrp_samples.dat) name of the file to write binary samples
>> to
>> --type arg (=short) sample type: double, float, or short
>> --nsamps arg (=0) total number of samples to receive
>> --time arg (=0) total number of seconds to receive
>> --spb arg (=10000) samples per buffer
>> --rate arg (=1000000) rate of incoming samples
>> --freq arg (=0) RF center frequency in Hz
>> --gain arg gain for the RF chain
>> --ant arg daughterboard antenna selection
>> --subdev arg daughterboard subdevice specification
>> --bw arg daughterboard IF filter bandwidth in Hz
>> --ref arg (=internal) reference source (internal, external,
>> mimo)
>> --wirefmt arg (=sc16) wire format (sc8 or sc16)
>> --setup arg (=1) seconds of setup time
>> --progress periodically display short-term bandwidth
>> --stats show average bandwidth on exit
>> --sizemap track packet size and display breakdown
>> on
>> exit
>> --null run without writing to file
>> --continue don't abort on a bad packet
>> --skip-lo skip checking LO lock status
>> --int-n tune USRP with integer-N tuning
>>
>> And, uhd_rx_cfile (A Gnu Radio app):
>>
>> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
>> UHD_003.007.002-94-ge56809a0
>>
>> Usage: uhd_rx_cfile: [options] output_filename
>>
>> Options:
>> -h, --help show this help message and exit
>> -a ARGS, --args=ARGS UHD device address args , [default=]
>> --spec=SPEC Subdevice of UHD device where appropriate
>> -A ANTENNA, --antenna=ANTENNA
>> select Rx Antenna where appropriate
>> --samp-rate=SAMP_RATE
>> set sample rate (bandwidth) [default=1000000.0]
>> -f FREQ, --freq=FREQ set frequency to FREQ
>> -g GAIN, --gain=GAIN set gain in dB (default is midpoint)
>> -s, --output-shorts output interleaved shorts instead of complex
>> floats
>> -N NSAMPLES, --nsamples=NSAMPLES
>> number of samples to collect [default=+inf]
>> -v, --verbose verbose output
>> --lo-offset=LO_OFFSET
>> set daughterboard LO offset to OFFSET [default=hw
>> default]
>> --wire-format=WIRE_FORMAT
>> set wire format from USRP [default=sc16
>> --stream-args=STREAM_ARGS
>> set stream arguments [default=]
>> --show-async-msg Show asynchronous message notifications from UHD
>> [default=False]
>> linux; GNU C++ version 4.7.2 20121109 (Red Hat 4.7.2-8); Boost_105000;
>> UHD_003.007.002-94-ge56809a0
>>
>> Usage: uhd_rx_cfile: [options] output_filename
>>
>> Options:
>> -h, --help show this help message and exit
>> -a ARGS, --args=ARGS UHD device address args , [default=]
>> --spec=SPEC Subdevice of UHD device where appropriate
>> -A ANTENNA, --antenna=ANTENNA
>> select Rx Antenna where appropriate
>> --samp-rate=SAMP_RATE
>> set sample rate (bandwidth) [default=1000000.0]
>> -f FREQ, --freq=FREQ set frequency to FREQ
>> -g GAIN, --gain=GAIN set gain in dB (default is midpoint)
>> -s, --output-shorts output interleaved shorts instead of complex
>> floats
>> -N NSAMPLES, --nsamples=NSAMPLES
>> number of samples to collect [default=+inf]
>> -v, --verbose verbose output
>> --lo-offset=LO_OFFSET
>> set daughterboard LO offset to OFFSET [default=hw
>> default]
>> --wire-format=WIRE_FORMAT
>> set wire format from USRP [default=sc16
>> --stream-args=STREAM_ARGS
>> set stream arguments [default=]
>> --show-async-msg Show asynchronous message notifications from UHD
>> [default=False]
>>
>>
>> You should try them both--they both support recording data as "shorts".
>> Which is certainly space efficient. There is no packed-12-bit recording
>> format.
>>
>>
>>
>>
>> _______________________________________________
>> 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/20141021/d9b7fa66/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 21 Oct 2014 09:04:26 +0000
From: "Banerjee, Soumen" <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Apps freeze with USRPB210
Message-ID:
<e80c9cb885a9d647b348a7e325e2471f1c006...@ie1aex3004.global.ds.honeywell.com>
Content-Type: text/plain; charset="us-ascii"
Hi!
When I executed uhd_usrp_probe, the fpga image was automatically downloaded and
installed. I had run through this step before writing to the list as well. The
apps continue to freeze.
Im guessing the uhd_fft would not have shown me a snapshot of the correct FM
radio stations if the firmware hadn't been installed properly?
Is there anything else I can try?
Regards,
Soumen
From: Ralph A. Schmid, dk5ras [mailto:[email protected]]
Sent: Tuesday, October 21, 2014 11:40 AM
To: Banerjee, Soumen; [email protected]
Subject: RE: [USRP-users] UHD Apps freeze with USRPB210
This sounds similar to my actual experiences. With the last release the USB
disconnect problems are gone, but especially at higher sampling rates the
system freezes after seconds up to one minute. Command line programs then show
errors like this one:
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or invalid packet length
UHD source block got error code 0xf
At the moment I have no idea what is happening, the whole thing is far from
being usable at the moment, while it operates under Windows on the same PC for
hours, so at least the hardware is OK.
OS is Kubuntu 14.04 32 bit low latency.
Unfortunately I was not able to build uhd on my Kubuntu 12 system, compile
stops with some nirio error, but I do not have the time at the moment to go
deeper into this.
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of
Banerjee, Soumen via USRP-users
Sent: Monday, October 20, 2014 6:08 AM
To: [email protected]<mailto:[email protected]>
Subject: [USRP-users] UHD Apps freeze with USRPB210
Greetings!
I managed to install gnuradio and uhd and it seems to be able to detect the
usrp device. It shows up in the output of lsusb.
I was trying out the simple fm radio demonstration and that one kept crashing.
No debug output, nothing. It just froze. So I thought Ill look at the basics
and tried to run the uhd_fft app (from path). I put the sampling frequency in
the FM band since I know the FM stations over here and I was able to see peaks
at the expected frequencies, but its not a continuous FFT. It just freezes
immediately after the first graph is plotted. Is there something that Im
missing? Im inclined to think that the installation went all right because the
peaks in the snapshot FFT match so well with the expected radio stations!
I noted that someone else has had this problem with a N210 before, and they
solved it by updating the OS and playing around with the Ethernet settings, but
Im connected to the B210 over USB, so that method can't be tried.
Any suggestions?
Thanks!
Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/5abcc03e/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 21 Oct 2014 16:08:22 +0700
From: Luong Tan Phong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UBX daughter board
Message-ID:
<caa8yxsromzwh0sgu10ttpservpnl7glaqllixnikokutrfm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi List,
I've read GRCON14 documents and found that Ettus will release UBX daughter
board.
Could you tell me when I can buy it, please?
BRs.
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/654a0c59/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 21 Oct 2014 13:11:03 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Keep transmitted signal in USRP to overcome
the limited host sample rate of E100/E110
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jack,
the FPGA is not a storage device, and even if you could use all the
block RAM on the FPGA and add some more memory by using logic cells, you
won't store /much/ on the moderately sized E100 FPGA or even on the
E110's one. So, you'd be limited to short bursts of TX samples.
The question whether something is "simple work" heavily depends on the
experience of the one doing that work. Since you ask, I assume you're
not very experienced doing FPGA development; as that seems to exhibit a
rather steep learning curve, I'm afraid the answer is "it's not simple".
Greetings,
Marcus
On 17.10.2014 09:38, Jack via USRP-users wrote:
> Hi -
>
> As you know, embedded series, E100/E110, has the limited host sample rate,
> just only 4MS/s. But I want to send bigger signal bandwidth (ex. 20Mhz).
>
> My idea to overcome this issue is to keep the transmitted signal inside
> FPGA. But I have not started to work on this yet. Have anyone tried to do
> so? Could you share your experience? Is it possible? Simple work? or
> Complicated work?
>
> Best Regards,
> Jack
>
>
>
> _______________________________________________
> 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/20141021/68203612/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 21 Oct 2014 19:29:56 +0800
From: Liwei <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID:
<cape0sywzorjkxxtsrprjgfpkvftykdm2vno7ct71eupz6tr...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Marcus,
Not multiple N210s. I've just tried out the spare N210, and it is
working fine for both TX and RX. I think this possibly narrows it down
to a hardware issue with the N210. Any way to figure out what is
wrong?
Thanks
Liwei
On 20 October 2014 23:21, <[email protected]> wrote:
> This issue survives multiple computers, and multiple N210s?
>
>
>
> Again, make sure that Network Manager isn't "owning" the device and turning
> it off due to failed DHCP.
>
>
>
>
>
>
>
>
>
> On 2014-10-20 10:24, Liwei wrote:
>
> Hi all,
> Sigh, should have known I'm not lucky enough to have this go away.
> Couldn't get transmit to work without stopping when I checked in
> today. Did the same things I did yesterday to try to replicate the
> result, but no go.
> So here's the information requested.
> Unfortunately, I can't get tx_waveforms running long enough to see
> it do anything on top, even with delay set to 0.5s. id hovers above
> 95% and us hovers below 4% or so:
> %Cpu(s): 1.0 us, 0.5 sy, 0.0 ni, 98.5 id, 0.0 wa, 0.0 hi,
> 0.0 si, 0.0 st
> tx_waveforms seems to be doing nothing once transmission stops:
> PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 4554 xieliwei -51 0 173568 11876 10756 S 0.0 0.1
> 0:00.09 tx_waveforms
> Here's how running tx_waveforms look like, the "S" appears
> instantly and nothing gets transmitted:
> $ /usr/lib/uhd/examples/tx_waveforms --rate 200000 --freq 144300000
> --gain 20 --wave-type CONST
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-6-gbde8e9a3
>
>
> Creating the usrp device with: ...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> Using Device: Single USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N210r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: WBXv3 RX+GDB
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: WBXv3 TX+GDB
>
> Setting TX Rate: 0.200000 Msps...
> Actual TX Rate: 0.200000 Msps...
>
> Setting TX Freq: 144.300000 MHz...
> -- Tune Request: 144.300000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 144.300000 MHz
> -- RF LO Result: 144.299451 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: 0.000549 MHz
> -- DSP Result: 0.000549 MHz
> -- Successfully tuned to 144.300000 MHz
> --
> Actual TX Freq: 144.300000 MHz...
>
> Setting TX Gain: 20.000000 dB...
> Actual TX Gain: 20.000000 dB...
>
> Setting device timestamp to 0...
> Checking TX: LO: locked ...
> Press Ctrl + C to stop streaming...
> S
>
>
> As for NetworkManager being the cause, I have it set to manual
> configuration, no go. It won't explain how receive works fine while
> transmit stops too, and the problem is the same on OS X on an entirely
> different laptop. Nothing in the system logs too.
>
> I'm starting to suspect that the N210 I have is faulty.
>
> Thanks
> Liwei
>
>
> On 20 October 2014 02:17, Liwei <[email protected]> wrote:
>
> Hi all, My mind is officially blown now. Everything suddenly works. After
> returning the MacBook to my friend, I started collecting the data Marcus
> asked for. The first thing I did was to load new firmware with
> usrp_n2xx_simple_net_burner (since the UHD version on my laptop is newer
> than the one from macports on the MBP). Next I tried to run the tx_waveforms
> test as suggested. I was expecting the same result since tx_waveforms should
> behave similar to uhd_siggen. To my surprise, it actually worked without
> issue. So I went back to uhd_siggen thinking maybe the problem lies with
> gnuradio. Again, I was surprised when it actually worked fine. Then I tried
> the test flow graph, then the flow graph I was working on, on fast ethernet,
> on the USB3 gigabit ethernet adapter, and even Wi-Fi. Now I have uhd_siggen
> running at 2.5Msps over Wi-Fi for the past 15 minutes without issue. 3 weeks
> recompiling different UHD/GNURadio versions, power cycling, firmware
> updating, swapping network devices around, network capturing, and things
> suddenly start working without clear explanation. So there are a few things
> that could have solved the problem: 1. Switching to the older
> firmware/UHD/gnuradio version from the MBP 2. Switching back to the new
> firmware/UHD/gnuradio version from my laptop 3. Running tx_waveforms (does
> it do anything especially different from uhd_siggen?) 4. Sentience, I did
> hint in my previous email of replacing this USRP unit with the spare ;) To
> be sure, I just power cycled the N210 and rebooted my laptop. Still works.
> Hopefully this holds up and what I've provided so far is of use in figuring
> out what exactly was happening. Thanks Liwei On 20 October 2014 00:55, Liwei
> <[email protected]> wrote:
>
> Whoops, attached the generated python instead of the flow graph. See
> attached. On 20 October 2014 00:50, Liwei <[email protected]> wrote:
>
> Hello Marcus, Marcus, Thanks for the reply. I'll get back to what the two of
> you have asked me to check in the next email. At the moment, I managed to
> get myself a mid-2010 MacBook Pro (running OS 10.10) from a friend. It runs
> on a 2.66GHz i7-620M (Arrandale) processor with a BCM5701 gigabit ethernet
> controller.
>
> --Snip--
------------------------------
Message: 16
Date: Tue, 21 Oct 2014 08:52:45 -0400
From: "Marcus D. Leech" <[email protected]>
To: Liwei <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 Stops Transmitting
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/21/2014 07:29 AM, Liwei wrote:
> Hi Marcus,
> Not multiple N210s. I've just tried out the spare N210, and it is
> working fine for both TX and RX. I think this possibly narrows it down
> to a hardware issue with the N210. Any way to figure out what is
> wrong?
>
> Thanks
> Liwei
You've tried different ethernet cables?
Otherwise, send a note to [email protected]
>
> On 20 October 2014 23:21, <[email protected]> wrote:
>> This issue survives multiple computers, and multiple N210s?
>>
>>
>>
>> Again, make sure that Network Manager isn't "owning" the device and turning
>> it off due to failed DHCP.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2014-10-20 10:24, Liwei wrote:
>>
>> Hi all,
>> Sigh, should have known I'm not lucky enough to have this go away.
>> Couldn't get transmit to work without stopping when I checked in
>> today. Did the same things I did yesterday to try to replicate the
>> result, but no go.
>> So here's the information requested.
>> Unfortunately, I can't get tx_waveforms running long enough to see
>> it do anything on top, even with delay set to 0.5s. id hovers above
>> 95% and us hovers below 4% or so:
>> %Cpu(s): 1.0 us, 0.5 sy, 0.0 ni, 98.5 id, 0.0 wa, 0.0 hi,
>> 0.0 si, 0.0 st
>> tx_waveforms seems to be doing nothing once transmission stops:
>> PID USER PR NI VIRT RES SHR S %CPU %MEM
>> TIME+ COMMAND
>> 4554 xieliwei -51 0 173568 11876 10756 S 0.0 0.1
>> 0:00.09 tx_waveforms
>> Here's how running tx_waveforms look like, the "S" appears
>> instantly and nothing gets transmitted:
>> $ /usr/lib/uhd/examples/tx_waveforms --rate 200000 --freq 144300000
>> --gain 20 --wave-type CONST
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-6-gbde8e9a3
>>
>>
>> Creating the usrp device with: ...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> Using Device: Single USRP:
>> Device: USRP2 / N-Series Device
>> Mboard 0: N210r4
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: WBXv3 RX+GDB
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: WBXv3 TX+GDB
>>
>> Setting TX Rate: 0.200000 Msps...
>> Actual TX Rate: 0.200000 Msps...
>>
>> Setting TX Freq: 144.300000 MHz...
>> -- Tune Request: 144.300000 MHz
>> -- The RF LO does not support the requested frequency:
>> -- Requested LO Frequency: 144.300000 MHz
>> -- RF LO Result: 144.299451 MHz
>> -- Attempted to use the DSP to reach the requested frequency:
>> -- Desired DSP Frequency: 0.000549 MHz
>> -- DSP Result: 0.000549 MHz
>> -- Successfully tuned to 144.300000 MHz
>> --
>> Actual TX Freq: 144.300000 MHz...
>>
>> Setting TX Gain: 20.000000 dB...
>> Actual TX Gain: 20.000000 dB...
>>
>> Setting device timestamp to 0...
>> Checking TX: LO: locked ...
>> Press Ctrl + C to stop streaming...
>> S
>>
>>
>> As for NetworkManager being the cause, I have it set to manual
>> configuration, no go. It won't explain how receive works fine while
>> transmit stops too, and the problem is the same on OS X on an entirely
>> different laptop. Nothing in the system logs too.
>>
>> I'm starting to suspect that the N210 I have is faulty.
>>
>> Thanks
>> Liwei
>>
>>
>> On 20 October 2014 02:17, Liwei <[email protected]> wrote:
>>
>> Hi all, My mind is officially blown now. Everything suddenly works. After
>> returning the MacBook to my friend, I started collecting the data Marcus
>> asked for. The first thing I did was to load new firmware with
>> usrp_n2xx_simple_net_burner (since the UHD version on my laptop is newer
>> than the one from macports on the MBP). Next I tried to run the tx_waveforms
>> test as suggested. I was expecting the same result since tx_waveforms should
>> behave similar to uhd_siggen. To my surprise, it actually worked without
>> issue. So I went back to uhd_siggen thinking maybe the problem lies with
>> gnuradio. Again, I was surprised when it actually worked fine. Then I tried
>> the test flow graph, then the flow graph I was working on, on fast ethernet,
>> on the USB3 gigabit ethernet adapter, and even Wi-Fi. Now I have uhd_siggen
>> running at 2.5Msps over Wi-Fi for the past 15 minutes without issue. 3 weeks
>> recompiling different UHD/GNURadio versions, power cycling, firmware
>> updating, swapping network devices around, network capturing, and things
>> suddenly start working without clear explanation. So there are a few things
>> that could have solved the problem: 1. Switching to the older
>> firmware/UHD/gnuradio version from the MBP 2. Switching back to the new
>> firmware/UHD/gnuradio version from my laptop 3. Running tx_waveforms (does
>> it do anything especially different from uhd_siggen?) 4. Sentience, I did
>> hint in my previous email of replacing this USRP unit with the spare ;) To
>> be sure, I just power cycled the N210 and rebooted my laptop. Still works.
>> Hopefully this holds up and what I've provided so far is of use in figuring
>> out what exactly was happening. Thanks Liwei On 20 October 2014 00:55, Liwei
>> <[email protected]> wrote:
>>
>> Whoops, attached the generated python instead of the flow graph. See
>> attached. On 20 October 2014 00:50, Liwei <[email protected]> wrote:
>>
>> Hello Marcus, Marcus, Thanks for the reply. I'll get back to what the two of
>> you have asked me to check in the next email. At the moment, I managed to
>> get myself a mid-2010 MacBook Pro (running OS 10.10) from a friend. It runs
>> on a 2.66GHz i7-620M (Arrandale) processor with a BCM5701 gigabit ethernet
>> controller.
>>
>> --Snip--
------------------------------
Message: 17
Date: Tue, 21 Oct 2014 09:58:06 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Michael,
Thanks for your reply.
We changed the threshold to 15 and now we get calibration data written to file
for each freq step.
Q: What is the reason the threshold is set to 30? Is there any reason I should
not set it to 15 or any other value? Is there is a reason this parameter value
is hard coded and is not something you can pass in as an argument?
Regardless, the original problem I wanted to solve by calibrating in finer
frequency steps still remains, namely, the residual IQ imbalance is too large
in certain bands.
I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz in 200kHz
steps, thinking that should do it.
To check for any residual IQ imbalance I then generated a complex exponential
with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs = 6.25 MHz, and
set tx gain to 0dB (using GnuRadio flowdiagram).
I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to 3000 MHz,
measured the power-ratio between fc+f and the undesired replica at fc-f which
is due to residual IQ imbalance.
fc (MHz) P_(fc-f)/P_(fc+f) (dB)
700 -40
800 -23
900 -17
1000 -22
1100 -27
1200 -40
1300 -12
1400 -15
1500 -40
1600 -40
1700 -21
1800 -13
1900 -40
2000 to small to measure (-infinity)
2100 -12
2200 -14
2300 to small to measure (-infinity)
... ...
3000 to small to measure (-infinity)
I thought that by calibrating the residual IQ imbalance would result in a power
ratio of at least < -40dB between the undesired replica at fc-f and the
original signal at fc+f.
Maybe my expectations are too high, or perhaps I have a bad SBX daughterboard?
Q: What results should I realistically be able to expect using the N210 + SBX
combination?
Regards,
Urban
----- Original Message -----
From: "Michael West" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Thursday, October 9, 2014 3:03:08 PM
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Hi Urban,
If I am understanding you correctly, you are saying that there is no
calibration data for those frequencies in the resulting file. That does not
mean the frequencies are being skipped by the utility. That only means that a
suppression of over 30 dB could not be achieved for those frequencies, so no
correction data was saved. You can set a lower threshold for the minimum
suppression by changing the value in the following line in each IQ calibration
utility:
if (best_suppression > 30){ //most likely valid, keep result
Best regards,
Michael
On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
[email protected] > wrote:
Hi everybody,
I am trying to calibrate my N210 SBX daughterboard using the three calibration
scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and uhd_cal_tx_dc_offset
using different values for freq_start, freq_stop, and freq_step.
uhd_cal_tx_iq_balance utility that is not behaving as I expected.
(uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
If I run uhd_cal_tx_iq_balance with any other values besides the default values
it will skip approximately 300MHz of frequencies from 790 MHz to ~ 1100MHz.
Here are a few of my attempts.
uhd_cal_tx_iq_balance --freq_start 500000000
uhd_cal_tx_iq_balance --freq_start 600000000
uhd_cal_tx_iq_balance --freq_start 700000000
uhd_cal_tx_iq_balance --freq_start 785000000
uhd_cal_tx_iq_balance --verbose --freq_step 100000
uhd_cal_tx_iq_balance --verbose --freq_step 110000
uhd_cal_tx_iq_balance --verbose --freq_step 225000
uhd_cal_tx_iq_balance --verbose --freq_step 900000
uhd_cal_tx_iq_balance --verbose --freq_step 1000000
uhd_cal_tx_iq_balance --verbose --freq_step 1100000
uhd_cal_tx_iq_balance --verbose --freq_step 2000000
...
uhd_cal_tx_iq_balance --verbose --freq_step 7300000
uhd_cal_tx_iq_balance always stops just before 790MHz and just sits there, but
does not abort, and after a really long time continues at ~ 1100MHz and
continues all the way to 4370MHz without any further gaps.
I attach the calibration scripts I am using and the three csv files for one
example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
General background information about my environment:
Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
Boost_104800; UHD_003.007.001-0-unknown
N210 informationfrom uhd_usrp_probe:
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: 00:80:2f:0a:e6:15
| | ip-addr: 192.168.2.199
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: F4A09C
| | FW Version: 12.4
| | FPGA Version: 10.1
What could the cause of this behaviour be? Are there only certain combination
of values that work? What do I need to do to make uhd_tx_iq_balance not hang
right before 790MHz?
Thanks for you consideration.
Regards,
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410 872 6315
Fax: +1 410 872 6010 Email: [email protected]
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/22850f45/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 21 Oct 2014 14:18:32 +0000 (UTC)
From: Ben ROBERT <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Boost Requirements (Was: 3.8.0 build issues
on centos 6)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Martin Braun via USRP-users <usrp-users@...> writes:
>
> On 10/15/2014 12:21 AM, Stan Vitebsky via USRP-users wrote:
> > I have trouble building newly released uhd 3.8.0 on Centos 6 (3.10.33
> > kernel).
> > [...]
> > I suppose this is because this file doesn't exist in boost 1.41, which
> > is default for Centos 6.
> > Does this mean that Centos 6 will no longer be supported by uhd?
>
> Everyone,
>
> we will indeed be bumping our minimum Boost version to 1.46 for 3.8.0.
> As you've already discussed in this thread, this doesn't mean we CentOS
> 6 won't work anymore, as it's a simple matter to update Boost.
> If you're using PyBombs to install UHD, this will automate the process
> for you.
>
> A short note on distros: We will make an effort to make UHD build on any
> not-too-old Linux (and other OSes) that meet our dependencies, but we
> mainly test on current Ubuntu and Fedora versions (those for which we
> also provide binary installers), Mac OS X and Windows 7. If it doesn't
> matter to you which distro you're using, we thus recommend Ubuntu or
> Fedora, but as I said, we'll do our best to write portable code to make
> it work on most platforms.
>
> Cheers,
> Martin
>
Hi everybody,
I am trying to build UHD 3.8.0 on Ubuntu LTS 12.04 and I am facing the same
problem with file shared_lock_guard.hpp missing.
I have libboost-all-dev 1.48.0.2 installed. May be a higher version of boost
library is required.
Cheers,
Benoit
------------------------------
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 50, Issue 20
******************************************
