Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Overflow with USRP N 210 --I receive oooooooooooooooooo
(Josh Blum)
2. Re: FPGA code about IQ balance (Matt Ettus)
3. Re: GPSDO on usrp2 (Dario Lombardo)
4. Re: FPGA code about IQ balance (???)
5. Different behavior in fft window depending on central
frequency (Lu?s Correia)
----------------------------------------------------------------------
Message: 1
Date: Tue, 05 Jun 2012 09:14:50 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Overflow with USRP N 210 --I receive
oooooooooooooooooo
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/05/2012 05:40 AM, zitouni rafik wrote:
> Hello for All,
>
> I use USRP N 210, When I run a receiver after some period of time i receive
> "OOOOOOOOOOOOOO". Is it overflow? Can you tell me how I fix this issue?
>
>
In your last email you stated that you were using 10/100 Ethernet... is
that the case? Does 4 bytes per complex samples exceed your link
bottleneck at the chosen sample rate?
And if thats not the case, see these notes here:
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes
-josh
------------------------------
Message: 2
Date: Tue, 5 Jun 2012 14:49:40 -0700
From: Matt Ettus <[email protected]>
To: ??? <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] FPGA code about IQ balance
Message-ID:
<CAN=1kn-yt+04+=pAhFL=qcve9b1shxaou7jnokqwqdwx6mo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The USRP1 really doesn't have enough FPGA resources to do the corrections
which we do in the newer devices. With some programming, you can do some
gain correction (but not phase correction) in the AD9862 codec chip, or
under some circumstances, you can do the correction on the host.
Matt
On Tue, Jun 5, 2012 at 7:37 AM, ??? <[email protected]> wrote:
> Dear everyone:
> In fpga/usrp2/sdr_lib/, there is tx_frontend.v, rx_frontend.v,
> rx_dcoffset.v, which are to deal with the problems of dc offset and IQ
> balance. While in fpga/usrp1/sdr_lib/, there are not
> tx_frontend.v or rx_frontend.v, and rx_dcoffset.v is different with that in
> usrp2 codes.
> Does that mean usrp1 does not deal with the problem of dc offset and IQ
> balance or deal with them in a simpler way? What cause this difference
> between usrp1 and usrp2? I wonder if in usrp1 dc offset and IQ balance are
> dealt with in the codes of c++ and python.
> Any of your replies will be very appreciated.
>
>
>
> _______________________________________________
> 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/20120605/42531fc0/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 6 Jun 2012 09:41:25 +0200
From: Dario Lombardo <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID:
<CAOYJJfv=w+ewzx9ocq9p_vrenmcwacl9tfq+qutyxibqmgk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Well, actually the behaviour changes if I set what you say. With eeprom gps
set to none, the offset given by kal canges.
With -x kal gives me 18kHz (or 15, like before). Without -x it gives me
220Hz.
$ /usr/local/share/uhd/utils/usrp_burn_mb_eeprom --key gpsdo
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_003.004.002-128-g12f7a5c9
Creating USRP device from address:
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Fetching current settings from EEPROM...
EEPROM ["gpsdo"] is "none"
Done
$ ./kal -c 37
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_003.004.002-128-g12f7a5c9
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.270833 MSps
Actual sample rate: 0.271739 MSps
kal: Calculating clock frequency offset.
Using GSM-900 channel 37 (942.4MHz)
average [min, max] (range, stddev)
+ 220Hz [186, 243] (57, 18.392006)
overruns: 0
not found: 0
$ ./kal -c 37 -x
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_003.004.002-128-g12f7a5c9
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.270833 MSps
Actual sample rate: 0.271739 MSps
kal: Calculating clock frequency offset.
Using GSM-900 channel 37 (942.4MHz)
average [min, max] (range, stddev)
- 18.752kHz [-18917, -18592] (325, 87.049797)
overruns: 0
not found: 0
On Tue, Jun 5, 2012 at 4:13 PM, Nick Foster <[email protected]> wrote:
> This is very strange. 15kHz is more offset than you should see from the
> Firefly device even if it has no GPS signal.
>
> Can you verify that:
> 1) the offset changes when you select an internal reference (set the GPS
> EEPROM setting to none), and
> 2) use a signal generator or another known RF source to verify this 15kHz
> offset? At this point I'm starting to suspect kal is leading you astray.
>
> --n
>
> On Tue, Jun 5, 2012 at 2:46 AM, Dario Lombardo <
> [email protected]> wrote:
>
>> What I can see now is both ref_locked and gpd_locked. But if I run kal I
>> still have 15kHz of offset.
>> Which further steps can I do?
>>
>> On Tue, Jun 5, 2012 at 10:56 AM, Haris Kremo <[email protected]>wrote:
>>
>>> Dario,
>>>
>>> Putting aside the error below, the GPGGA sentence claims your device is
>>> locked to the satellite signal. It sees 9 satellites and in conjunction
>>> with Google maps claims you are in Torino.
>>>
>>> http://aprs.gids.nl/nmea/#gga
>>>
>>> From what I understand, ref_lock tells whether the internal USRP clock
>>> is locked to the GPSDO or an external reference.
>>>
>>> Hope that helps,
>>>
>>> H.
>>>
>>> On 6/5/2012 4:39 PM, Dario Lombardo wrote:
>>>
>>> Ryan
>>>
>>> it compiles and runs perfectly. There's the output
>>>
>>> $ ./test_gpsdo
>>> linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
>>> UHD_003.004.002-128-g12f7a5c9
>>>
>>>
>>> Creating the usrp device with: ...
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>> -- Found a Jackson Labs GPS
>>> -- Setting references to the internal GPSDO
>>> -- Initializing time to the internal GPSDO
>>> Using Device: Single USRP:
>>> Device: USRP2 / N-Series Device
>>> Mboard 0: N210r4
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: RFX900 RX
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: RFX900 TX
>>>
>>>
>>> Querying gps_time sensor...
>>> Sensor output: GPS epoch time: 1338881388 seconds
>>>
>>>
>>> Querying gps_locked sensor...
>>> Sensor output: GPS lock status: locked
>>>
>>>
>>> Querying ref_locked sensor...
>>> Sensor output: Ref: unlocked
>>>
>>>
>>> Querying gps_gpgga sensor...
>>> ensor output: GPS_GPGGA: $GPGGA,072949.00,4506.7212,N,0740.3228
>>> ,E,2,09,1.1,271.7,M,47.2,M,,*5C
>>>
>>>
>>> Querying gps_gprmc sensor...
>>> ensor output: GPS_GPRMC: $GPRMC,072950.00,A,4506.7212,N,0740.3228
>>> ,E,1.1,0.0,050612,,*03
>>>
>>>
>>> Querying gps_gpgsa sensor...
>>> Error: LookupError: Path not found in tree: /mboards/0/sensors/gps_gpgsa
>>>
>>> Which output should be taken into account, gps_locked, or ref_locked?
>>> If ref_locked, I think that the "clear view of the sky" should be
>>> improved... since a small roof out of my window could partially hide the
>>> sky. I can try to move my equipment to the courtyard. Should it be useful?
>>>
>>> On Mon, Jun 4, 2012 at 8:57 PM, Ryan Connelly <
>>> [email protected]> wrote:
>>>
>>>> The GPS antenna should have a clear unobstructed view of the sky. Also
>>>> if the GPS antenna has a little metal dimple on one of its sides, it
>>>> has to be facing up towards the sky.
>>>>
>>>> Here is a C++ program written by someone a while back to check GPS
>>>> sensors. I don't know if it still works but that gives you an idea of
>>>> how to query the sensor info. One of the sensors outputs the GGA info
>>>> as an NMEA string. Here's a link to read the string:
>>>> http://www.gpsinformation.org/dale/nmea.htm#GGA
>>>>
>>>>
>>>> ---------------------file:
>>>>
>>>> test_gpsdo.cpp--------------------------------------------------------------------
>>>> --------------------example compile: g++ -luhd
>>>> -lboot_program_options-mt test_gpsdo.cpp -o test_gpsdo -------
>>>> --------------------example usage: ./test_gpsdo --args
>>>> "addr=192.168.10.2"-----------------------------------
>>>>
>>>> // author: Anonymous ( based on
>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions
>>>> //
>>>> /6bd7281f83d5311675847b31746525841657c057/entry/host/examples/test_pps_input.cpp
>>>> )
>>>> // date: 2012/02/16
>>>> // purpose: access gpsdo information (by querying all the gpsdo
>>>> sensors) and output results to console
>>>>
>>>> #include <uhd/utils/thread_priority.hpp>
>>>> #include <uhd/utils/safe_main.hpp>
>>>> #include <uhd/usrp/multi_usrp.hpp>
>>>> #include <boost/program_options.hpp>
>>>> #include <boost/format.hpp>
>>>> #include <boost/thread.hpp>
>>>> #include <iostream>
>>>> #include <complex>
>>>>
>>>> namespace po = boost::program_options;
>>>> int UHD_SAFE_MAIN(int argc, char *argv[]){
>>>>
>>>> uhd::set_thread_priority_safe();
>>>>
>>>> //variables to be set by po
>>>> std::string args;
>>>>
>>>> //setup the program options
>>>> po::options_description desc("Allowed options");
>>>> desc.add_options()
>>>> ("help", "help message")
>>>> ("args", po::value<std::string>(&args)->default_value(""),
>>>> "single uhd device address args")
>>>> ;
>>>>
>>>> po::variables_map vm;
>>>> po::store(po::parse_command_line(argc, argv, desc), vm);
>>>> po::notify(vm);
>>>>
>>>> //print the help message
>>>> if (vm.count("help")){
>>>> std::cout << boost::format("UHD Test PPS Input %s") % desc <<
>>>> std::endl;
>>>> return ~0;
>>>> }
>>>>
>>>> //create a usrp device
>>>> std::cout << std::endl;
>>>> std::cout << boost::format("Creating the usrp device with: %s...")
>>>> % args << std::endl;
>>>> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>>>> std::cout << boost::format("Using Device: %s") %
>>>> usrp->get_pp_string() << std::endl;
>>>>
>>>> //query gpsdo sensors and output to console
>>>> //gps_time sensor
>>>> std::cout << std::endl << "Querying gps_time sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_gps_time =
>>>> usrp->get_mboard_sensor("gps_time",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_gps_time.to_pp_string() << std::endl << std::endl;
>>>> //gps_locked sensor
>>>> std::cout << std::endl << "Querying gps_locked sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_gps_locked =
>>>> usrp->get_mboard_sensor("gps_locked",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_gps_locked.to_pp_string() << std::endl << std::endl;
>>>> //ref_locked sensor
>>>> std::cout << std::endl << "Querying ref_locked sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_ref_locked =
>>>> usrp->get_mboard_sensor("ref_locked",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_ref_locked.to_pp_string() << std::endl << std::endl;
>>>> //gps_gpgga sensor
>>>> std::cout << std::endl << "Querying gps_gpgga sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_gps_gpgga =
>>>> usrp->get_mboard_sensor("gps_gpgga",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_gps_gpgga.to_pp_string() << std::endl << std::endl;
>>>> //gps_gprmc sensor
>>>> std::cout << std::endl << "Querying gps_gprmc sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_gps_gprmc =
>>>> usrp->get_mboard_sensor("gps_gprmc",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_gps_gprmc.to_pp_string() << std::endl << std::endl;
>>>> //gps_gpgsa sensor
>>>> std::cout << std::endl << "Querying gps_gpgsa sensor..." <<
>>>> std::endl;
>>>> uhd::sensor_value_t val_gps_gpgsa =
>>>> usrp->get_mboard_sensor("gps_gpgsa",0);
>>>> std::cout << boost::format("Sensor output: %s") %
>>>> val_gps_gpgsa.to_pp_string() << std::endl << std::endl;
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> -----------------------------------------------------------
>>>>
>>>>
>>>> On Mon, Jun 4, 2012 at 2:19 PM, Dario Lombardo
>>>> <[email protected]> wrote:
>>>> >
>>>> >
>>>> > On Mon, Jun 4, 2012 at 8:03 PM, Nick Foster <[email protected]> wrote:
>>>> >>
>>>> >> I guess I suspect that you aren't getting a valid GPS signal.
>>>> >
>>>> >
>>>> > It's what others have suggested. But I don't know how to improve it.
>>>> >
>>>> >>
>>>> >> I'd suggest doing a little coding and checking the GPSDO lock status,
>>>> >> probably easiest to modify the UHD examples.
>>>> >
>>>> >
>>>> > Can you suggest one to start from?
>>>> >
>>>> >>
>>>> >> What antenna are you using?
>>>> >
>>>> >
>>>> > It's a GPS/GSM antenna (antennas are packed together, with separate
>>>> cables
>>>> > to go to the board).
>>>> >
>>>> >>
>>>> >> Does it have a clear view of the sky?
>>>> >
>>>> >
>>>> > More or less. I'm in a building and the usrp is in my office. Inside
>>>> the
>>>> > building I can't get the GPS signal, but I can get it close to my
>>>> window (I
>>>> > mean with other GPS equipments). I don't know how clean the GPS
>>>> signal must
>>>> > be caught.
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing
>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> _______________________________________________
>> 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/20120606/0c2d95c1/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 6 Jun 2012 16:54:32 +0800 (CST)
From: ??? <[email protected]>
To: "Matt Ettus" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] FPGA code about IQ balance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
Thank you very much for the reply.
Besides FPGA, I also noticed in host\utils there are c++ codes such as
uhd_cal_rx_iq_balance.cpp, uhd_cal_tx_iq_balance.cpp and so on. So what is the
relationship between them? Do the c++ files represent something like the upper
layer API and when used they call the bottom layer FPGA codes? If so, when we
write applications, is extra IQ balance codes in c++ or python necessary
besides FPGA?
Best regards
At 2012-06-06 05:49:40,"Matt Ettus" <[email protected]> wrote:
The USRP1 really doesn't have enough FPGA resources to do the corrections which
we do in the newer devices. With some programming, you can do some gain
correction (but not phase correction) in the AD9862 codec chip, or under some
circumstances, you can do the correction on the host.
Matt
On Tue, Jun 5, 2012 at 7:37 AM, ??? <[email protected]> wrote:
Dear everyone:
In fpga/usrp2/sdr_lib/, there is tx_frontend.v, rx_frontend.v,
rx_dcoffset.v, which are to deal with the problems of dc offset and IQ balance.
While in fpga/usrp1/sdr_lib/, there are not tx_frontend.v or rx_frontend.v, and
rx_dcoffset.v is different with that in usrp2 codes.
Does that mean usrp1 does not deal with the problem of dc offset and IQ
balance or deal with them in a simpler way? What cause this difference between
usrp1 and usrp2? I wonder if in usrp1 dc offset and IQ balance are dealt with
in the codes of c++ and python.
Any of your replies will be very appreciated.
_______________________________________________
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/20120606/698138b6/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 6 Jun 2012 13:23:52 +0100
From: Lu?s Correia <[email protected]>
To: [email protected]
Subject: [USRP-users] Different behavior in fft window depending on
central frequency
Message-ID:
<CAOt7J2HBRuBPmqXyBJt1dvCjb=txqx7t0kmlrvab8sldp5d...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all!
I have a B100 with a WBX and a couple of VERT900 antennas.
I'm getting completely different readings in the uhd_fft utility depending
on the center frequency.
For example, if I center at 896M I get a peak at 896.2M. But if I center at
896.3M, the 896.2M peak seen earlier disappears..
Also using the RX2 antenna I always get a center peak, no matter the
frequency.
Is this normal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120606/c20fa4d0/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 6
*****************************************
