Re: [Discuss-gnuradio] Printing from c++ code
My first guess is that you have gnuradio modules installed on more than
one place in your system; older modules compiled without the printfs are
being used, and the newer ones have second priority in the search path.
Try a sudo make uninstall, and run your program, you should get errors.
My second guess would be that your work function is not getting called,
or there is some conditional logic before the printfs. Try putting some
printfs in the constructor of the block, just to prove to yourself that
it prints on instantiation.
-Josh
David Knox wrote:
I am unable to print from C++ code in gnuradio. I have tried various
combinations of included libraries and different types of print statements
in my C++ code. However, nothing that I have tried yet (see some attempts
below) has let me see any output from the command terminal (where my printed
python output appears). I found an old response from Eric B. for a similar
problem, but the offered solution did not work for me either.
// #include// DAK
#include
// #include// DAK
// #include // DAK
#include
fprintf(stdout, "\nTEST");
fprintf(stderr, "\nTEST");
printf ("\nThis is a test");
fprintf(stderr, "Samples Processed: %d\n", d_processed), fflush(stderr);
During the make/make install process (executed from the /src and /src/lib
directories after my experimental changes; not sure where I'm supposed to do
this). I see errors if my C++ syntax is not correct, so presumably my
changes are actually being compiled and I also see the corresponding object
file times changing appropriately. There could well be a problem with the
importing of modules in python or C++ and/or my directory structure or
paths sort of why I need the print statements to work in the first
place.
I don't claim to understand the hierarchy of python/swig/c++ calls or the
autotools processes yet. My basic task is to figure out the execution
progress and sequencing of some routines written by others (which are a bit
more complicated than the one in D. Shen's tutorial). I want to understand
the control flow for some ucla 802.15.4 extension code to gnuradio,
specifically in the receive direction.
In general, how should/could standard I/O work out of a C++ program through
SWIG into python? Could someone tell me what is *supposed* to work (i.e.
maybe the pertinent #include and (f)printf statements. Alternatively, maybe
someone could give alternatives to my primitive approach for understanding
python/C++ program control flow and calling structure? I have tried using
the python interpreter and manually listing modules and module paths after
each encountered import statement; pretty tedious.
Presumably, there could be issues if C++ print statements get executed at
the same rate as RF data is processed... but right now being swamped by
print statement output from the signal processing code would be a welcome
problem!
Thanks, David
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
>> Another study you could look at is >> ftp://ftp.cs.washington.edu/tr/2009/10/UW-CSE-09-10-02.PDF >> >> It gives another overview of where latency comes from, and shows how you can >> get around some of it. >> We were able to get turnaround times for our application below 300 us by >> making a few simple modifications to the GNU Radio C++ code. > >Nice work! Have these modifications been accepted upstream? It would >be great if your RFID reader was a standard part of GNU Radio -- I >suspect that a lot more experimenters would start messing with RFID. >And it would be even better if every interactive GNU Radio application >could benefit from the latency improvements you made. > > John I will be uploading the RFID reader code to CGRAN in the next week or so, and will post to this list when that happens. The GNU Radio subsystem and scheduler modifications for reducing latency will be included. More work would need to be done to show that it is the always the right approach for all applications before trying to push it into the trunk. -michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Printing from c++ code
I am unable to print from C++ code in gnuradio. I have tried various
combinations of included libraries and different types of print statements
in my C++ code. However, nothing that I have tried yet (see some attempts
below) has let me see any output from the command terminal (where my printed
python output appears). I found an old response from Eric B. for a similar
problem, but the offered solution did not work for me either.
// #include// DAK
#include
// #include// DAK
// #include // DAK
#include
fprintf(stdout, "\nTEST");
fprintf(stderr, "\nTEST");
printf ("\nThis is a test");
fprintf(stderr, "Samples Processed: %d\n", d_processed), fflush(stderr);
During the make/make install process (executed from the /src and /src/lib
directories after my experimental changes; not sure where I'm supposed to do
this). I see errors if my C++ syntax is not correct, so presumably my
changes are actually being compiled and I also see the corresponding object
file times changing appropriately. There could well be a problem with the
importing of modules in python or C++ and/or my directory structure or
paths sort of why I need the print statements to work in the first
place.
I don't claim to understand the hierarchy of python/swig/c++ calls or the
autotools processes yet. My basic task is to figure out the execution
progress and sequencing of some routines written by others (which are a bit
more complicated than the one in D. Shen's tutorial). I want to understand
the control flow for some ucla 802.15.4 extension code to gnuradio,
specifically in the receive direction.
In general, how should/could standard I/O work out of a C++ program through
SWIG into python? Could someone tell me what is *supposed* to work (i.e.
maybe the pertinent #include and (f)printf statements. Alternatively, maybe
someone could give alternatives to my primitive approach for understanding
python/C++ program control flow and calling structure? I have tried using
the python interpreter and manually listing modules and module paths after
each encountered import statement; pretty tedious.
Presumably, there could be issues if C++ print statements get executed at
the same rate as RF data is processed... but right now being swamped by
print statement output from the signal processing code would be a welcome
problem!
Thanks, David
--
View this message in context:
http://www.nabble.com/Printing-from-c%2B%2B-code-tp25891709p25891709.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] USRP1 DBSRX read ADC values
I am using USRP1 with DBSRX. My goal is to implement signal conditioning algorithm. Input is the tuned frequency, output is the optimal gain settings to utilize the full range of ADCs with saturation below acceptable threshold. As the RSSI is not available for DBSRX, the idea is to acquire a short signal and analyze the ADC values. The gain value will be set iteratively according the clipping rate and number of utilized ADC bits. I need to analyze the ADC values, as the further processing (e.g. CIC) "corrupts" the signal and the strategy mention above could not be used. My question is how can I read the ADC values? Can I use: adc_val = u->read_aux_adc(which_side, which_adc) In the post http://www.nabble.com/aux_adc-inputs-td9441955.html#a9441955 aux_adc inputs stands the AUX_ADC is not wired for DVBRX. Can anyone give me a hint how to read the ADC values? -- View this message in context: http://www.nabble.com/USRP1-DBSRX-read-ADC-values-tp25888607p25888607.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] why "usrp2::tx_raw: FIXME: short packet" still appear
Hello all, I tried 'ofdm example' on my two computers. I used 'benchmark_ofdm_tx.py' and 'benchmark_ofdm_rx.py' for test. 1. If I use computer A as transmiter and computer B as receiver. The transmission is successful. 2. But if I take B as transmitter and A as receiver. B will report 'usrp2::tx_raw: FIXME: short packet' sometimes. 3. And if B transmits in discontinuous mode, the error 'short packet' disappear but the signal transmitted out still seems not correct since A cannot demodulate it correctly. Some data may be lost at the transmitter side. (Later, I'll open logging to confirm this.) I had a look in the discussion list and I found this error should have been fixed in gnuradio3.2.2. But at that time computer B used gnuradio3.2.0. So I reinstalled gnuradio for version 3.2.2. But this error still appears. A computer is FC8 + gnuradio3.2.2 B computer is FC10 + gnuradio3.2.2 What does other configuration need to make the ethernet port work well? Thanks a lot for your help!! Best Wishes Lin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
