[Discuss-gnuradio] GNURadio on custom SDR platform
Hello all, My name is Martin Flasskamp and I'm currently starting my diploma thesis at Bielefeld University in Germany. My task is to create a wireless demonstration system which enables two nodes to communicate wirelessly using software-defined radio. The platform I'll use is our own modular FPGA-based rapid prototyping system called RAPTOR ( http://www.raptor2000.de/en/home/ ). One of the available daughter boards (called DB-SDR) is compatible to an USRP2 and has a standard XCVR2450 board on top. By integrating our SDR-platform into GNURadio I want to be comparable to USRP and maybe benefit from other GNURadio projects in the future. Now my question: Which wireless standard is the best one to start with as a reference implementation? WiFi/Bluetooth/ZigBee/other? The aim is to have a sender as well as a receiver. Standard conformity would be nice but is not necessarily required. Best regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bug on get_mboard_sensor(gps_time) : may return old value
Hi
Using USRP N210, UHD 3.2.1, windows7 (VC++ 9), GPSDO (Jackson Labs)
I first use :
get_mboard_sensor(gps_time)
set_time_next_pps(0, 1, 5400)
Since gps time returns soon after pps edge occurs, I know that time is set
to 0 at a known GPS time called gps_t_0 (which is gps time returned by
sensor + 1)
(this is based on previous comments of Nick
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-08/msg00097.html)
Then, I want to check that gps_t_0 is really my starting point, then I
discovered the bug
Here is pseudo code (in real code I use get_full_secs())
loop(){
//Sleep(3000)
gps_now = get_mboard_sensor(gps_time)
time_now = get_time_now()
if ((gps_now - gps_t_0) != time_now){
//NOT OK
std::cout (gps_now - gps_t_0) - time_now
}
}
If there is no Sleep(3000), results are OK
If I enable the Sleep(3000), it prints at every loop iteration either -2 or
-3
If I change the sleep into Sleep(6000), it prints at every loop iteration -5
or -6
This means that query of gps_time is proportionally to Sleep(x) in the past
So I guess there is a problem of data flushing, the sensor query returning
first gps phrase generated by GPSDO since last gps_time query
A way to solve this bug may be to flush previous gps_time phrase generated
by GPSDO prior to get current time ??
Trying to dig into code (so far searching around get_nmea(...) in
gps_ctrl.cpp l.148), but not sure this can be solved in host code ??
Regards
Bastien
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug with USRP2/SBX and UHD when launching the acquisition
Hello all, I have a problem with my USRP2 (with a SBX board) : Most of times when I launch the acquisition, no data are received. For example with uhd_fft.py : $ uhd_fft.py linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes and the FFT Plotter appear but is empty. I have to try up to five times to make it work. Anyone having the same problem ? Or do you know what may it be ? If it can help, I am using a Gigabit Switch and Ubuntu 11.04 -- Emmanuel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem regarding installing the gr-rds
hello people, i have successfully installed the gnuradio 3.2.2 on ubuntu 10.04, and i want to use the RDS enabled application on the grc. when i install it, it is showing me many errors. i dont know whether i am using the right source onto it or not. i followed the steps from https://www.cgran.org/wiki/RDS but end in errrors. can any one please guide me the right path to download the gr-rds and the detailed steps to install it. will be very thankful to you. -- *REGARDS* *MOHAMMED BILALUDDIN GHOURI * *00447547981723* *E-MAIL : bgh...@gmail.com** * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bug while executing the make command
hello people, In the gr-rds repository installation to work with the grc, after configuring it when i enter the make command i am getting the following error rds.cc:145:20: error: Python.h: No such file or directory rds.cc:2557:4: error: #error This python version requires swig to be run with the '-classic' option rds.cc:751: error: expected initializer before ‘*’ token rds.cc:806: error: expected initializer before ‘*’ token rds.cc:827: error: expected initializer before ‘*’ token In file included from /usr/include/c++/4.4/stdexcept:38, from rds.cc:2576: /usr/include/c++/4.4/exception:35: error: expected declaration before end of line make[4]: *** [rds.lo] Error 1 make[4]: Leaving directory `/home/bilal/Downloads/gr-rds-3.0svn/src/lib' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/bilal/Downloads/gr-rds-3.0svn/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/bilal/Downloads/gr-rds-3.0svn/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bilal/Downloads/gr-rds-3.0svn' make: *** [all] Error 2 can any one please help me in this. will be very thankful to you. -- *REGARDS* *MOHAMMED BILALUDDIN GHOURI * *00447547981723* *E-MAIL : bgh...@gmail.com** * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug with USRP2/SBX and UHD when launching the acquisition
On 08/05/2011 07:33 AM, Emmanuel Caillé wrote: Hello all, I have a problem with my USRP2 (with a SBX board) : Most of times when I launch the acquisition, no data are received. For example with uhd_fft.py : $ uhd_fft.py linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes and the FFT Plotter appear but is empty. I have to try up to five times to make it work. Anyone having the same problem ? Or do you know what may it be ? 1) If there were no samples, you would see a timeout error printed to the terminal. 2) If the samples were all zero, press autoscale, you should see a horizontal blue line. Which one do you see? If it can help, I am using a Gigabit Switch and Ubuntu 11.04 -- Emmanuel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bug fix for GPSDO discovery and querying gps_time
Hi
I have experienced some issues regarding querying GPS time
(get_mboard_sensor(gps_time))
and about GPSDO discovery stability
For more details, see previous posts :
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-08/msg00111.html
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-08/msg00090.html
Anyway, I made 2 little fixes to gps_ctrl.cpp
I attached the new version to this email
It consist of :
1. waiting after sending string to GPSDO, while discovering GPSDO devices
(line 54)
//wait for _send(...) to return
sleep(milliseconds(FIREFLY_STUPID_DELAY_MS));
2. flushing NMEA data from previous sentences (line 159)
//flush data to avoid reading outdated value (because NMEA string
generated every second)
while (_recv() != ){
sleep(milliseconds(10));
}
I found these fixes to be stable on my setup
How can I get it merged into the main branch ?
Also Nick, I tried to play around with FIREFLY_STUPID_DELAY_MS first, but
this did not avoid the error I mentioned earlier
(I assume this is what you were talking about in
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-08/msg00073.html)
Regards
Bastien
//
// Copyright 2010-2011 Ettus Research LLC
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see http://www.gnu.org/licenses/.
//
#include uhd/usrp/gps_ctrl.hpp
#include uhd/utils/msg.hpp
#include uhd/utils/props.hpp
#include uhd/exception.hpp
#include uhd/types/sensors.hpp
#include boost/algorithm/string.hpp
#include boost/assign/list_of.hpp
#include boost/cstdint.hpp
#include boost/date_time/posix_time/posix_time.hpp
#include boost/thread/thread.hpp
#include boost/tokenizer.hpp
using namespace uhd;
using namespace boost::gregorian;
using namespace boost::posix_time;
using namespace boost::algorithm;
using namespace boost::this_thread;
/*!
* A GPS control for Jackson Labs devices (and other NMEA compatible GPS's)
*/
class gps_ctrl_impl : public gps_ctrl{
public:
gps_ctrl_impl(gps_send_fn_t send, gps_recv_fn_t recv){
_send = send;
_recv = recv;
std::string reply;
bool i_heard_some_nmea = false, i_heard_something_weird = false;
gps_type = GPS_TYPE_NONE;
//first we look for a Jackson Labs Firefly (since that's what we provide...)
_recv(); //get whatever junk is in the rx buffer right now, and throw it away
_send(HAAAY GUS\n); //to elicit a response from the Firefly
//wait for _send(...) to return
sleep(milliseconds(FIREFLY_STUPID_DELAY_MS));
//then we loop until we either timeout, or until we get a response that indicates we're a JL device
int timeout = GPS_TIMEOUT_TRIES;
while(timeout--) {
reply = _recv();
if(reply.find(Command Error) != std::string::npos) {
gps_type = GPS_TYPE_JACKSON_LABS;
break;
}
else if(reply.substr(0, 3) == $GP) i_heard_some_nmea = true; //but keep looking for that Command Error response
else if(reply.length() != 0) i_heard_something_weird = true; //probably wrong baud rate
sleep(milliseconds(200));
}
if((i_heard_some_nmea) (gps_type != GPS_TYPE_JACKSON_LABS)) gps_type = GPS_TYPE_GENERIC_NMEA;
if((gps_type == GPS_TYPE_NONE) i_heard_something_weird) {
UHD_MSG(error) GPS invalid reply \ reply \, assuming none available std::endl;
}
switch(gps_type) {
case GPS_TYPE_JACKSON_LABS:
UHD_MSG(status) Found a Jackson Labs GPS std::endl;
init_firefly();
case GPS_TYPE_GENERIC_NMEA:
if(gps_type == GPS_TYPE_GENERIC_NMEA) UHD_MSG(status) Found a generic NMEA GPS device std::endl;
if(get_time() == ptime()) {
UHD_MSG(status) No valid GPRMC packet found. Ignoring discovered GPS.;
gps_type = GPS_TYPE_NONE;
}
break;
case GPS_TYPE_NONE:
default:
break;
}
}
~gps_ctrl_impl(void){
/* NOP */
}
//return a list of supported sensors
std::vectorstd::string get_sensors(void) {
std::vectorstd::string ret = boost::assign::list_of
(gps_gpgga)
(gps_gprmc)
(gps_gpgsa)
(gps_time)
(gps_locked);
return ret;
}
uhd::sensor_value_t get_sensor(std::string key) {
if(key == gps_gpgga
or key == gps_gprmc
or key == gps_gpgsa) {
return sensor_value_t(
boost::to_upper_copy(key),
get_nmea(boost::to_upper_copy(key.substr(4,8))),
);
}
else if(key == gps_time) {
Re: [Discuss-gnuradio] Bug with USRP2/SBX and UHD when launching the acquisition
On 05/08/2011 10:33 AM, Emmanuel Caillé wrote: Hello all, I have a problem with my USRP2 (with a SBX board) : Most of times when I launch the acquisition, no data are received. For example with uhd_fft.py : $ uhd_fft.py linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.002.001-fc349d3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes and the FFT Plotter appear but is empty. Also, what do you get with uhd_usrp_probe --args addr=192.168.10.2 (or whatever you've set the IP addr of the USRP2 to). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 'gr_top_block_sptr' object has no attribute '_setup_usrp'
Hi Thanks marcus. I am new to Gnu Radio and Python. I am working on USRP N200 with RFX2400. I am trying to make digital-bert scripts to work for UHD. I made some changes in the code but i am encoutering errors. The latest error is shown below: aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./benchmark_tx1.py --tx-freq=2500M -g 32 --ip=192.168.10.2 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 32 dB Actual center frequency 2.5G UUterminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::math::rounding_error ' what(): Error in function boost::math::iroundd(d): Value 7.3939377762685976e+134 can not be represented in the target integer type. Aborted any help or feedback will be appreciated. Thanks --Saketh On Thu, Aug 4, 2011 at 1:28 PM, saketh kumar m.sakethku...@gmail.comwrote: Hi I am trying to make digital-bert scripts work with USRP N200, RFX2400. I have changed my code a little bit. But it shows me an error saying object has no attribute. aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./benchmark_tx1.py -f 2500M linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 Traceback (most recent call last): File ./benchmark_tx1.py, line 108, in module tb = tx_bpsk_block(options) File ./benchmark_tx1.py, line 52, in __init__ self._setup_usrp(options.ip, File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute '_setup_usrp' Can anyone help me out, how to resolve this error ? Attached is my little modified code. -- Saketh Kumar -- Saketh Kumar #!/usr/bin/env python # # Copyright 2008 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # from gnuradio import gr, eng_notation, uhd from gnuradio.eng_option import eng_option from optparse import OptionParser from transmit_path import transmit_path import sys _dac_rate = 128e6 n2s = eng_notation.num_to_str class tx_bpsk_block(gr.top_block): def __init__(self, options): gr.top_block.__init__(self, tx_mpsk) self._transmitter = transmit_path(options.sps, options.excess_bw, options.amplitude) if_rate = options.rate*options.sps interp = int(_dac_rate/if_rate) print Modulation:, n2s(options.rate), bits/sec print TX IF rate:, n2s(if_rate), samples/sec print USRP interpolation:, interp print DAC amplitude:, options.amplitude self._setup_usrp(options.ip, interp, options.gain, options.tx_freq) self.connect(self._transmitter, self._usrp) def _setup_usrp(self,ip,interp, gain, tx_freq): self._usrp = uhd.usrp_sink(device_addr=, io_type=uhd.io_type.COMPLEX_FLOAT32,
Re: [Discuss-gnuradio] 'gr_top_block_sptr' object has no attribute '_setup_usrp'
On 05/08/2011 1:35 PM, saketh kumar wrote: Hi Thanks marcus. I am new to Gnu Radio and Python. I am working on USRP N200 with RFX2400. I am trying to make digital-bert scripts to work for UHD. I made some changes in the code but i am encoutering errors. The latest error is shown below: Looks to me like you're trying to stuff a very-large floating-point value into an integer. 32-bit integers are good to +/- 2**31, whereas whatever value you have is very much larger than that. Usually, one uses the error messages as a clue to debugging the code. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 'gr_top_block_sptr' object has no attribute '_setup_usrp'
I got it what you are trying to say but i haven't mentioned any integer type in the code so which very large value is it taking. -saketh On Fri, Aug 5, 2011 at 1:35 PM, saketh kumar m.sakethku...@gmail.comwrote: Hi Thanks marcus. I am new to Gnu Radio and Python. I am working on USRP N200 with RFX2400. I am trying to make digital-bert scripts to work for UHD. I made some changes in the code but i am encoutering errors. The latest error is shown below: aravind@COE-CW85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./benchmark_tx1.py --tx-freq=2500M -g 32 --ip=192.168.10.2 linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-5239879 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- mboard0 is MIMO master UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam Gain d'board: 32 dB Actual center frequency 2.5G UUterminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::math::rounding_error ' what(): Error in function boost::math::iroundd(d): Value 7.3939377762685976e+134 can not be represented in the target integer type. Aborted any help or feedback will be appreciated. Thanks --Saketh On Thu, Aug 4, 2011 at 1:28 PM, saketh kumar m.sakethku...@gmail.comwrote: Hi I am trying to make digital-bert scripts work with USRP N200, RFX2400. I have changed my code a little bit. But it shows me an error saying object has no attribute. aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ ./benchmark_tx1.py -f 2500M linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8 gr_fir_ccf: using SSE Modulation: 250k bits/sec TX IF rate: 500k samples/sec USRP interpolation: 256 DAC amplitude: 2000 Traceback (most recent call last): File ./benchmark_tx1.py, line 108, in module tb = tx_bpsk_block(options) File ./benchmark_tx1.py, line 52, in __init__ self._setup_usrp(options.ip, File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute '_setup_usrp' Can anyone help me out, how to resolve this error ? Attached is my little modified code. -- Saketh Kumar -- Saketh Kumar -- Saketh Kumar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna
Using this flow graph: http://i.imgur.com/K9TaN.png I get this traceback: -- Opening USRP-E on /dev/usrp_e0 Traceback (most recent call last): File full_duplex.py, line 60, in module tb = full_duplex() File full_duplex.py, line 31, in __init__ num_channels=1, File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 2045, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: EnvironmentError: IOError: Failed to open /dev/usrp_e0 This never occurs when using only one source or sink, but occurs with two, independent of the antennas I specify. On Thu, Aug 4, 2011 at 13:57, Meyer S. Jacobs meyerma...@gmail.com wrote: Using gnuradio-companion for code generation, with the UHD drivers for the E100, it still locks up. I can provide my .grc files and generated python code when I get back to my desk. -Meyer S. Jacobs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna
On Fri, 2011-08-05 at 13:40 -0700, Meyer S. Jacobs wrote: Using this flow graph: http://i.imgur.com/K9TaN.png What version of E100 images are you using? The older stuff had a known bug that would cause this. Update to latest images try again. --n I get this traceback: -- Opening USRP-E on /dev/usrp_e0 Traceback (most recent call last): File full_duplex.py, line 60, in module tb = full_duplex() File full_duplex.py, line 31, in __init__ num_channels=1, File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 2045, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: EnvironmentError: IOError: Failed to open /dev/usrp_e0 This never occurs when using only one source or sink, but occurs with two, independent of the antennas I specify. On Thu, Aug 4, 2011 at 13:57, Meyer S. Jacobs meyerma...@gmail.com wrote: Using gnuradio-companion for code generation, with the UHD drivers for the E100, it still locks up. I can provide my .grc files and generated python code when I get back to my desk. -Meyer S. Jacobs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna
I updated the usrp kernel module and boot files with the versions published on the wiki. The problem persists. I also recently applied the Console Development Image from http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Images (within the last week). root@usrp-e1xx:~# uname -a Linux usrp-e1xx 2.6.38 #1 PREEMPT Tue Aug 2 08:56:51 EDT 2011 armv7l GNU/Linux root@usrp-e1xx:~# modinfo usrp_e filename: /lib/modules/2.6.38/kernel/drivers/misc/usrp_e.ko license:GPL v2 author: Philip Balister phi...@opensdr.com description:usrp_e alias: usrp_e version:0.2 srcversion: 2D513E631A29B9FC987759B depends: vermagic: 2.6.38 preempt mod_unload modversions ARMv7 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs)
Phil, What may be the reason that after updating FAT and uploading rootfs with new files It blows when python is interpreting from gnuradio import uhd I need to upload new UHD from GIT and compile it? WD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs)
K. Leaving in 5 Sent via DROID on Verizon Wireless -Original message- From: Radio Man gnuradio...@gmail.com To: Philip Balister phi...@opensdr.com Cc: usrp-us...@lists.ettus.com usrp-us...@lists.ettus.com, GNURadio Discussion List Discuss-gnuradio@gnu.org Sent: Fri, Aug 5, 2011 21:26:00 GMT+00:00 Subject: Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs)
On 08/05/2011 02:26 PM, Radio Man wrote: Phil, What may be the reason that after updating FAT and uploading rootfs with new files It blows when python is interpreting from gnuradio import uhd Send the error verbose and the output of uhd_usrp_probe I need to upload new UHD from GIT and compile it? WD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna
On Fri, Aug 5, 2011 at 15:41, Josh Blum j...@ettus.com wrote: Can you tell me the output of uhd_usrp_probe thanks -josh It appears I must have botched something during the updating. Now everything gives this error: root@usrp-e1xx:~# uhd_usrp_probe linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.001.001-3724b82 -- Opening USRP-E on /dev/usrp_e0 Error: EnvironmentError: IOError: Failed to open /dev/usrp_e0 I seem to remember having this problem early on, but recompiling the UHD drivers and Gnuradio solved it. I'll try that again in an hour, unless advised otherwise. Also, it seems another thread on discuss is related to the most recent problem. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help
hello, how you did it, that changed in the sensing spectrum, I'm using the module FLEX900? devin kelly-2 wrote: Hello, I've created a spectrum sensor with the USRP2, my python script uses the same idea as usrp_spectrum_sense.py found in gnuradio. That is, it tunes, takes an FFT, records, retunes, etc. I have two problems with my data though. In the file attached is some TV spectrum (left half) and noise (right half). My first question is this: why isn't the spectrum for the TV signal flat, it seems to bob up and down. Note that each segment is from a different FFT, that is each FFT produces that oval shape. At first I thought this had something to do with the window I was using but I've tried hamming, blackman-harris, and rectangular windows and they all have this effect. My second question is why isn't the transition between TV spectrum and noise more smooth? It looks like it could be smooth but the gain seems to jump for an FFT right after 566 MHz and then settle down again. I thought this might be the AGC but I've tried different attack/decay rates, different reference levels, etc with the agc2_cc block but the problem remains. Any help with either of these questions would be appreciated, Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio jhar...@hotmail.com -- View this message in context: http://old.nabble.com/USRP2-Spectrum-Sensing-Help-tp31183192p32206004.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna
On 08/05/2011 03:53 PM, Meyer S. Jacobs wrote: On Fri, Aug 5, 2011 at 15:41, Josh Blum j...@ettus.com wrote: Can you tell me the output of uhd_usrp_probe thanks -josh It appears I must have botched something during the updating. Now everything gives this error: root@usrp-e1xx:~# uhd_usrp_probe linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.001.001-3724b82 Yes, 3.1.* had this issue, its been fixed on the master for some time, and now 3.2.* is an official release with the fix. -josh -- Opening USRP-E on /dev/usrp_e0 Error: EnvironmentError: IOError: Failed to open /dev/usrp_e0 I seem to remember having this problem early on, but recompiling the UHD drivers and Gnuradio solved it. I'll try that again in an hour, unless advised otherwise. Also, it seems another thread on discuss is related to the most recent problem. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
