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: Synchronizing Data Streams from multiple N210 boards on
FPGA (Josh Blum)
2. Re: Object for spi_iface (Ben Hilburn)
3. Re: FW: Config N210 with Microblaze (Ian Buckley)
4. FW: Config N210 with Microblaze (Huldi Michael)
5. Re: GPSDO on usrp2 (Dario Lombardo)
6. Connecting a test signal source to the SBX's RX2 (Ryan Connelly)
7. Re: Connecting a test signal source to the SBX's RX2
([email protected])
8. Re: Connecting a test signal source to the SBX's RX2
(Ryan Connelly)
9. Re: Connecting a test signal source to the SBX's RX2
([email protected])
10. Re: Connecting a test signal source to the SBX's RX2
(Ryan Connelly)
11. Re: Connecting a test signal source to the SBX's RX2
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Jun 2012 11:17:53 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Synchronizing Data Streams from multiple
N210 boards on FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/10/2012 03:01 PM, Yasir Javed wrote:
> We are working on a MIMO-OFDM system using two USRP N210s. We want our
> Synchronization algorithm to be implemented on FPGA instead of Software.
> The algorithm needs to process coherent DDC data samples from both boards.
>
> Is it possible to forward data from one N210 to another where I can
> implement the Synchronization logic?
Yes
> If so, how can I make one FPGA logic wait until I get samples at almost
> exactly the same time instant from the other board?
If you tell all DSP to stream at time X, you simply need to wait until
the same time appears at the front of the FIFO at each channel. In other
words, it will require a little alignment state machine. The time is a
64-bit tick count in the VITA IF packet.
> At what points in the verilog code would you suggest to make changes?
>
You may want to take a look at the packet router block in the usrp
core.v All the inputs and output data streams from the DSP and MIMO
cable can be found going into this module
> My understanding so far is that I can modify dsp_rx_glue.v to add custom
> processing on DDC out samples (bb_sample and bb_strobe). What I am not
> clear is where would I get samples from the other N210 board. My initial
> guess was to use MIMO cable. But it seems that MIMO cable is used for
> sharing timing information to synchronize capturing time, its not used for
> data transfers (Is my understanding right?). So the next solution I could
> think of was to send packets from one N210 to other. I am so far unable to
> figure out where I would be able to intercept data in that case. Secondly
> by the time one N210 is waiting for samples from other N210, the DDC out
> samples have to be saved somewhere (in a FIFO).. Is the network delay
> deterministic to decide a safe FIFO size? Thirdly, My understanding is that
> timing information is added in vita_rx_chain.v which comes after
> dsp_rx_glue.v where I can get DDC out samples, how can I figure out the
> timing information of DDC samples from both boards in dsp_rx_glue.v?
>
The custom DSP is more useful for working at the sample level, but I
think you will want to work at the packet level to handle alignment.
-josh
------------------------------
Message: 2
Date: Mon, 11 Jun 2012 13:18:38 -0700
From: Ben Hilburn <[email protected]>
To: Pertti Sepp?nen <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Object for spi_iface
Message-ID:
<caoevzklrhw0pqkwfmddkdokoqe5t88sbymgw3dn+svlsc08...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Perrti -
As you discovered, the SPI interface isn't exposed to the application. If
you want to be able to issue SPI commands from an application, you'll need
to modify UHD to expose new API calls for the purpose.
Sorry there's no easier way!
Cheers,
Ben
----------------------------
Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/>
On Sun, Jun 10, 2012 at 2:17 AM, Pertti Sepp?nen
<[email protected]>wrote:
> Hi,
>
> going thru the documentation & code on the SPI interface for usrp1 I did
> not manage to find a way how to construct an object for it. The interface
> is there and is used by for instance in codec_control. The latter has a
> constructor but it is not opened for an application programmer.
>
> Is there a way to use the SPI interface with usrp1 that I missed in my
> search or is there any other means to access the ADC/DAC registers from the
> application code?
>
> BR
> Pertti Sepp?nen
>
> _______________________________________________
> 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/20120611/d732d531/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 11 Jun 2012 15:51:32 -0700
From: Ian Buckley <[email protected]>
To: Huldi Michael <[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] FW: Config N210 with Microblaze
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
usrp_n2xx_net_burner.py expects FPGA configuration images to be in MCS format.
Look in Makefile.common to understand the correct invocation of promgen
-Ian
On Jun 11, 2012, at 7:38 AM, Huldi Michael wrote:
> Hi,
> I give you right that the problems with the tools of Xilinx not your issue
> is. But fact is if I add a elf-file from microblaze to a ise-project and
> generate the .bit file for an other hardware than USRP N210 so I can download
> the generated download.bit file via Jtag and it works.
> But if I generate the download.bit file on the same way and convert the
> generated download.bit file with the command "promgen -u 0x0 download.bit -p
> bin -w " to a .bin file, the net-burner doesn?t accept the file.
> Do you have an idea how I can solve this problem on a simple way. Because to
> write some extra zpu-firmware is too complex.
> Thanks Michael
>
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Donnerstag, 7. Juni 2012 18:54
> To: Huldi Michael
> Cc: '[email protected]'
> Subject: Re: [USRP-users] Config N210 with Microblaze
>
> Michael, I'm a little confused by what your actual question is? It seems your
> having fundamental tactical problems loading a new FPGA image onto the N210,
> but the question you pose is architectural: "Is it possible to program the
> fpga with impact via JTAG? How could I insert the zpu firmware file in this
> case?"
>
> I'm not going to address your problems with using the Xilinx Microblaze SDK,
> that's a Xilinx proprietary flow and not something I, nor anyone at Ettus
> uses. But I'll try to give you some architectural guidelines how to add a new
> microprocessor to the N210:
>
> First, yes it's entirely possible to use impact to program the FPGA, this is
> how all new H/W is initially brought up. However note that unless you design
> the H/W to have an attached FLASH RAM in a way supported by impact for JTAG
> programming then you are only to directly configure the FPGA and that
> configuration will be lost every power cycle/reset. The USRP SPI flash is not
> programable via impact, so all non-volatile FPGA images and firmware images
> have to be burned under firmware & FPGA control.
>
> Now to boot an embedded microprocessor there are generally 2 different
> approaches:
> 1) The boot vector (PC after reset) directly addresses a discrete FLASH RAM
> that you can program externally (normally via JTAG)...this option doesn't
> exist for unmodified N210 H/W.
> 2) The boot vector addresses an internal stable boot ROM (a pre-initialized
> BRAM in a Xilinx) and the microcode in there performs a second stage boot,
> getting more firmware from elsewhere (FLASH RAM, network etc). This is how
> the stock N210 works with the ZPU and the attached SPI flash, which contains
> multiple FPGA and firmware images. In this case the ZPU boot's with the
> bootrom code in one BRAM, and uses this code to load the production firmware
> ware image from SPI FLASH to the other at which point it does a quick FPGA
> logic trick, swaps the MSB of the 2 BRAM's so that the boot vector now points
> to the other BRAM and toggles the ZPU reset line to cause a new (ZPU not
> FPGA) boot.
>
> Since you already have a working bootable and upgradable system in the stock
> N210, I strongly suggest the following approach:
> 1) Add your second microprocessor (I suggest reusing the ZPU, firmware
> libraries and tools..but you may have a compelling reason to learn and use
> Xilinx microblaze SDK) to the existing FPGA build methodology and continue to
> use the Ettus Makefile driven scripts to build and upload a new FPGA image
> via the network.
>
> 2) Make the BRAM(s) that contain the firmware for your new microprocessor
> exist also in the existing ZPU memory map. You can do this either by
> multiplexing them or making use of the dual port nature of BRAM.
>
> 3) Write some extra firmware for the existing ZPU so that it handles the
> download of your new microprocessors firmware from network to SPI flash and
> from SPI flash to BRAM exploiting all the TCP/IP based updater code that
> already exists. Boot your second microprocessor after and under the control
> of the original ZPU.
>
> This will be less work than you imagine since you will essentially be able to
> re-use all Josh's existing firmware code and the H/W design idea's behind the
> N210. You'll have a system quickly where you will not have to rebuild the
> FPGA every time you change firmware.
>
> Hope this helps,
> -Ian
>
>
>
>
>
>
> On Jun 7, 2012, at 5:53 AM, Huldi Michael wrote:
>
>
> Hello,
>
> I need help to get a simple microblaze configuration with bram-memory working
> with the USRP N210 release_003_004_001.
>
> I removed the tx chain and insert the microblaze in the top and connect 2 of
> the leds from the front to the microblaze gpio. Run a software with a
> blinking led function.
>
> I tried different ways to program the fpga without success:
>
> 1. add the elf-file from the microblaze to the ise-project and generate a
> .bin File with double click to "generate programming file" in ise, then
> download with net burner.
>
> 2. combine the bitstream with the elf file, which resides in the bram in SDK
> with "Programm FPGA" to a .bit file, then convert the generated file
> download.bit to a .bin file with "promgen -u 0x0 download.bit -p bin -w " and
> try to download with net burner. But the net burner says "Invalid FPGA image
> file".
>
> 3. Download with Platform Cable and with SDK, JTAG connected to the FPGA. But
> here it doesn't load the new configuration, since the leds I disconnect still
> light up in startup.
>
> I also changed the StartUpClk in the bitgen.ut from JTAGCLK to CCLK.
>
> Someone have an idea, how to make my configuration working? Is it possible to
> program the fpga with impact via JTAG? How could I insert the zpu firmware
> file in this case?
>
> Thanks for your help!
> Huldi
>
> _______________________________________________
> 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/20120611/7320b585/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 12 Jun 2012 11:16:26 +0200
From: Huldi Michael <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] FW: Config N210 with Microblaze
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Isn't the file in MCS format for loading directly to the Flash via Jtag? If I
convert the BIT file with the command "promgen -w -spi -p mcs -o $(MCS_FILE) -s
4096 -u 0 $(BIT_FILE)" the generated MCS file is around 3.9MB, that means four
times bigger than the BIT or BIN file.
I figured out that the net burner scan the BIN file for 0hAA99 to accept the
BIN file. If I combine the BIT file with the ELF file I overwrite this part.
Could you say me the meaning of this check? Is there perhaps a conflict between
the bootloader part and the program code from the microblaze?
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/d1f579bf/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 12 Jun 2012 11:20:40 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID:
<CAOYJJftVCxeMVC+_FXn=kwz681nutoeccnvvts+v6lbucwf...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all
I've written a small program that continuously polls the ref_locked and
gps_locked status. Both of them are always locked. But kal still gives me
an high error (8-10 kHz)
So there are some questions I can't answer:
1) how long doest it take to have an acceptable error? Minutes, hours,
days? In 1 hour of observation the error moved between 4 and 11 kHz
2) if I set the eeprom gpsdo to "internal" the gpsdo is always used, right?
That means that the external ref switch of softwares (like -x in kal) is
without effect (I mean, gpsdo is always used despite of the switch)
3) if I have a ref_locked but high error rate in kal, should I suspect that
gpsdo is broken, or that I failed/missed something?
Thanks a lot for the answers
Dario.
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/20120612/55a1da9d/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 12 Jun 2012 09:15:13 -0400
From: Ryan Connelly <[email protected]>
To: [email protected]
Subject: [USRP-users] Connecting a test signal source to the SBX's RX2
Message-ID:
<CAGfqHEgeaUsW6XTkxV=bAw0URjtNKWiKGd2D5d-CqFf=vu5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Is there any possibility of damaging the SBX board if I connect a test
signal source directly to the SBX? I want to connect from a 50 ohm SMA
connector that produces a signal source (1200MHz carrier) at -20dBm
nominal power directly to the SMA connector on the SBX for RX2. I
can't find any specs for the SBX max receive power.. Does anyone have
any links?
Thanks
R
------------------------------
Message: 7
Date: Tue, 12 Jun 2012 09:25:02 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Connecting a test signal source to the SBX's
RX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Jun 2012 09:15, Ryan Connelly wrote:
> Is there any
possibility of damaging the SBX board if I connect a test
> signal
source directly to the SBX? I want to connect from a 50 ohm SMA
>
connector that produces a signal source (1200MHz carrier) at -20dBm
>
nominal power directly to the SMA connector on the SBX for RX2. I
>
can't find any specs for the SBX max receive power.. Does anyone have
>
any links?
>
> Thanks
> R
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-20dBm
should be fine, but I wouldn't go any higher than that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/d34290bd/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 12 Jun 2012 11:06:52 -0400
From: Ryan Connelly <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Connecting a test signal source to the SBX's
RX2
Message-ID:
<CAGfqHEgUw6S1DWHr2Q+35dJ6AwwU2c7G8O_tqvj2w4N+r=s...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I did the connection and no smoke came out.. Good!
An FFT plot centered at the carrier frequency shows that the signal
does not exceed -25dBm so I don't think it is stressing the SBX board
too much. I agree with you though, I wouldn't want to go much higher
than that.
On Tue, Jun 12, 2012 at 9:25 AM, <[email protected]> wrote:
> On 12 Jun 2012 09:15, Ryan Connelly wrote:
>
> Is there any possibility of damaging the SBX board if I connect a test
> signal source directly to the SBX? I want to connect from a 50 ohm SMA
> connector that produces a signal source (1200MHz carrier) at -20dBm
> nominal power directly to the SMA connector on the SBX for RX2. I
> can't find any specs for the SBX max receive power.. Does anyone have
> any links?
>
> Thanks
> R
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -20dBm should be fine, but I wouldn't go any higher than that.
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Tue, 12 Jun 2012 11:10:10 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Connecting a test signal source to the SBX's
RX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Jun 2012 11:06, Ryan Connelly wrote:
> I did the connection
and no smoke came out.. Good!
>
> An FFT plot centered at the carrier
frequency shows that the signal
> does not exceed -25dBm so I don't
think it is stressing the SBX board
> too much. I agree with you though,
I wouldn't want to go much higher
> than that.
>
> On Tue, Jun 12, 2012
at 9:25 AM, <[email protected]> wrote:
>
>> On 12 Jun 2012 09:15, Ryan
Connelly wrote: Is there any possibility of damaging the SBX board if I
connect a test signal source directly to the SBX? I want to connect from
a 50 ohm SMA connector that produces a signal source (1200MHz carrier)
at -20dBm nominal power directly to the SMA connector on the SBX for
RX2. I can't find any specs for the SBX max receive power.. Does anyone
have any links? Thanks R _______________________________________________
USRP-users mailing list [email protected] [1]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
-20dBm should be fine, but I wouldn't go any higher than that.
_______________________________________________ USRP-users mailing list
[email protected] [3]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [4]
>
> _______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Keep
in mind that the Gnu Radio FFT isn't calibrated in any way--the dB
numbers given are relative. If absolute power indications are important,
you'll need to calibrate them yourself at various frequencies.
Links:
------
[1] mailto:[email protected]
[2]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[3]
mailto:[email protected]
[4]
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/20120612/02efdc86/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 12 Jun 2012 11:26:08 -0400
From: Ryan Connelly <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Connecting a test signal source to the SBX's
RX2
Message-ID:
<CAGfqHEh677TJLpbey=p_cdzbdhdfjmcscz33+dzcmenkryn...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Oh yes of course what was I thinking.. The FFT is not even plotting
w.r.t. power. But the zero must be some reference value? Are you just
saying that the reference is not accurate and varies with frequency?
On Tue, Jun 12, 2012 at 11:10 AM, <[email protected]> wrote:
> On 12 Jun 2012 11:06, Ryan Connelly wrote:
>
> I did the connection and no smoke came out.. Good!
>
> An FFT plot centered at the carrier frequency shows that the signal
> does not exceed -25dBm so I don't think it is stressing the SBX board
> too much. I agree with you though, I wouldn't want to go much higher
> than that.
>
> On Tue, Jun 12, 2012 at 9:25 AM, <[email protected]> wrote:
>
> On 12 Jun 2012 09:15, Ryan Connelly wrote: Is there any possibility of
> damaging the SBX board if I connect a test signal source directly to the
> SBX? I want to connect from a 50 ohm SMA connector that produces a signal
> source (1200MHz carrier) at -20dBm nominal power directly to the SMA
> connector on the SBX for RX2. I can't find any specs for the SBX max receive
> power.. Does anyone have any links? Thanks R
> _______________________________________________ USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -20dBm
> should be fine, but I wouldn't go any higher than that.
> _______________________________________________ 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
>
> Keep in mind that the Gnu Radio FFT isn't calibrated in any way--the dB
> numbers given are relative.? If absolute power indications are important,
> you'll need to calibrate them yourself at various frequencies.
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Tue, 12 Jun 2012 11:32:56 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Connecting a test signal source to the SBX's
RX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Jun 2012 11:26, Ryan Connelly wrote
> Oh yes of course what
was I thinking.. The FFT is not even plotting
> w.r.t. power. But the
zero must be some reference value? Are you just
> saying that the
reference is not accurate and varies with frequency?
The effective
analog gain at any given frequency will vary by up to a couple of dB,
depending on the daughtercard.
Furthermore, the voltage samples coming
off the ADC are processed by the decimator chain in the FPGA, and by the
time they get to Gnu Radio flow-graph, they've been scaled into
{-1.0,+1.0}. So, those samples are linearly-proportional to the incoming
voltage, but aren't a direct measurement.
Which is why you have to
calibrate over several frequencies, at your operating bandwidth.
Otherwise, the values shown in dB in the FFT graph are just
relative--they don't indicate any particular power level.
-Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/6ae15c19/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 12
******************************************
