[Discuss-gnuradio] Regarding use of GNU Radio for Primary User Emulation Attack
Dear Marcus, Thank you very much for your reply. I had asked you regarding Neural Network implementation on GNU radio. I want to explain my problem in detail. Well I am working on Primary user Emulation Attack in Cognitive Radio. My work includes identifying the Primary User signal from that of a malicious user signal using cyclostationary detection method. After that i want to use Neural Network for Signal classification and identification. I want to implement this on GNU Radio. I want to also test my results using USRP. I am new to GNU Radio and hence I am putting these questions to you. I may sound silly but please do answer my questions. Please help me. Best regards, M. Shriraghavan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tutorial issue: AttributeError: 'module' object has no attribute 'square2_ff'
Hi all, Thank you for your replies. "That's not a typo--Ubuntu, in their infinite wisdom, opted to change the name of that package mid-stream, so there's no way for build-gnuradio to really know which one of two will succeed, so it tries both--one of them WILL produce a (non-fatal) error." Thanks for the clarification, I will just leave the script as is then, it was probably foolish of me to believe that there is a typo in a carefully maintained script. I completed the instructions here: https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++ I followed the instructions very carefully as I have done in the past but I ended up with the same error: self.tutorial_my_qpsk_demod_cb_0 = tutorial.my_qpsk_demod_cb(True) AttributeError: 'module' object has no attribute 'my_qpsk_demod_cb' Any ideas? Thank you very much in advance Lefteris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-uhd timed command messages
When using messages, simply add a 'time' key to the command dictionary,
and it will be set for the command you're calling. The time stamp value,
is a long/double pair, for full and fractional time. Example:
{'freq': 1e9, 'time': (100, 0.1)}
If this is your message, it will set the frequency to 1 GHz at time 100.1.
Cheers,
Martin
On 03/02/2016 05:46 AM, Nigel Steed wrote:
> Hi,
>
>
>
> Anyone know or managed to implement the time command using a message
> port to the UHD Source Block ?
>
>
>
> I believe time commands are not implemented in the latest GNURadio
> gr-uhd ? Is that correct ?
>
>
>
> Thanks,
>
>
>
> Nigel
>
>
>
> ___
> 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] Tutorial issue: AttributeError: 'module' object has no attribute 'square2_ff'
Lefteris, I would recommend you follow the Guided Tutorials, instead of this page. The content should be mostly the same, the latter hasn't been updated lately, though. In your installation, the block isn't properly swigged. This is a standard procedure, so I recommend you start from scratch, use modtool, and follow the guided tutorials. Most likely it's a build artefact or something like that. Cheers, M On 03/02/2016 12:23 PM, Lefteris Kampianakis wrote: > Hello, > > I am experiencing problems with the tutorial on OOT development. I am > trying to implement the basic square_ff that is described here: > > https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules > > and I get the following error: > > File "MYPATHTOMODULE/Gnuradio/top_block.py", line 263, in > main() > File "MYPATHTOMODULE/Gnuradio/top_block.py", line 251, in main > tb = top_block_cls() > File "MYPATHTOMODULE/Gnuradio/top_block.py", line 117, in __init__ > self.howto_square2_ff_0 = howto.square2_ff() > AttributeError: 'module' object has no attribute 'square2_ff' > > where "MYPATHTOMODULE" is where I have saved the files. > > I have followed the instructions very carefully and the module appears > in GRC but the error is still there. > > I have recently seen the same issue in these threads: > > https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00156.html > https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00130.html > https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00364.html > > But in all cases people seem to have done something more other than just > the tutorial. > > Here's a link to my files: > https://www.dropbox.com/sh/phd3mzi6lwrh9vl/AAASUHh8Tj6PxrLEb78zYMTRa?dl=0 > > I installed gnuradio using the build-gnuradio script after I fixed the > libzmq-dev typo. > > * ldd libgnuradio-howto.so *gives the following output: > linux-vdso.so.1 => (0x7ffd821b1000) > libboost_system.so.1.54.0 => > /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7f3a0fcde000) > libgnuradio-runtime-3.7.9.1.so.0.0.0 => > /usr/local/lib/libgnuradio-runtime-3.7.9.1.so.0.0.0 (0x7f3a0fa0f000) > libgnuradio-pmt-3.7.9.1.so.0.0.0 => > /usr/local/lib/libgnuradio-pmt-3.7.9.1.so.0.0.0 (0x7f3a0f7c7000) > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f3a0f4c3000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f3a0f2ad000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3a0eee8000) > libvolk.so.1.2.1 => /usr/local/lib/libvolk.so.1.2.1 (0x7f3a0eb2a000) > libboost_filesystem.so.1.54.0 => > /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7f3a0e914000) > libboost_thread.so.1.54.0 => > /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7f3a0e6fe000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f3a0e4e) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3a0e2d8000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3a0dfd2000) > /lib64/ld-linux-x86-64.so.2 (0x7f3a100ed000) > liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 > (0x7f3a0dd5) > > > The problem appeared after I upgraded from ubuntu 12.04 to ubuntu 14.04 > if that helps. > uname -a gives: > 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 > x86_64 x86_64 GNU/Linux > > I had a module that acted as a very simple detector for my receiver that > converted a complex number to a binary value (byte output) that worked > fine before the upgrade that I have developed with the same method as > the tutorial. Now of course it doesn't work. > > I wouldn't send a message if I hadn't spend 3 days on this but now I am > really stuck. Please advise. > > > Thank you > Lefteris > > > ___ > 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] Tutorial issue: AttributeError: 'module' object has no attribute 'square2_ff'
On 03/02/2016 03:23 PM, Lefteris Kampianakis wrote: I installed gnuradio using the build-gnuradio script after I fixed the libzmq-dev typo. That's not a typo--Ubuntu, in their infinite wisdom, opted to change the name of that package mid-stream, so there's no way for build-gnuradio to really know which one of two will succeed, so it tries both--one of them WILL produce a (non-fatal) error. * ldd libgnuradio-howto.so *gives the following output: linux-vdso.so.1 => (0x7ffd821b1000) libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7f3a0fcde000) libgnuradio-runtime-3.7.9.1.so.0.0.0 => /usr/local/lib/libgnuradio-runtime-3.7.9.1.so.0.0.0 (0x7f3a0fa0f000) libgnuradio-pmt-3.7.9.1.so.0.0.0 => /usr/local/lib/libgnuradio-pmt-3.7.9.1.so.0.0.0 (0x7f3a0f7c7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f3a0f4c3000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f3a0f2ad000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3a0eee8000) libvolk.so.1.2.1 => /usr/local/lib/libvolk.so.1.2.1 (0x7f3a0eb2a000) libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7f3a0e914000) libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7f3a0e6fe000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3a0e4e) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3a0e2d8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3a0dfd2000) /lib64/ld-linux-x86-64.so.2 (0x7f3a100ed000) liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x7f3a0dd5) The problem appeared after I upgraded from ubuntu 12.04 to ubuntu 14.04 if that helps. uname -a gives: 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I had a module that acted as a very simple detector for my receiver that converted a complex number to a binary value (byte output) that worked fine before the upgrade that I have developed with the same method as the tutorial. Now of course it doesn't work. I wouldn't send a message if I hadn't spend 3 days on this but now I am really stuck. Please advise. Thank you Lefteris ___ 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] Tutorial issue: AttributeError: 'module' object has no attribute 'square2_ff'
Hello, I am experiencing problems with the tutorial on OOT development. I am trying to implement the basic square_ff that is described here: https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules and I get the following error: File "MYPATHTOMODULE/Gnuradio/top_block.py", line 263, in main() File "MYPATHTOMODULE/Gnuradio/top_block.py", line 251, in main tb = top_block_cls() File "MYPATHTOMODULE/Gnuradio/top_block.py", line 117, in __init__ self.howto_square2_ff_0 = howto.square2_ff() AttributeError: 'module' object has no attribute 'square2_ff' where "MYPATHTOMODULE" is where I have saved the files. I have followed the instructions very carefully and the module appears in GRC but the error is still there. I have recently seen the same issue in these threads: https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00156.html https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00130.html https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00364.html But in all cases people seem to have done something more other than just the tutorial. Here's a link to my files: https://www.dropbox.com/sh/phd3mzi6lwrh9vl/AAASUHh8Tj6PxrLEb78zYMTRa?dl=0 I installed gnuradio using the build-gnuradio script after I fixed the libzmq-dev typo. * ldd libgnuradio-howto.so *gives the following output: linux-vdso.so.1 => (0x7ffd821b1000) libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7f3a0fcde000) libgnuradio-runtime-3.7.9.1.so.0.0.0 => /usr/local/lib/libgnuradio-runtime-3.7.9.1.so.0.0.0 (0x7f3a0fa0f000) libgnuradio-pmt-3.7.9.1.so.0.0.0 => /usr/local/lib/libgnuradio-pmt-3.7.9.1.so.0.0.0 (0x7f3a0f7c7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f3a0f4c3000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f3a0f2ad000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3a0eee8000) libvolk.so.1.2.1 => /usr/local/lib/libvolk.so.1.2.1 (0x7f3a0eb2a000) libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7f3a0e914000) libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7f3a0e6fe000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3a0e4e) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3a0e2d8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3a0dfd2000) /lib64/ld-linux-x86-64.so.2 (0x7f3a100ed000) liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x7f3a0dd5) The problem appeared after I upgraded from ubuntu 12.04 to ubuntu 14.04 if that helps. uname -a gives: 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I had a module that acted as a very simple detector for my receiver that converted a complex number to a binary value (byte output) that worked fine before the upgrade that I have developed with the same method as the tutorial. Now of course it doesn't work. I wouldn't send a message if I hadn't spend 3 days on this but now I am really stuck. Please advise. Thank you Lefteris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [spectrum sense bug][usrp]
Hi Heitor, if the same applies to you just displaying e.g. 10MHz of bandwidth with uhd_fft, you probably have a hefty oscillator offset, either on the N210 10MHz reference or your signal generator. What generates your signal, and which LEDs are active on your N210? Best regards, Marcus On 02.03.2016 21:06, Heitor Araujo wrote: > Hi > > I'm trying to do a basic spectrum sense with a USRP N210 kit and gnuradio. > > I made a literature research and noted that the > “usrp_spectrum_sense.py” code was used in some articles. But when > transmit some signal in a certain frequecy and execute the > “usrp_spectrum_sense.py”, the signal is found by the code, but it > appears in another frequency (usually about 1Mhz ahead). And also the > bandwidth of the received signal is different from the transmited > signal (It seems it depends of the sample rate of the transmited the > signal). > > sudo ./usrp_spectrum_sense.py 699M 702M --fft 512 and execute the > "uhd_tx_dpsk.grc" in gnuradio to transmit the signal from 700.2M tom > 700.4M. The signal is detected in 700.7M to 701M. > > Thanks > > > > > > > > > > ___ > 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] [spectrum sense bug][usrp]
Hi I'm trying to do a basic spectrum sense with a USRP N210 kit and gnuradio. I made a literature research and noted that the “usrp_spectrum_sense.py” code was used in some articles. But when transmit some signal in a certain frequecy and execute the “usrp_spectrum_sense.py”, the signal is found by the code, but it appears in another frequency (usually about 1Mhz ahead). And also the bandwidth of the received signal is different from the transmited signal (It seems it depends of the sample rate of the transmited the signal). sudo ./usrp_spectrum_sense.py 699M 702M --fft 512 and execute the "uhd_tx_dpsk.grc" in gnuradio to transmit the signal from 700.2M tom 700.4M. The signal is detected in 700.7M to 701M. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] calculate data rate
On 03/02/2016 02:00 PM, Diyar Muhammed wrote: Dear ALL for example we use qpsk modulation and 1M sample rate, what is the transmission throughput? data rate - You're going to have to decide what *symbol rate* want, and whether the resulting signal bandwidth fits into your 1M sample rate. Simple QPSK carries two bits/symbol. Do some research on the bandwidth occupied by a QPSK signal at a given symbol rate, and then use your stated 1M sample rate to see how much you can "fit in" to a 1M sample rate. Your question is more about signals, signal processing, and their properties in the time and frequency domain which is quite independent from which signal processing framework you're using. I encourage you to do some research. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] calculate data rate
Dear ALL for example we use qpsk modulation and 1M sample rate, what is the transmission throughput? data rate -- Regards, Diyar Muhammed Ministry of Higher Education and Scientific Research Duty: Network Administration and Design Website: www.mhe-krg.org Cell Phone: 009647504690060 Office Phone: 00964662554683 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation
On 03/02/2016 08:41 AM, Nigel Steed wrote:
Hi Marcus,
I have now tried exactly that and it works. Thanks. One thing I am
trying now is to implement the command times over the message ports
but if you say time commands are not supported in gr-uhd I maybe
stuck. I see the functions are in a ifdef.
Thanks,
Nigel
Again, gr-uhd has bindings for timed-commands, it's just that the *GRC*
block logic has no way of using them. But if you hand-code
Python, or edit the output of GRC, you can wrap your tunings in timed
commands.
*From:*discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org
[mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] *On
Behalf Of *Marcus D. Leech
*Sent:* 02 March 2016 02:08
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] UHD Source Block and N210/SBX
Synchronisation
On 03/01/2016 10:43 AM, Marcus D. Leech wrote:
The only thing really missing in gr-uhd is the ability to do timed
commands. You can force integer-N mode by constructing your own
tune_request that includes the integer-N option. You'd use a
feature from the latest Gnu Radio to help you with this, because
it involves
getting into the internal structure of a tune_request blob.
So, use the "Python module" block, and in that Python do something
like:
def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r
Then, in your UHD source/sink block, instead of using your target
frequency directly, use:
your_module_name.integer_N_tune_me(desired_freq)
Martin could probably comment on the feasibility of adding timed
commands to gr-uhd.
What I actually meant wasn't that gr-uhd doesn't have timed-command
support, but rather, the GRC scaffolding for this doesn't really
exist. If you write your own Python, you can of course use
timed-commands with gr-uhd, and in fact if you're willing to edit the
output of GRC (generated Python) you can wire-in timed-commands
fairly easily, it's just that there's no way to set this up with
the existing UHD blocks for GRC (yet).
___
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] Spectral Survey with GRC?
Hi GRC companions Has anyone used GRC to acquire a large range RF spectral survey? Basically, step from range to range, and save the output in a (text) file. I would like to be able to average each frequency/range for some (variable) period of time, or do peak hold, much like some of the nice FFT sinks do. I have been doing this in Python with a modification of osmocom_spectrum_sense, but I would rather use GRC since it is more intuitive. I just need a starting point, and particularly how to save to file, and time average. This seems like it would be pretty straightforward, but I haven't seen it done anywhere (with GRC). A little background. I am working on a research project on ambient RF energy harvesting (using printed metamaterial antennas). I recently got a HackRF One to help understand the ambient RF energy present and correlate it with energy harvesting performance. Thanks in advance! --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-uhd timed command messages
Hi, Anyone know or managed to implement the time command using a message port to the UHD Source Block ? I believe time commands are not implemented in the latest GNURadio gr-uhd ? Is that correct ? Thanks, Nigel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation
Hi Marcus,
I have now tried exactly that and it works. Thanks. One thing I am trying now
is to implement the command times over the message ports but if you say time
commands are not supported in gr-uhd I maybe stuck. I see the functions are in
a ifdef.
Thanks,
Nigel
From: discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org
[mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] On Behalf Of
Marcus D. Leech
Sent: 02 March 2016 02:08
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation
On 03/01/2016 10:43 AM, Marcus D. Leech wrote:
The only thing really missing in gr-uhd is the ability to do timed commands.
You can force integer-N mode by constructing your own
tune_request that includes the integer-N option. You'd use a feature from
the latest Gnu Radio to help you with this, because it involves
getting into the internal structure of a tune_request blob. So, use the
"Python module" block, and in that Python do something like:
def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r
Then, in your UHD source/sink block, instead of using your target frequency
directly, use:
your_module_name.integer_N_tune_me(desired_freq)
Martin could probably comment on the feasibility of adding timed commands to
gr-uhd.
What I actually meant wasn't that gr-uhd doesn't have timed-command support,
but rather, the GRC scaffolding for this doesn't really
exist. If you write your own Python, you can of course use timed-commands
with gr-uhd, and in fact if you're willing to edit the
output of GRC (generated Python) you can wire-in timed-commands fairly
easily, it's just that there's no way to set this up with
the existing UHD blocks for GRC (yet).
___
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] ControlPort setup_rpc function not called for pure message passing blocks
Dear mailing list, we are trying to create a status overview of our receiver by using the control ports feature. For most of our custom made blocks this works very well and we can see the exported variables. But for a few blocks the exported variables do not show up in the control port monitor. After putting tracing lines in these blocks we found out that the setup_rpc function is not called. The only difference we could see between the blocks were the setup_rpc function is called and the ones where it is not is that the latter have no stream in- or output. Instead they only use the message passing API to process data, like the mesage debug block from GNURadio. A minimal working example of a block whichs setup_rpc() method is not called can be found at http://pastebin.com/cBFJCnW7 with private and public header files at http://pastebin.com/35WhFqQ0 and http://pastebin.com/zb4jBRAw If we run this block and feed messages to it, we get the following output: constructor() ControlPort Monitor running. INFO: Apache Thrift: -h localhost -p 40444 monitor::endpoints() = -h localhost -p 40444 process frame() process frame() [...] process frame() process frame() running: ['gr-ctrlport-monitor', 'localhost', '40444'] process frame() process frame() [...] process frame() process frame() We would expect to see an additional line at the beginning saying "setup_rpc()" (see line 71 of the c++ code) and consequently see the variable "testval" in the control port monitor, like it does for our working blocks. The above output is generated with GNURadio version 3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu trusty system (64 bit). The only difference we could find between the blocks working as expected and the ones that do not, is that they use streaming for data transport, i.e. that their work or general_work function has some actual data processing and their gr::io_signature is not set to (0,0,0). I kindly ask for your help to find out why the setup_rpc function is not called for our example block posted above and what we can do to change this. Yours sincerely Martin Luelf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] probe sample rate block
Hi, I believe the problem with the 'small polyphase channelization application' that I posted to the list could be related to the polyphase channelizer block downsampling the channels, and consequently insufficient samples are making it to the PHY receivers for them to decode packets. I would like to test this with the sample probe block but it does not work the way I expect. I added a probe rate block and gave it an ID, 'p_rate'. I used 'p_rate' as the default value of a WX GUI text box. It could not evaluate 'p_rate' because it was not defined. I also tried putting this as the default value of the text box but it did not work: blocks.probe_rate(gr.sizeof_gr_complex*1, 500.0, 0.15).rate() What is the proper way to do this? Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
