[Discuss-gnuradio] Why d_phase in Costas loop different in gr_costas_loop from gr_mpsk_receiver?
Hi, Why is the d_phase equation different in these two files? d_phase += d_alpha*phase_error; // In gr_mpsk_receiver.cc and d_phase = d_phase + d_freq + d_alpha * error; // In gr_costas_loop.cc The d_freq term is omitted and I don't understand why. Thanks, Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to view data samples when running fm radio
In usrp_wfm_rcv.py, there is a command self.u = usrp.source_c() Now how do we use the gr.file_sink() in this file? On 5/27/09, Eric Blossom e...@comsec.com wrote: On Tue, May 26, 2009 at 01:53:40PM +0500, Zainab Qureshi wrote: I have successfully run gnuradio on linux/windows. I am running the example usrp_wfm_rcv.py. i want to look at few of the data samples coming from the usb port. What changes in the code should i make to view these data samples. Connect a gr.file_sink to the usrp, then look at the resulting data using octave or some other tool. -- z...@!n@b ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Early Late Prompt Correlation and Costas Loop implementation
Hi Johnathan and other friends, I want to use an E/P/L Correlation (for Code synchronization) and Costas loop (for carrier phase sync) for Direct Sequence Spread Spectrum receiver based on this. http://img19.imageshack.us/img19/826/dsssrxr.jpg I have a doubt that needs to be cleared as I spent a lot of time trying to figure it out without any luck. I need a carrier signal to strip the carrier signal from the received DSSS signal so as to get the Spreading sequence. I use the phase corrected spreading sequence to obtain the continuous wave signal and use costas loop to get the phase corrected Carrier Signal. As in Gnuradio there is no such thing as a carrier as the signal is in baseband what will the output of costas loop be so as to use it to get the Spreading sequence. I am sorry my concepts are not very strong but I am learning and such unresolved questions make this learning all the more difficult. Can you please tell me where I am wrong and what could be done. Thank you for taking time to answer to my question. Thanks, Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to view data samples when running fm radio
s=*gr*.*file_sink*(*gr*.sizeof_gr_complex, file.txt) and then connect usrp.source to this object s. On Wed, May 27, 2009 at 3:06 AM, Zainab Qureshi zaina...@gmail.com wrote: In usrp_wfm_rcv.py, there is a command self.u = usrp.source_c() Now how do we use the gr.file_sink() in this file? On 5/27/09, Eric Blossom e...@comsec.com wrote: On Tue, May 26, 2009 at 01:53:40PM +0500, Zainab Qureshi wrote: I have successfully run gnuradio on linux/windows. I am running the example usrp_wfm_rcv.py. i want to look at few of the data samples coming from the usb port. What changes in the code should i make to view these data samples. Connect a gr.file_sink to the usrp, then look at the resulting data using octave or some other tool. -- z...@!n@b ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to write a block - Error adding sub function to a block
Hello!
I've been using the examples from how to write a block as a base to create
my own.
Using one of them a created some kind of sink. In it I added some auxiliary
function accessible from the outside in order to get the values from the
buffer. So far so good...
With the other one I made a file sink, which stores some statistics
calculated on the block. Then I went to add a simple function just to close
the current file and open a new one every few hours.
What happens is that I followed the same procedure to add the sub function
to be accessible from the outside, and for some reason I can't seem to find
it gives me an error which I never seen on the other one.
The procedure I used on the other was this:
1. On the header define the function as public
2. After the my_class::work() define the function and the code
3. On the howto.i add the function as in header file
I don't know if this was correct but it worked on the first one.
I hope you can help me. Thanks in advance!
Next is the errors and the code:
#--#
ERROR:
Traceback (most recent call last):
File Acquisition.py, line 4, in module
from gnuradio import usrp, howto
File /usr/local/lib/python2.5/site-packages/gnuradio/howto.py, line 6,
in module
import _howto
ImportError: /usr/local/lib/python2.5/site-packages/gnuradio/_howto.so:
undefined symbol: _ZN16howto_co_cx_stat14create_new_logEPc
#---#
HOWTO.I
GR_SWIG_BLOCK_MAGIC(howto,co_cx_stat);
howto_co_cx_stat_sptr howto_make_co_cx_stat ( unsigned int vector_size,
unsigned int sampling,
unsigned int fftsize,
char *filename);
class howto_co_cx_stat : public gr_block
{
private:
howto_co_cx_stat (unsigned int vector_size,
unsigned int sampling,
unsigned int fftsize,
char *filename);
public:
int create_new_log(char file_name[255]); // REFERENCE //
};
#---#
HOWTO_CO_CX.H
class howto_co_cx_stat : public gr_block
{
//private:
// The friend declaration allows howto_make_co_cx_stat to
// access the private constructor.
friend howto_co_cx_stat_sptr howto_make_co_cx_stat (unsigned int
vector_size,
unsigned int sampling,
unsigned int fftsize,char *filename);
howto_co_cx_stat (unsigned int vector_size,
unsigned int sampling,
unsigned int fftsize,
char *filename); // private
constructor
unsigned int d_vector_size;
unsigned int d_sampling;
unsigned int d_fftsize;
char d_filename[255];
std::vectorgr_complex band100_CO;
std::vectorgr_complex band100_CX;
std::vectorgr_complex band4000_Noise;
std::vectorfloat band100_CXi;
std::vectorfloat band100_CXq;
float amp_co, amp_cx, phase;
FILE *file;
MATLAB_MATRIX_HEADER header;
public:
~howto_co_cx_stat (); // public destructor
int general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items);
int create_new_log(char file_name[255]);
// DESIRED FUNCTION //
};
#-#
HOW_CO_CX.CC
(...default stuff...)
int
howto_co_cx_stat::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
(...work...)
}
int create_new_log(char file_name[255])
{
printf(\n\n\name changed!!!\n\n\n);
printf(\nFile 1 C++: %s, file_name);
return 0;
}
--
View this message in context:
http://www.nabble.com/How-to-write-a-block---Error-adding-sub-function-to-a-block-tp23740353p23740353.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
RE: [Discuss-gnuradio] DAB receiver
Hello Andreas, Sampling rate is 2.048Msps. When I analyze every DAB frame captured, I see that in total the whole frame has shortage of 9 to 10 samples. There could be a very high possibility due to ADC clock drift when we capture the data from DAB generator and digitize it. Thanks for the references. I have developed the receiver side matlab code which works for simulated data. But I face issues in getting it working for real time streams. I need to add sampling rate converter in the code which I will be doing. You have mentioned in your thesis.pdf that you did refer to a matlab code for DAB receiver. If possible and if it's not copyrighted can you share the same to me? Best Regards Ravi -Original Message- From: discuss-gnuradio-bounces+ravishankar.m=jasmin-infotech@gnu.org [mailto:discuss-gnuradio-bounces+ravishankar.m=jasmin-infotech@gnu.org] On Behalf Of Andreas Mueller Sent: Wednesday, May 27, 2009 12:11 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DAB receiver Hello Ravi Ravi Trivedi wrote: Hello all, I am trying to implement synchronization of DAB receiver in matlab. I have been facing some problems when I test the matlab receiver code for real time streams. First issue is sampling rate estimation problem. I see that real time frame has shortage of samples when compared to values given in specification. I do frame detection first followed by joint estimation What is your sampling rate, and how many samples are you missing? It's likely that your sampling rate is not exactly what you expect, when you use real-world data, and maybe you have to do sampling rate correction as well. of fine timing and coarse frequency offset. After compensation, I perform fine frequency offset estimation and compensation. I see that for real time streams FIC decoder doesn't pass the CRC. If I use simulated data CRC check gets passed. Does anyone have receiver matlab code working for real time data which I can use for comparison with my code? Thanks in advance. I did an implementation for GNU Radio a while ago. You can find it at [1] and a description in [2]. Although it's not complete, it does everything on the lower levels, up to (and including) FIC CRC verification (which works, also with real-world data). Regards, Andreas [1] http://people.ee.ethz.ch/~andrmuel/files/gnuradio/gr-dab.tgz [2] http://people.ee.ethz.ch/~andrmuel/files/gnuradio/dab-doc/thesis.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] DAB receiver
Hello Andreas, Sampling rate is 2.048Msps. When I analyze every DAB frame captured, I see that in total the whole frame has shortage of 9 to 10 samples. There could be a very high possibility due to ADC clock drift when we capture the data from DAB generator and digitize it. Thanks for the references. I have developed the receiver side matlab code which works for simulated data. But I face issues in getting it working for real time streams. I need to add sampling rate converter in the code which I will be doing. You have mentioned in your thesis.pdf that you did refer to a matlab code for DAB receiver. If possible and if it's not copyrighted can you share the same to me? Best Regards Ravi -Original Message- From: discuss-gnuradio-bounces+ravishankar.m=jasmin-infotech@gnu.org [mailto:discuss-gnuradio-bounces+ravishankar.m=jasmin-infotech@gnu.org] On Behalf Of Andreas Mueller Sent: Wednesday, May 27, 2009 12:11 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DAB receiver Hello Ravi Ravi Trivedi wrote: Hello all, I am trying to implement synchronization of DAB receiver in matlab. I have been facing some problems when I test the matlab receiver code for real time streams. First issue is sampling rate estimation problem. I see that real time frame has shortage of samples when compared to values given in specification. I do frame detection first followed by joint estimation What is your sampling rate, and how many samples are you missing? It's likely that your sampling rate is not exactly what you expect, when you use real-world data, and maybe you have to do sampling rate correction as well. of fine timing and coarse frequency offset. After compensation, I perform fine frequency offset estimation and compensation. I see that for real time streams FIC decoder doesn't pass the CRC. If I use simulated data CRC check gets passed. Does anyone have receiver matlab code working for real time data which I can use for comparison with my code? Thanks in advance. I did an implementation for GNU Radio a while ago. You can find it at [1] and a description in [2]. Although it's not complete, it does everything on the lower levels, up to (and including) FIC CRC verification (which works, also with real-world data). Regards, Andreas [1] http://people.ee.ethz.ch/~andrmuel/files/gnuradio/gr-dab.tgz [2] http://people.ee.ethz.ch/~andrmuel/files/gnuradio/dab-doc/thesis.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why d_phase in Costas loop different in gr_costas_loop from gr_mpsk_receiver?
Why is the d_phase equation different in these two files? d_phase += d_alpha*phase_error; // In gr_mpsk_receiver.cc and d_phase = d_phase + d_freq + d_alpha * error; // In gr_costas_loop.cc The d_freq term is omitted and I don't understand why. gr_costas_loop is wrong, and gr_mpsk_receiver used to have the same error and has since been updated. The frequency component of the rotation has already been added to the current phase estimate during de-rotation of of the samples (in mm_sample, I think); so here all we have to do is update the phase estimate by the estimated error. I would also check your version of gr_costas_loop to see if the phase estimate is clipped, or wrapped. There was an error where the phase was clamped to 2*pi rather than rolling over, which would cause an error once the phase drifted that far; this has also been fixed in the latest version of mpsk_receiver. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Cygwin C++ example with 3.2
Problem solved. I've forgot to replace cygusrp-0.dll with the new one from the 3.2 release. Additionally I had to add boost_thread-gcc34-mt-1_36.dll if I want to run the compiled executable with Windows. Kutik wrote: Hello, I've updated to release 3.2. I am running the example from C++ Interfacing Questions. I get the following error: $ ./testusrp.exe 5 [main] testusrp 3532 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) The error appears with call of usrp_standard_rx::make Note that with previous release I had no problem. Does anyone has similar experience? Is there some limitation of 3.2 release to be used under Cygwin? Thank you. -- View this message in context: http://www.nabble.com/USRP1-Cygwin-C%2B%2B-example-with-3.2-tp23738943p23741604.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why d_phase in Costas loop different in gr_costas_loop from gr_mpsk_receiver?
gr_costas_loop is wrong, and gr_mpsk_receiver used to have the same error and has since been updated. The frequency component of the rotation has already been added to the current phase estimate during de-rotation of of the samples (in mm_sample, I think); so here all we have to do is update the phase estimate by the estimated error. DOH! I it's still early for me. gr_costas_loop is /not/ wrong. The reason that d_freq is added is because the phase advances normally over time, and this line updates the phase estimate for both changes over time and the error. It is not need in mpsk receiver because it is split into two parts (one in mm_sample and one where you got that line from). Sorry for the confusion. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Upcoming changes in the development trunk
Now that we have a new stable release series, I want to alert developers to some upcoming changes in the GNU Radio trunk which will impact your software, requiring changes on your part in order to continue to compile and link against a version of GNU Radio built from the trunk. For those of you who need to maintain source code compatibility, you should be using either the official release 3.2 tarball, the Ubuntu binary packages, or a Subversion checkout of the release 3.2 branch. This code branch will have backported bug fixes and new features, but only those which can be implemented without breaking existing source code. In no particular order of time or importance, these are among some of the changes planned for the development trunk and 3.3 release that may affect you: * Removal of the omnithreads library/switchover to Boost threads. This is a C++ auxiliary library used internally as a layer on top of pthreads, but made available for users as well. Python API users will be unaffected, as will most C++ API users, but if you've used this library directly, you'll need to investigate replacements from the Boost threading library. This changeover has been going on for some time already. * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. * Replacement of usrp-inband code for USRP1. Using the to-be-developed merge of message passing capabilities into gr-blocks, the USRP1 (and USRP2) will have timed transmit/receive and metadata capabilities from within the traditional (non-mblock) GNU Radio C++ and Python APIs. * Migration of blks2 into C++. This has been a place to hold hierarchical blocks constructed in Python. Many of these blocks will be reimplemented as C++ API hierarchical blocks, and re-exported into Python as part of the core 'gr' namespace. This will done where possible without syntax changes needed in your Python code other than the namespace to import from. * Movement of libusrp header files into 'include/usrp' directory. Today, these are installed into the global $prefix/include directory, with the possibility of name clashes with other header files. If you are using libusrp directly, you'll need to update your #include statements in your C++ code. * Deprecation and eventual removal of gr-comedi. This component provides GNU Radio blocks for the libcomedi interface to many ADC cards. However, it is no longer compatible with the current libcomedi API, and without a maintainer or the ability to test correctness, it is becoming stale. If this component is important to you, we'd love to hear from you. There are of course many new capabilities planned for 3.3, which will be the subject of another email, and Eric has already touched on a few in his prior email after the release of 3.2. Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] unaesthetic connections in GRC
HI All and thanks for your posts before, .-) in my GRC schematic there are some unaesthetic connections, which goes through some of my elements, therefore i want to use the copy Element. Is this ok ? Or what Element should i use to let the connection goe another way ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upcoming changes in the development trunk
On Wed, 2009-05-27 at 06:44 -0700, Johnathan Corgan wrote: In no particular order of time or importance, these are among some of the changes planned for the development trunk and 3.3 release that may affect you: ... * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. Is it really neccesary to remove this? I need the single-threaded-scheduler for my GPGPU code. (Running gnuradio on a videocard) When doing doing calculations on en external device, you really need to be in control of on which CPU/thread which block is running. In practice you need to run everything that runs on the external device from a single host thread. The external device is running hundreds of threads and gnuradio only needs a single thread to control the external device and move data between the host and external device. I have been waited with developing the GPGPU code further until the changes in the scheduling code stabelizes. (At the moment the gpgpu branche is incompatible with the most recent trunk) My version of the scheduler is a modified single-threaded scheduler. So I don't neccesaraly need to keep the current single-threaded scheduler, but I do need the possibility to choose which scheduler to use. * Migration of blks2 into C++. This has been a place to hold hierarchical blocks constructed in Python. Many of these blocks will be reimplemented as C++ API hierarchical blocks, and re-exported into Python as part of the core 'gr' namespace. This will done where possible without syntax changes needed in your Python code other than the namespace to import from. Will it be still possible to build your own python hierarchical blocks and install them somewhere.? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to write a block - Error adding sub function to a block
ImportError: /usr/local/lib/python2.5/site-packages/gnuradio/ _howto.so: undefined symbol: _ZN16howto_co_cx_stat14create_new_logEPc #-# HOW_CO_CX.CC int create_new_log(char file_name[255]) You have a basic C++ scope issue ... the above should be: int howto_co_cx_stat::create_new_log(char file_name[255]) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Early Late Prompt Correlation and Costas Loop implementation
I am using Flex-2400 boards and the received signal is ideally at baseband which in fact is not possible because, of various factors. Now, we have a signal that has a center frequency 'fc' which is not 0Hz. Assuming the costas to lock at this carrier I can achieve my goal. Isn't it right? Can you also tell me how fmax and fmin are calculated? For example, dbpsk.py has fmax=0.1 and fmin=-0.1. How do we get these? Thanks, Ali On Wed, May 27, 2009 at 8:24 AM, Tom Lutz tommyl...@gmail.com wrote: As in Gnuradio there is no such thing as a carrier as the signal is in baseband what will the output of costas loop be so as to use it to get the Spreading sequence. I am sorry my concepts are not very strong but I am learning and such unresolved questions make this learning all the more difficult. Can you please tell me where I am wrong and what could be done. The costas loop block (the one found in GRC and in the source code, assuming you are using that one) actually outputs the incoming signal multiplied by the synchronized carrier (assuming it has locked). If you tune the USRP off of the carrier you are interested in, that would probably work, but that's from my naive view of the world. For example, if your carrier was at 465MHz and you tuned to 464MHz, you might be able to bandpass filter and send to the costas loop the 1MHz carrier. The costas loop would output the downmixed signal downmixed further, such that baseband is now 465MHz. The min/max frequencies for the costas loop are in radians/sample, FYI. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upcoming changes in the development trunk
On Wed, May 27, 2009 at 7:35 AM, Martin DvH gnuradiom...@olifantasia.com wrote: * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. Is it really neccesary to remove this? Not strictly necessary, no. A lot of the new features in 3.3 will impact the scheduler, especially the new message passing between blocks. It will be extra work to modify both schedulers. This is Eric's area, however, so I'll let him comment further. * Migration of blks2 into C++. Will it be still possible to build your own python hierarchical blocks and install them somewhere.? Yes, of course. To clarify the above, we're reimplementing a number of our own Python hierarchical blocks that are in now in the blks2 namespace as C++ hierarchical blocks that will then be re-made available to Python via SWIG in the gr namespace. We're not removing the ability to write hierarchical blocks in Python. This mostly to allow pure C++ API users to take advantage of them, such as the using the digital packet radio capabilities we have. As an example where we've already done this, we (well, Tom Rondeau) migrated the blks2 channel model: http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/blks2impl/channel_model.py?rev=10863#L25 ...into C++ here: http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/hier/gr_channel_model.cc#L43 Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] inconsistency between .h and .i in gr_ofdm_cyclic_prefixer
I noticed that the aforementioned block is defined correctly as an interpolator in the .h file and as a decimator in the .i file. One question is why is it that this is not caught at build time... Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Python error USRP question
After installing everything, I tried to run one of the python examples through the terminal. Each of the examples played but threw the following error: Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored Any idea what is wrong? I even attached the USRP and nothing worked. If I open an example should the usrp run off of that? -- View this message in context: http://www.nabble.com/Python-error-USRP-question-tp23745395p23745395.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC request
I would like to be able to execute GRC from a directory structure
moved elsewhere from ${prefix} ... meaning, I compile and install into
${prefix}, but then 'cp -r' or 'mv' or 'tar - | tar -' the whole
directory structure elsewhere outside of the usual execution
location. I then create / modify the environment variables such that
they point to the new location (PATH, PYTHONPATH, and
DYLD_LIBRARY_PATH are the 3 primary ones for OSX). From my initial
testing, the rest of GNU Radio can do this with just those 3 variables
(on OSX; Y-Variables-MV on other platforms)
This doesn't work because GRC hard-wires the install path (or
something like it) in a few files (I do not know if all of these files
need to be modified to get what I'd like to do working; nor do I know
if these are all of the files that need to be tweaked):
grc/freedesktop/grc_setup_freedesktop.in
grc/src/platforms/base/Constants.py.in
grc/src/platforms/python/Constants.py.in
I can think of two possible solutions:
1) Put a switch at the top of each of these files along the lines of:
import os
DATA_DIR = os.getenv (GRC_DATADIR)
if not DATA_DIR:
DATA_DIR = @datadir@
or the equivalent functionality that would work for the @variables@
used in that file (I don't know if the above would work; it is for
descriptive purposes only): first check the user's shell environment
for the appropriate variables, and if they don't exist, then revert to
the default from compiling. This way, users who wish to change the
location can do so easily via their shell environment, and those who
do not set the shell environment variables get the default -- same as
current usage.
2) Even better would be the use of relative paths (it does work for
me, directly modifying the installed files). This solution would
require knowing the path to $sharedir and the $pythondir and then
figuring out how to get from one to the other (the relative path), but
IMHO is the more elegant solution.
Thanks in advance! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC request
Im not a huge fan of the hard-coded directories, i think it might be kind of nice to have a data_dir_prefix that would default to whatever automake/autoconf says, but also takes queues from an environment variable...so I know this is possible, but I am a bit confused about why. Woulnt it be easier to modify $(datadir) via ./configure --datadir=xxx, and use the whole automake system for gnuradio? What are you attempting to do, making a distributable package? -Josh grc/freedesktop/grc_setup_freedesktop.in grc/src/platforms/base/Constants.py.in grc/src/platforms/python/Constants.py.in I can think of two possible solutions: 1) Put a switch at the top of each of these files along the lines of: import os DATA_DIR = os.getenv (GRC_DATADIR) if not DATA_DIR: DATA_DIR = @datadir@ and because we like one-liners :-) import os DATA_DIR = os.environ.get(GRC_DATADIR, @datadir@) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DAB receiver
Hello Ravi Sampling rate is 2.048Msps. When I analyze every DAB frame captured, I see that in total the whole frame has shortage of 9 to 10 samples. There could be a very high possibility due to ADC clock drift when we capture the data from DAB generator and digitize it. Sounds reasonable - and afaik, 9 to 10 samples drift per frame could corrupt the signal enough to invalidate the CRC. Thanks for the references. I have developed the receiver side matlab code which works for simulated data. But I face issues in getting it working for real time streams. I need to add sampling rate converter in the code which I will be doing. You have mentioned in your thesis.pdf that you did refer to a matlab code for DAB receiver. If possible and if it's not copyrighted can you share the same to me? Unfortunately it is copyrighted, and I don't have the permission of the author to distribute it - but I'll forward his email to you, you can try asking him directly. Regards, Andreas pgpIahulorIRy.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python error USRP question
i installed python and gnu radio 3.2. Here is a list of the items installed from http://gnuradio.org/trac/wiki/UbuntuInstall http://gnuradio.org/trac/wiki/UbuntuInstall -- View this message in context: http://www.nabble.com/Python-error-USRP-question-tp23745395p23749141.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Continuous Stream Reading off of the usrp_rx_cfile.py capture possible?
Dear list, I have one question regarding the samples captured using usrp_rx_cfile.py at the receiver. Is there anyway that I let the usrp_rx_cfile.py run forever, and it will keep on capturing samples through USRP forever, while I keep on taking out 10K samples (lets say) at a time from that continuous capture, and process them for xyz(..). Then next time I take out the NEXT 10K samples and process them for xyz(..). Meanwhile, the usrp_rx_cfile.py continuously keeps on capturing the samples off of the air using USRP uninterrupted? One naive way, I can think of is, saving each 10K samples in a different file one after another, but I fear i might miss some samples or some other disaster may occur that I am not being able to foresee. I wanted to hear your thoughts/suggestion/anger? -Sincerely, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python error USRP question
Your question is fairly generic. Please see http://gnuradio.org/trac/wiki/ReportingErrors for some guidelines on the best way to ask you question in a manner that will allow us to help you solve it. Thanks Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Continuous Stream Reading off of the usrp_rx_cfile.py capture possible?
I have one question regarding the samples captured using usrp_rx_cfile.py at the receiver. Is there anyway that I let the usrp_rx_cfile.py run forever, and it will keep on capturing samples through USRP forever, while I keep on taking out 10K samples (lets say) at a time from that continuous capture, and process them for xyz(..). Then next time I take out the NEXT 10K samples and process them for xyz(..). Meanwhile, the usrp_rx_cfile.py continuously keeps on capturing the samples off of the air using USRP uninterrupted? The easiest way I think to do this would be just pipe the output of the gnuradio data into your handler program. Of course this limits you to the maximum buffer size in the pipe (64KB on linux I think?). If that's no good, you would probably be better off simply writing your own gnuradio block to handle the processing and produce whatever output you require (http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html). Finally, If you absolutely need to process the data outside of gnuradio for some reason and the tcp_sink/pipe method doesn't work you could make a 'rotating sink' by following the same directions, but using the gr_file_sink as a baseline. You could write n samples to a file, then write n to a second file, then switch back to the first. I think it would pretty simple to re-write gr_file_sink to do this; just remember that if have more than one of these sinks active they may not be exactly in sync. If none of these are ideal you could let us know your motivation behind wanting this scheme to work and we might able to present you with a better way to go about it. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Format of captured data
I am receiving 16-bit data from USRP (data is in the range of -32768 to 32767) in Windows. Now I want to apply some demodulation algorithms to these samples but I am a bit confused. According to the following thread, each data sample that is coming from USRP is a complex baseband value. However, a complex baseband value should be of 32 bit (and not 16-bit) as it comprises of 16-bit I and Q each. http://www.ruby-forum.com/topic/182559 So the data samples that I am getting are in the form of I0,Q0,I0,Q0 or a sum: (I + Q)? If these are in the form of I0,Q0 ... then how do we keep a track that which one is an I and which one is a Q? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Format of captured data
On Wed, May 27, 2009 at 1:50 PM, Ujala Qasim ujala.qa...@gmail.com wrote: I am receiving 16-bit data from USRP (data is in the range of -32768 to 32767) in Windows. Now I want to apply some demodulation algorithms to these samples but I am a bit confused. According to the following thread, each data sample that is coming from USRP is a complex baseband value. However, a complex baseband value should be of 32 bit (and not 16-bit) as it comprises of 16-bit I and Q each. http://www.ruby-forum.com/topic/182559 So the data samples that I am getting are in the form of I0,Q0,I0,Q0 or a sum: (I + Q)? If these are in the form of I0,Q0 ... then how do we keep a track that which one is an I and which one is a Q? If you use usrp_c() source, then the real part of the complex values are the I values and the imaginary parts are Q values. They are each 16 bits. Karthik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upcoming changes in the development trunk
On Wed, 2009-05-27 at 08:12 -0700, Johnathan Corgan wrote: On Wed, May 27, 2009 at 7:35 AM, Martin DvH gnuradiom...@olifantasia.com wrote: * Elimination of the single-threaded flowgraph scheduler. The thread-per-block scheduler is already the default in 3.2. While this won't require any code changes, if you've been manually selecting the STS via the environment, you won't be able to do this anymore. Is it really neccesary to remove this? Not strictly necessary, no. A lot of the new features in 3.3 will impact the scheduler, especially the new message passing between blocks. It will be extra work to modify both schedulers. This is Eric's area, however, so I'll let him comment further. OK, I get the picture. Since my single-threaded gpgpu-scheduler needs modifications as it is. Maybe you should implement the multi-threaded-scheduler and leave the scheduler choosing mechanism in place, and only leave stubs for the single-threaded case. I then could have a go at (trying to) implementing it for the single-threaded (gpgpu ) case. Eric, what's your view on this? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Format of captured data
Hi, On Wed, 5/27/09, Karthik karthik1...@gmail.com wrote: If you use usrp_c() source, then the real part of the complex values are the I values and the imaginary parts are Q values. They are each 16 bits. Karthik That is not correct. If you use usrp_c source, then I Q each are 32 bits (total complex is 64bits). However, if you use usrp_s, then each are 16 bits (total complex is 32bits).. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reading data from an xml file in python
Hello all! I have been experimenting with transfer of xml file between different computers. I need help in reading an xml file in pyton. I want the data in the xml file to be put into some variables. I have used minidom put still could not work it out in an easy way. I would be grateful if someone could post a complete code showing how could i retreive the data in some variable in python in some easy way for the simple xml file sample given below. ?xml version=1.0 encoding=UTF-8? sdr modulationQAM/modulation index4/index power50/power /sdr thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Format of captured data
Hi,I am not using GNU Radio, I am simply taking 16-bit data samples from the USRP in a small C++ interfacing program for Windows using usrp_standard.h. Now, I want to write my own FM demodulation code for these samples as I am not using GNU Radio, I won't be using any signal processing blocks, therefore I cannot use usrp.source_c [s] block. So in this case, what is my 16-bit sample representing? An I or Q or (I + Q)? On Thu, May 28, 2009 at 2:59 AM, Jason Uher jasonu...@gmail.com wrote: So the data samples that I am getting are in the form of I0,Q0,I0,Q0 or a sum: (I + Q)? If these are in the form of I0,Q0 ... then how do we keep a track that which one is an I and which one is a Q? Which usrp source are you using in gnuradio? There are both real sources, and complex sources. You want to use a complex source, in which case the data will be streamed as (I0+Q0i). Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
