Re: FOSDEM 2020: Free Software Radio Devroom CfP
Dear friends and fans of software-defined radio, the SDR track at next year's FOSDEM still has some slots left! We already have some submissions and we are in the process of ranking those, but we will gladly add YOUR presentation to the list! If you have anything related to the field of free software radio, please head to: https://penta.fosdem.org/submission/FOSDEM20 and submit your short abstract! We're looking very much forward to your submission. For the committee, Nicolas Cuervo On Wed, Oct 16, 2019 at 8:19 PM Nicolas Cuervo Benavides < cuervonico...@gmail.com> wrote: > Dear friends and fans of software-defined radio and free/open-source radio > topics in general, > > FOSDEM 2020 (the free and open-source developer's meeting in Brussels, > Europe) will, once again, feature a track on Software Defined Radio, and > any other radio-related topics in the (now known as) *Free Software Radio* > devroom. > Therefore, we invite developers and users from the free software radio > community to join us for this track and present your talks or demos. > > > Software Radio has become an important tool to allow anyone to access the > EM spectrum. Using free software radio libraries and applications and cheap > hardware, anyone can now start hacking on wireless communications, remote > sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, > we hope to network all these projects and improve collaboration, bring new > ideas forward and get more people involved. > > > The track's web site resides at the link below. The final schedule will be > available through Pentabarf and the official FOSDEM website. > > https://fosdem.org/2020/schedule/track/free_software_radio/ > > > Additional Information will be also available at: > https://wiki.gnuradio.org/index.php/FOSDEM_2020 > > > ** Submit your presentations > > To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and > follow the instructions (you need an account, but can use your account from > last year if you have one). You need to create an 'Event'; make sure it's > in the Free Software Radio track! Lengths aren't fixed, but give a > realistic estimate and please don't exceed 30 minutes unless you have > something special planned (in that case, contact one of us). Also, don't > forget to include time for Q&A. > We will typically go for 30-minute slots -- shorter talks, unless they're > really short, usually tend to screw up the schedule too much. > > You aren't limited to slide presentations, of course. Be creative. > However, FOSDEM is an open-source conference, therefore we ask you to stay > clear of marketing presentations and present something relevant to > free/open software. We like nitty-gritty technical stuff. > > Topics discussed in this devroom include: > > * SDR Frameworks + Tools > * Cellular/telecoms software > * Free/Open SDR hardware > * Wireless security > * Random fun wireless hacks > * SDR in education > * Satellite/spacecraft communication > * Ham radio related topics > > > ** Important Dates > > FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is > happening on Sunday, the 2nd of February. > > The submission deadline is Friday, December 6th. A complete schedule for > the presentations in the devroom will be available on the 15th of December. > > > In the last years we were always full to the brim with presentations, so > if you want to present, please make sure to submit your abstracts soon! > > ** Steering Committee > The track committee consists of: > > * Phil Balister - "Crofton" > * Sylvain Munaut -"tnt" > * Derek Kozel - "dkozel" > * Nicolas Cuervo - "primercuervo" > * Martin Braun - "mbr0wn" (Emeritus) > > > Hope to hear from you soon! And please forward this announcement. >
More on C++11 requirements
Playing with a project (gr-radio_astro from WVURAIL: https://github.com/WVURAIL/gr-radio_astro), and running into compile issues on older OS (Fedora 20 in this case). Now, the interesting thing is that my GCC appears to have support for c++11 (since -std=c++11 works as a command arg), and despite the fact that the CMakelists.txt file for the project includes: # Compiler specific setup if(CMAKE_COMPILER_IS_GNUCXX AND NOT WIN32) #http://gcc.gnu.org/wiki/Visibility add_definitions(-fvisibility=hidden) set(CMAKE_CXX_STANDARD 11) endif() There doesn't appear to be any use of -std=c++11 in the Make files generated, and one gets compile errors for source that includes C++11 features/syntax. Are there extra "sets" in the CMakeLists.txt that I should be using to force it to use the c++11 compiler options? Cheers
GNU Radio Companion Error for Custom OOT cpp block
Hi all,
I have created my first custom OOT block in c++
It works when my block takes no inputs.
However, after changing my block signature to allow one input variable (called
samp_rate), I am getting the following error in GRC:
self.custom_blocks_readfilesource_cpp_0 =
custom_blocks.readfilesource_cpp(samp_rate)
TypeError: make() takes no arguments (1 given)
As you can see, my block is called "readfilesource_cpp"
I have updated the make function in readfilesoure_cpp.h like so:
static sptr make(float input_sample_rate = 1.0);
I have updated the make function and constructor in my
"readfilesource_cpp_impl.cpp" file like so:
readfilesource_cpp::sptr readfilesource_cpp::make(float input_sample_rate) {
return gnuradio::get_initial_sptr (new
readfilesource_cpp_impl(input_sample_rate));
}
/* The private constructor */
readfilesource_cpp_impl::readfilesource_cpp_impl(float input_sample_rate)
: gr::sync_block("readfilesource_cpp",gr::io_signature::make(0, 0,
0),gr::io_signature::make(1, 1, sizeof(float))),
sample_rate(input_sample_rate)
{}
I downloaded the gnu radio source code from github and compared the
char_to_float block to my own. I can't see why mine isn't working.
Cheers,
Mike
p.s.
Why are there two header files for a block? why is _impl automatically added
to my files by gr_modtool?
Custom OOT Block Running on USRP + General GNU Radio Questions.
Hi guys, Firstly, I feel obliged to explain that I'm a young engineer relatively new to Linux, SDR, GNU radio and USRP, and currently overwhelmed with the task assigned to me! Many thanks in advance to any help provided. First time posting to the I have written a custom OOT block for GNU Radio that reads in information from a file (in this case, pulse width (PW), and pulse repetition interval (PRI)), and outputs a corresponding waveform with matching characteristics. I am attempting to run this from a USRP E312 device. It is currently partially working, and I have several questions: 1/ In the work function, an output array is provided as follows "out = output_items[0]". The length of this array seems to be maxed at 8192, however some times it's much less. Is this because the scheduler doesn't always have enough resources to do the send the full 8192 - I found this statement GNU website somewhere, is it related to this 'phenomenon'? /* By default, GNU Radio runs a scheduler that attempts to optimize throughput. Using a dynamic scheduler, blocks in a flowgraph pass chunks of items from sources to sinks.The sizes of these chunks will vary depending on the speed of processing. For each block, the number of items it can process is dependent on how much space it has in its output buffer(s) and how many items are available on the input buffer(s). */ Could someone please explain the output_items object to me? 2/ This is how i'm setting the output, out array within my custom block work function: self.num_samples_pri = int(self.sample_rate * float(self.pri)) self.num_samples_pw = int(self.sample_rate * float(self.pw)) for i in range(self.num_samples_pri): if i < len(out): if i < self.num_samples_pw: out[i] = 1 else: out[i] = 0 If the out array length is < num_samples_pw, my waveform is cut short, and I get uneven spacing between some of the waveform pulses. My question is, how do I deal with this issue? I have tried to appending more elements to out array, but they seem to be ignored. 3/ I have built a GRC project with my custom block as source, and UHD: USRP sink block as output so that I can run my project soley on the USRP device with no connection to the PC. When I run the compiled file on my USRP device, I am getting continuous under-run errors. I know that under-run occurs when a block is not receiving enough samples. In my case, the sample rate used in my code matches that entered in the UHD USRP sink block. D Is the underrun occurring because my USRP device isn't running my custom code fast enough? How do I deal with this? 4/ Should I be using custom blocks written in C++ instead of python, when the intent is to run on the USRP device. I have heard that C++ is faster. 5/ I was able to run my custom PYTHON block from the USRP by copying the gr-custom_block folder to the device, and building using cmake, etc. however the C++ implementation of my custom block was not recognized. AttributeError: 'module' object has no attribute 'readfilesource_cpp' I got some advice on stack overflow about setting up a cross compilation tool-chain, and recommended Ettus procedures to follow AN-311 and AN-315. However, It was a struggle. I would love some more advice on this! Cheers, Mike
Re: Custom OOT Block Running on USRP + General GNU Radio Questions.
Hello Mike, I never used USRP E3xx series boards, so I coud be off on some points, but: 1: Yes, you are correct. If I recall correctly, it uses a ring buffer-like structure. Length of the output buffer is basically amount of data points that you can safely write to the buffer at the moment, and therefore variable. There are a few functions that can affect the buffer size. See: https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html (assumes C++, though). 2: If your output buffer is too small, just keep your unwritten data in a some internal array (self.something) and write to the output buffer during the next round or wait (and do not write to the buffer) until the buffer grows large enough (maybe there are better ways to do this - can anyone help?). By the way, I believe you are using Python to write OOT blocks. Python OOT blocks can be extremely slow, especially if you are using for and if statements and/or running it on an low-power ARM board. Use Python tricks to minimise the number of for and if statments (use something like "a[0:2] = [1] * 2 "). It is just like writing a Matlab/Octave simulation. 3: "Sampling Rate" in the GNU Radio blocks, except in some hardware sources/sinks (including "UHD: USRP sink") and the "Throttle" block (which is for simulation purposes), is just a concept. It does not actually affect the processing speed of the code, and is there to solely make your calculations easier (by allowing you to think in Hertz, instead of in Radians). Actual processing speed is defined by the sampling rate of the hardware sources/sink blocks in your flow graph (the "UHD: USRP Sink" block, in this case), and all other blocks will just try to generate as many samples as they can, regardless of their configured sampling rates. So, if your codes can generate samples fast enough, and if you do not have conflicting settings (more than two instances of hardware sources/sinks , or "Throttle" blocks, with conflicting sampling rates), you should not see any underruns. I think your codes are indeed running too slow, especially since the processing power of E313 is very limited. To verify this, replace your "UHD: USRP Sink" with a "Null Sink" block and attach "Probe Rate" -> "Message Debug" to your code (I've never done this on a E313, but I think it should still work). It will show you the maximum throughput of your flowgraph. If this is indeed the case, you must try optimising your codes, or re-write them in C++ (Or even better, see if you can push things to RFNoC). 4: It depends (there are some cases where you can write fast Python blocks), but yes, C++ blocks are usually _way_ faster, and you are better off with C++ blocks, especially if you are dealing with low-power ARM chips. Poorly written C++ blocks can still run very slowly, so please read OOT blocks that other people wrote before moving on ( http://cgran.hopto.org/ ). RFNoC is also an option for USRP E3xx / X3xx series boards. The Cortex-A9 CPUs in your USRP E313 have very limited computational power, so you may HAVE to use RFNoC. That requires some HDL experiences, however (FPGA development required). 5: (maybe someone else can answer this?) Regards, Kyeong Su Shin 보낸 사람: Michael Bassi 대신 Discuss-gnuradio 보낸 날짜: 2019년 11월 25일 월요일 오전 9:32 받는 사람: Discuss Gnuradio 제목: Custom OOT Block Running on USRP + General GNU Radio Questions. Hi guys, Firstly, I feel obliged to explain that I'm a young engineer relatively new to Linux, SDR, GNU radio and USRP, and currently overwhelmed with the task assigned to me! Many thanks in advance to any help provided. First time posting to the I have written a custom OOT block for GNU Radio that reads in information from a file (in this case, pulse width (PW), and pulse repetition interval (PRI)), and outputs a corresponding waveform with matching characteristics. I am attempting to run this from a USRP E312 device. It is currently partially working, and I have several questions: 1/ In the work function, an output array is provided as follows "out = output_items[0]". The length of this array seems to be maxed at 8192, however some times it's much less. Is this because the scheduler doesn't always have enough resources to do the send the full 8192 - I found this statement GNU website somewhere, is it related to this 'phenomenon'? /* By default, GNU Radio runs a scheduler that attempts to optimize throughput. Using a dynamic scheduler, blocks in a flowgraph pass chunks of items from sources to sinks.The sizes of these chunks will vary depending on the speed of processing. For each block, the number of items it can process is dependent on how much space it has in its output buffer(s) and how many items are available on the input buffer(s). */ Could someone please explain the output_items object to me? 2/ This is how i'm setting the output, out array within my custom block work function: self.num_samples_p
Re: Custom OOT Block Running on USRP + General GNU Radio Questions.
The function call set_output_multiple() is your friend. You can specify
the size of the output buffer explicitly (although it may be 2X, 3X,
etc. of that size). Here's some example code.
Ron
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include "buffer_cc_impl.h"
#define CHUNK_SIZE 8900
namespace gr {
namespace michael {
buffer_cc::sptr
buffer_cc::make()
{
return gnuradio::get_initial_sptr
(new buffer_cc_impl());
}
/*
* The private constructor
*/
buffer_cc_impl::buffer_cc_impl()
: gr::block("buffer_cc",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex)))
{
set_output_multiple(CHUNK_SIZE);
}
/*
* Our virtual destructor.
*/
buffer_cc_impl::~buffer_cc_impl()
{
}
void
buffer_cc_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}
int
buffer_cc_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
printf("noutput_items = %d\n", noutput_items);
for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
in += CHUNK_SIZE;
out += CHUNK_SIZE;
}
consume_each (noutput_items);
// Tell runtime system how many output items we produced.
return noutput_items;
}
} /* namespace michael */
} /* namespace gr */
On 11/24/19 16:32, Michael Bassi wrote:
Hi guys,
Firstly, I feel obliged to explain that I'm a young engineer
relatively new to Linux, SDR, GNU radio and USRP, and currently
overwhelmed with the task assigned to me! Many thanks in advance to
any help provided. First time posting to the
I have written a custom OOT block for GNU Radio that reads in
information from a file (in this case, pulse width (PW), and pulse
repetition interval (PRI)), and outputs a corresponding waveform with
matching characteristics. I am attempting to run this from a USRP E312
device. It is currently partially working, and I have several questions:
1/ In the work function, an output array is provided as follows "out =
output_items[0]". The length of this array seems to be maxed at 8192,
however some times it's much less. Is this because the scheduler
doesn't always have enough resources to do the send the full 8192 - I
found this statement GNU website somewhere, is it related to this
'phenomenon'?
/* By default, GNU Radio runs a scheduler that attempts to optimize
throughput. Using a dynamic scheduler,blocks in a flowgraph pass
chunks of items from sources to sinks.The sizes of these chunks will
vary depending on the speed of processing. For each block, the number
of items it can process is dependent on how much space it has in its
output buffer(s) and how many items are available on the input
buffer(s). */
Could someone please explain the output_items object to me?
2/ This is how i'm setting the output, out array within my custom
block work function:
self.num_samples_pri = int(self.sample_rate * float(self.pri))
self.num_samples_pw = int(self.sample_rate * float(self.pw))
for i in range(self.num_samples_pri):
if i < len(out):
if i < self.num_samples_pw:
out[i] = 1
else:
out[i] = 0
If the out array length is < num_samples_pw, my waveform is cut short,
and I get uneven spacing between some of the waveform pulses.
My question is, how do I deal with this issue? I have tried to
appending more elements to out array, but they seem to be ignored.
3/ I have built a GRC project with my custom block as source, and UHD:
USRP sink block as output so that I can run my project soley on the
USRP device with no connection to the PC.
When I run the compiled file on my USRP device, I am getting
continuous under-run errors.I know that under-run occurs when a block
is not receiving enough samples. In my case, the sample rate used in
my code matches that entered in the UHD USRP sink block. D
Is the underrun occurring because my USRP device isn't running my
custom code fast enough?
How do I deal with this?
4/ Should I be using custom blocks written in C++ instead of python,
when the intent is to run on the USRP device. I have heard that C++ is
faster.
5/ I was able to run my custom PYTHON block from the USRP by copying
the gr-custom_block folder to the device, and building using cmake,
etc. however the C++ implementation of my custom block was not
recognized.
AttributeError: 'module' object has no attribute '
Re: Custom OOT Block Running on USRP + General GNU Radio Questions.
Thank you, Kyeong I really appreciate your reply. 1/ Does anyone have experience using these functions? would any help with 2/? 2/ Thank you. It looks like the work function input array "output_items" is a numpy array. I was therefore able to eliminate the for loop. I am also now return = 0 if the output buffer isn't long enough. My waveform PRI now appears to be consistent upon visual inspection. out = output_items[0] if not len(out) < self.num_samples_pri: out[:self.num_samples_pw] = 1.0 out[self.num_samples_pw:] = 0.0 num_out = self.num_samples_pri else: num_out = 0 return num_out This may just be a quick fix though. My PRI may be longer than expected in some cases, and I should be doing like you suggest by keeping some internal array. Does anyone know how to implement this properly? Assuming it is necessary? 3/ With the python code improvements, I am still getting under-runs at the same sample rate of 1e6. However, after reducing the samp rate by a factor of 10 (to 1e5 samp/sec). I am no longer getting under-run... Would this be because my code is now working with smaller arrays and therefore runs faster? Or because the UHD: USRP sink samp rate is set to a rate that it can 'handle'? I still have a shaky understanding of what sampling rate means here. I have attached Probe Rate -> Message Debug blocks to the output of my custom block, as you suggested. rate_now and rate_ave appear to be consistent with my defined sampling rate. Is there a specific test you do with these blocks? what do you look for? I have the C++ implementation ready to go, though still having troubles running my custom blocks from the USRP (see 5/) RFNoC is just plain intimidating. 4/ Thanks I will check out other custom blocks. 5/ Yes, hopefully someone can help! Thanks again, Mike From: Kyeong Su Shin Sent: 25 November 2019 13:44 To: Michael Bassi ; Discuss Gnuradio Subject: Re: Custom OOT Block Running on USRP + General GNU Radio Questions. Hello Mike, I never used USRP E3xx series boards, so I coud be off on some points, but: 1: Yes, you are correct. If I recall correctly, it uses a ring buffer-like structure. Length of the output buffer is basically amount of data points that you can safely write to the buffer at the moment, and therefore variable. There are a few functions that can affect the buffer size. See: https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html (assumes C++, though). 2: If your output buffer is too small, just keep your unwritten data in a some internal array (self.something) and write to the output buffer during the next round or wait (and do not write to the buffer) until the buffer grows large enough (maybe there are better ways to do this - can anyone help?). By the way, I believe you are using Python to write OOT blocks. Python OOT blocks can be extremely slow, especially if you are using for and if statements and/or running it on an low-power ARM board. Use Python tricks to minimise the number of for and if statments (use something like "a[0:2] = [1] * 2 "). It is just like writing a Matlab/Octave simulation. 3: "Sampling Rate" in the GNU Radio blocks, except in some hardware sources/sinks (including "UHD: USRP sink") and the "Throttle" block (which is for simulation purposes), is just a concept. It does not actually affect the processing speed of the code, and is there to solely make your calculations easier (by allowing you to think in Hertz, instead of in Radians). Actual processing speed is defined by the sampling rate of the hardware sources/sink blocks in your flow graph (the "UHD: USRP Sink" block, in this case), and all other blocks will just try to generate as many samples as they can, regardless of their configured sampling rates. So, if your codes can generate samples fast enough, and if you do not have conflicting settings (more than two instances of hardware sources/sinks , or "Throttle" blocks, with conflicting sampling rates), you should not see any underruns. I think your codes are indeed running too slow, especially since the processing power of E313 is very limited. To verify this, replace your "UHD: USRP Sink" with a "Null Sink" block and attach "Probe Rate" -> "Message Debug" to your code (I've never done this on a E313, but I think it should still work). It will show you the maximum throughput of your flowgraph. If this is indeed the case, you must try optimising your codes, or re-write them in C++ (Or even better, see if you can push things to RFNoC). 4: It depends (there are some cases where you can write fast Python blocks), but yes, C++ blocks are usually _way_ faster, and you are better off with C++ blocks, especially if you are dealing with low-power ARM chips. Poorly written C++ blocks can still run very slowly, so please read OOT blocks that other people wrote before moving on ( http://cgran
