Porting gr-osmosdr to gr-3.9 without swig.
Hello All, I was wondering if anyone had successfully built gr-osmosdr against gnuradio-3.9 now that we don't use swig? I have looked at https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide and haven't figured out how to port gr-osmosdr. I've gotten to '4. (in 3.8 OOT) Call gr_modtool bind for each block in your OOT' and don't know where to go from there. I have tried various combinations of gr_modtool bind block arguments with no success. Continuing without adding bind blocks. I run my cmake build command and get... chris [ ~/src/gnuradio/gr-osmosdr/build ]$ cmake ../ CMake Warning (dev) at /usr/share/cmake-3.18/Modules/GNUInstallDirs.cmake:225 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:24 (include) This warning is for project developers. Use -Wno-dev to suppress it. -- Build type not specified: defaulting to release. CMake Warning (dev) at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (PkgConfig) does not match the name of the calling package (GMP). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): /usr/share/cmake-3.18/Modules/FindPkgConfig.cmake:59 (find_package_handle_standard_args) /opt/gnuradio/lib/cmake/gnuradio/FindGMP.cmake:1 (include) /opt/gnuradio/lib/cmake/gnuradio/FindMPLIB.cmake:1 (find_package) /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:14 (find_dependency) CMakeLists.txt:45 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (PkgConfig) does not match the name of the calling package (MPIR). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): /usr/share/cmake-3.18/Modules/FindPkgConfig.cmake:59 (find_package_handle_standard_args) /opt/gnuradio/lib/cmake/gnuradio/FindMPIR.cmake:1 (include) /opt/gnuradio/lib/cmake/gnuradio/FindMPLIB.cmake:2 (find_package) /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:14 (find_dependency) CMakeLists.txt:45 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. -- Checking for module 'mpir >= 3.0' -- No package 'mpir' found -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR) -- Found Boost: /usr/lib/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.74.0") found components: date_time program_options filesystem system regex thread unit_test_framework CMake Warning (dev) at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (VOLK) does not match the name of the calling package (Volk). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): /usr/lib/cmake/volk/VolkConfig.cmake:32 (find_package_handle_standard_args) /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:34 (find_dependency) CMakeLists.txt:45 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. -- User set python executable /usr/bin/python3 -- Found PythonLibs: /usr/lib/libpython3.8.so (found suitable exact version "3.8.5") -- Found ALSA 1.2.3.2 -- Extracting version information from git describe... -- Found Boost: /usr/lib/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.65") found components: chrono thread system -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- Searching for GNURadio-Blocks... -- Found GNURadio-Blocks: 1 -- Searching for IQ Balance... -- Could NOT find gnuradio-iqbalance (missing: gnuradio-iqbalance_DIR) -- Found IQ Balance: 0 -- Searching for UHD Drivers... CMake Warning (dev) at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (PkgConfig) does not match the name of the calling package (UHD). This can lead to problems in calling code that expects `find_packag
Re: GNU Radio Conference 2020 – Online, Free and Starting Monday, 2020-09-14
If you want a calendar that you can embed into your thunderbird, or
Google Calendar, or any other Webcal-compatible (ICS) software:
https://sync.inpha.se
is a calendar URL. The calendar is automatically generated from the
openconf calendar, and might be ~ 10 min behind on any updates that happen.
On 13.09.20 22:04, Marcus Müller wrote:
> Dear most social SDR community to ever peruse the aethers,
>
> Monday GRCon'2020 kicks off. That seems almost unreal – usually I'd be
> stumbling around jetlagged after travelling to the US for GRCon, but due
> to epidemic reasons, this year's GRCon happens online, streamed live.
>
> So, how do you participate? Read the full participant's guide [1]!
> And: bask in our schedule [2].
>
> Because I know not everyone likes clicking links, I'd like to give a few
> key points that most of you might care about in this email already:
>
> # Streaming
>
> Every day has its own stream URL, these are [3]
>
> # Participation instead of passive consumption
>
> This is not a TV show. It lives from interaction.
> You will be encouraged to ask questions and discuss the talks while the
> thing is happening. Sadly, unlike in-person GRCon's, we don't have
> hallways with delicious food and coffee for that, so instead we have a
> chat server with several specific channels.
>
> You'll want to join the +grcon community on the gnuradio.org Matrix
> server. It's all not very hard, and you can sign up under [4];
> afterwards, navigating to the +grcon community [5] will lead you to all
> the channels that will be used for GRCon discussions – you'll mainly
> want to join #grcon-discuss for general discussion ("hey, how you've
> been?") and #grcon-talks (discussion and Q&A for talks).
>
> Because it's so crucial people are able to communicate (ha! Who would
> know better than SDR people?), we have a video tutorial [6].
>
> # Time Zones
>
> The Conference starts at 10:00am EDT, that is the time zone of e.g. New
> York. That's, to pick a few locations,
>
> * 02:00 in Wellington (next morning)
> * 01:00 in Port Vila
> * 24:00 in Sydney
> * 23:00 in Seoul and Tokio
> * 22:00 in Beijing
> * 21:00 in Bangkok
> * 19:30 in New Delhi
> * 17:00 in Helsinki, Moscow, Haifa
> * 16:00 in Paris, Brussels, Warsaw, Johannesburg, Karlsruhe, Vienna
> * 15:00 in London, Lisbon
> * 14:00 in Dakar, Reykjavík
> * 13:00 in Praia
> * 12:00 in Nuuk
> * 11:30 in St. John's
> * 11:00 in Brasília
> * 10:00 in Toronto, Port-au-Prince
> * 09:00 in Mexico City, Bogotá
> * 08:00 in Guatemala City
> * 04:00 in Honululu
>
> I'm kind of excited: The GRCon team did, in my opinion, an incredible
> job at coordinating a fascinating programme, and making it possible to
> access all that. You can thank them by showing up!
>
> See you then,
> Marcus
>
> [1]
> https://docs.google.com/document/d/e/2PACX-1vQtKfY1-ZT7bhYlkbQlOIKlv026qGr9ZbZlpoWx4Sjou8dOOZ4K2GvAMhCXVu0vIPYvq2z5KsvGIj36/pub
> [2]
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRzQRVelQmDWWUJJRgzFe0OxdVntA5X191hM3zhGgjKIpgMB9KOllXRmFwbryoGJpYIKiNNF4rQv_hw/pubhtml
> [3] Monday September 14th - https://youtu.be/o0Q99JYW8Mg
> Tuesday September 15th - https://youtu.be/sFqIkXxhc14
> Wednesday September 16th - https://youtu.be/YOT8U5K4wbk
> Thursday September 17th - https://youtu.be/RTio6xMka2o
> [4] https://chat.gnuradio.org
> [5] https://chat.gnuradio.org/#/group/+grcon:gnuradio.org
> [6] https://www.youtube.com/watch?v=9ZUWmGQrbBQ
>
GNU Radio Conference 2020 – Online, Free and Starting Monday, 2020-09-14
Dear most social SDR community to ever peruse the aethers,
Monday GRCon'2020 kicks off. That seems almost unreal – usually I'd be
stumbling around jetlagged after travelling to the US for GRCon, but due
to epidemic reasons, this year's GRCon happens online, streamed live.
So, how do you participate? Read the full participant's guide [1]!
And: bask in our schedule [2].
Because I know not everyone likes clicking links, I'd like to give a few
key points that most of you might care about in this email already:
# Streaming
Every day has its own stream URL, these are [3]
# Participation instead of passive consumption
This is not a TV show. It lives from interaction.
You will be encouraged to ask questions and discuss the talks while the
thing is happening. Sadly, unlike in-person GRCon's, we don't have
hallways with delicious food and coffee for that, so instead we have a
chat server with several specific channels.
You'll want to join the +grcon community on the gnuradio.org Matrix
server. It's all not very hard, and you can sign up under [4];
afterwards, navigating to the +grcon community [5] will lead you to all
the channels that will be used for GRCon discussions – you'll mainly
want to join #grcon-discuss for general discussion ("hey, how you've
been?") and #grcon-talks (discussion and Q&A for talks).
Because it's so crucial people are able to communicate (ha! Who would
know better than SDR people?), we have a video tutorial [6].
# Time Zones
The Conference starts at 10:00am EDT, that is the time zone of e.g. New
York. That's, to pick a few locations,
* 02:00 in Wellington (next morning)
* 01:00 in Port Vila
* 24:00 in Sydney
* 23:00 in Seoul and Tokio
* 22:00 in Beijing
* 21:00 in Bangkok
* 19:30 in New Delhi
* 17:00 in Helsinki, Moscow, Haifa
* 16:00 in Paris, Brussels, Warsaw, Johannesburg, Karlsruhe, Vienna
* 15:00 in London, Lisbon
* 14:00 in Dakar, Reykjavík
* 13:00 in Praia
* 12:00 in Nuuk
* 11:30 in St. John's
* 11:00 in Brasília
* 10:00 in Toronto, Port-au-Prince
* 09:00 in Mexico City, Bogotá
* 08:00 in Guatemala City
* 04:00 in Honululu
I'm kind of excited: The GRCon team did, in my opinion, an incredible
job at coordinating a fascinating programme, and making it possible to
access all that. You can thank them by showing up!
See you then,
Marcus
[1]
https://docs.google.com/document/d/e/2PACX-1vQtKfY1-ZT7bhYlkbQlOIKlv026qGr9ZbZlpoWx4Sjou8dOOZ4K2GvAMhCXVu0vIPYvq2z5KsvGIj36/pub
[2]
https://docs.google.com/spreadsheets/d/e/2PACX-1vRzQRVelQmDWWUJJRgzFe0OxdVntA5X191hM3zhGgjKIpgMB9KOllXRmFwbryoGJpYIKiNNF4rQv_hw/pubhtml
[3] Monday September 14th - https://youtu.be/o0Q99JYW8Mg
Tuesday September 15th - https://youtu.be/sFqIkXxhc14
Wednesday September 16th - https://youtu.be/YOT8U5K4wbk
Thursday September 17th - https://youtu.be/RTio6xMka2o
[4] https://chat.gnuradio.org
[5] https://chat.gnuradio.org/#/group/+grcon:gnuradio.org
[6] https://www.youtube.com/watch?v=9ZUWmGQrbBQ
Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass
Hi George,
noutput_items is a number given to you by GNURadio. I would not
overwrite this variable, otherwise you no longer know how many items you
can write into the output buffer. Create a new variable nitems_written
or similar to track how many items you have written.
Also have a look at what each variable is tracking exactly. cnt seems to
be the number of input bytes you have checked for the preamble. But you
also use it to compute the position in the out array, which does not
make sense to me. cnt would increase with more spurious bytes in front
of the preamble, but the output position should not depend on the number
of spurious bytes. From the code you showed me cnt also seems to persist
between multiple calls to general_work, but the out array is always
clean when general_work is called again (meaning that on every
general_work call you should always start writing to element 0).
You loop over your entire input array and if the preamble was found you
copy the entire preamble and then you copy every following byte one by
one. That means you copy the entire preamble again (without the first
byte) and if your input buffer is longer than your message size you also
copy more bytes to the output than your message is long which could
result in missing the next preamble. Also you are potentially writing
more items into the out array than GNURadio has space for, which is why
I recommend you not to overwrite noutput_items and while you are still
learning check that your computed indices for out and in are within the
allowed bounds before every single write and read (i.e. by using
assertions).
What messages are you using in your unittest and what kind of spurious
bytes? Is is all zeros, or all ones? I would recommend you use different
bytes, e.g. an increasing counter for your message and a decreasing
counter starting from 255 for your spurious bytes so you can quickly
spot if your messages are cropped, or off in some other way. Because the
way you describe your results it seems like one message is copied twice.
I could not find any obvious bug in your code that would output a
message exactly twice, so I suppose it copies some data that look like a
message on the first glance.
Yours
Martin
On 11.09.20 03:06, George Edwards wrote:
Hi Martin,
Thanks for your detailed answer. I really appreciate the great effort
you put into explaining how things work. I am still on the learning curve.
I used your suggestions to the best of my understanding and it worked
beautifully for the one sync pattern test vector in the QA test.
Then, I took your suggestion for repeated sync patterns using an init
flag which I reset to 0 to restart the process. For the QA test, I
repeated the original input data twice (now I have 2 sync patterns), so
the expected QA output should be the original output repeated twice. I
modified the C code by adding an if statement at the end to check if
noutput_items == Buf_size+message_size (buf_size is the length of the
pattern, which I call preamble) and if it is, I reset the init flag to
zero as well as other params used in the initialization section of the
code. The QA test failed by producing an output with 3 repeated copies
of the original output rather than the expected 2 copies. I do not
expect you to send too much time looking at my code below, however, I
would appreciate it very much, if you would glance at it to see if you
can spot what I am doing wrong. The test to un-initialize (setting init
to 0) was done towards the end of the code block after the consume method.
int kk = 0;
for (int i = 0; i < ninput_items[0]; i++)
{
if(!init){__
cnt += 1; // cnt number of passing bytes
kk = initialize(in[i]);
if (kk == 0){
noutput_items = cnt;
}else{
memcpy((void*)out, (const void*)preamble, buf_size);
noutput_items = cnt;
}
} else {
out[i-cnt+buf_size] = in[i];
noutput_items = buf_size + message_size;
}
}
consume_each (noutput_items);
if (noutput_items == buf_size + message_size){
init = 0; // re-initialize all
cnt = 0;
kk = 0;
}
return noutput_items;
}
Thanks very much for the help.
Regards,
George
On Thu, Sep 10, 2020 at 12:06 AM Martin Luelf > wrote:
Dear George,
this also caused me a lot of headache when I started with GNURadio, so
here is what I learned about it.
Let's start with the forecast method. This tells GNURadio how many
input
samples you need on each input stream to generate the requested number
of output items. Usually GNURadio will run your forecast function a
couple of times wi
