Re: gr-adsb
I've used this package recently and it would not be trivial to convert from rx to tx. With that said, ADS-B is a pretty simple signal, I don't think it would be a monumental effort to do it. You would need to write the reverse of the decoder block that would create ADS-B messages from your input data. Additionally, you might need to write a block that converts that message to the Pulse Position Modulation used by ADS-B (I'm not sure if there are any standard blocks that can do this for you) and appends the preamble sequence. I'm not sure what your application is, but I would make sure that whatever you are planning to do it legal where you are located. I'm not a lawyer, but I would imagine that you could get in trouble while building up your transmitter if other aircraft or flight controllers were able to pick up on your signal. On Mon, Jul 3, 2023 at 9:44 AM Mike Sousa wrote: > The gr-adsb package has a receiver example. Is there an example of a adsb > transmitter? If not, how difficult would it be to convert the rx into tx? > Would it be similar to replacing the USRP Source with a Signal Source and > replacing the ZMQ PUB message Sink with a USRO Sink (this sounds too > simplistic, but one can hope)? > > https://github.com/mhostetter/gr-adsb > > >
Re: How to force the decimation to schedule at least 16 output samples
The set_min_noutput_items function exists, but sadly it does nothing (literally nothing). I've traced the value through the scheduler code to verify this. The only way to mostly do what you want is through set_output_multiple (ie self.set_output_multiple(16). This will ensure that you always receive at least 16 samples and that the number of samples is a multiple of 16. It's not the best solution but it gets the job done. John On Wed, Mar 15, 2023 at 12:37 PM Jeff Long wrote: > The function is there. Perhaps you're not calling it correctly, but I > can't tell. > > On Wed, Mar 15, 2023 at 11:11 AM George Edwards > wrote: > >> Hi Jeff, >> Thanks for the suggestion. >> >> I tried set_min_noutput_items(16) first in the __init__() method, then >> the work() of Python file and each time I get the response Name Error: name >> 'set_min_noutput_items' is not defined. >> >> Any more suggestions! 樂 >> >> George >> >> On Tue, Mar 14, 2023, 7:03 PM Jeff Long wrote: >> >>> Try: set_min_noutput_items(16) >>> >>> On Tue, Mar 14, 2023 at 5:39 PM George Edwards >>> wrote: >>> Dear GNURadio Community, I have a decimator OOT block doing my signal processing. It works well, but after 30 or epochs, it schedule an output of one sample which breaks my signal processing algorithm. Then the output gets scheduled to a good number and the algorithm starts working good again before going off script to scheduling an output of 1 sample again. Every time it does this, it breaks my signal processing algorithm. Is there a way to force the decimator to schedule a minimum number outputs, like say 16 samples (which would work for my algorithm because the correspondingnumber of input samples would be just fine)? Will appreciate any suggestion towards a solution. Thank you! George >>>
Re: Installation of Gnuradio on Windows 11
Ryan has done a great job maintaining Windows support in conda. I'll throw out that if you prefer, you can use the Windows subsystem for Linux to run Linux based docker containers. On Mon, Feb 6, 2023, 2:03 PM Ryan Volz wrote: > Hi George, > > The conda installation method and radioconda should work fine on Windows > 11: > > https://wiki.gnuradio.org/index.php/CondaInstall > https://github.com/ryanvolz/radioconda > > This doesn't come in a debug-build version, but it is still possible > develop OOT blocks on Windows in the same way that it is done on Linux > by running `gr_modtool`, etc. Instructions for building OOTs within a > conda environment can be found here: > > > https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio > > Cheers, > Ryan > > On 2/6/23 11:07 AM, George Edwards wrote: > > Dear GNURadio Community, > > > > I plan to buy a PC with Windows 11. I looked online to see if folks were > > installing Gnuradio on Windows 11 and found nothing definitive. Please > > advise me if Gnuradio works on Windows 11. > > > > I also noticed online that there was an installation package for Windows > > Debugging, does this mean one can develop their own OOT custom block in > > the Windows environment similar to the Linux environment? > > > > Thank you very much! > > > > Regards > > George > >
Re: Realtime Kernel, UHD 4.0, GNURadio
I have found that using chrt can make a big difference with USRP performance.When using rx hardware I will run my flowgraph with chrt -f 99 python3 my_flowgraph.py. Even when I run the ettus provided benchmarks, I have found that I will eventually drop data without realtime priority. If you are using GRC, there is an RT setting that you can apply. Either way, you have to have permissions set up properly to be able to elevate a process to have real time priority. I don't know about GNURadio compatibility with realtime linux, but I have never needed it. I've always been able to keep up using chrt and occasionally taskset. On Thu, May 5, 2022 at 4:13 PM Dobler, Anton wrote: > Dear community, > > > I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as > a SDR. > > > When I execute the benchmark_rate example with DPDK enabled, I do not see > any under- or overruns even with the sampling rate set to 125 MHz, however > using GNURadio - DPDK enabled here as well - I do not achieve that high > sampling rate. The limit seems to be around 30MHz though. > > > Do you know, apart from using taskset and isolcpus any other possibility > to achieve higher sampling rates? > > > Would it be an option to use the realtime kernel available for Ubuntu > 20.04 and is this kernel compatible with GNURadio? > > > Any help also with regards to the usage of taskset and isolcpus would be > highly appreciated! > > > Thank you in advance! > > > BR, > > > Anton >
Re: VOLK C++ core
If nothing else I think there is a lot of value in adding c++ wrappers to volk. I don't have a strong opinion on an underlying base of c or c++, but would like for it to be easier to use in c++. A common approach with other c libraries like zeromq is to make a header only c++ wrapper. This would take a lot less work to implement, but only provides some of the advantages you mention. What version of c++ would you target? I would recommend c++20 so that you can define a concept for a vector like object to use as arguments to these functions (or at least a concept based wrapper) On Tue, Dec 21, 2021, 5:21 AM Johannes Demel wrote: > Hi everyone, > > today I'd like to propose an idea for the future of VOLK. Currently, > VOLK is a C library with a C++ interface and tooling that is written in > C++. > > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a > C interface if the need arises. > > This email serves as a request for comments. So go ahead. > > Benefits: > - sane std::complex interface. > - same compilation mode on all platforms. > - Better dynamic kernel load management. > - Option to use std::simd in the future > - Less manual memory management (think vector, ...). > > Drawbacks: > - It is a major effort. > - VOLK won't be a C project anymore. > > Why do I propose this shift? > VOLK segfaults on PowerPC architectures. This issue requires a breaking > API change to be fixable. I tried to update the API to fix this isse. > https://github.com/gnuradio/volk/pull/488 > It works with GCC and Clang but fails on MSVC. > One might argue that PowerPC is an obscure architecture at this point > but new architectures might cause the same issue in the future. Also, > VOLK tries to be portable and that kind of issue is a serious roadblock. > > How did we get into this mess? > The current API is a workaround to make things work for a specific > compiler: MSVC. MSVC does not support C `complex.h` at all. The trick to > make things work with MSVC is: compile VOLK in C++ mode and pretend it > is a C++ library anyways. > In turn `volk_complex.h` defines complex data types differently > depending if VOLK is included in C or C++. Finally, we just hope that > the target platform provides the same ABI for C complex and C++ complex. > C complex and C++ complex are not compatible. However, passing pointers > around is. > Thus, the proposed change does not affect Windows/MSVC users because > they were excluded from our C API anyways. The bullet point: "same > compilation mode on all platforms" refers to this issue. > > Proposed timeline: > Together with our re-licensing effort, we aim for a VOLK 3.0 release. > VOLK 3.0 is a good target for breaking API changes. > > Effects: > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, > I'd like to keep an interface that hopefully doesn't require any code > changes for VOLK 2.x users. A re-built of your application should be > sufficient. However, we'd be able to adopt a C++-ic API as well. e.g. > use vectors, spans etc. > > The current implementation to detect and load the preferred > implementation at runtime is hard to understand and easy to break. C++ > should offer more accessible tools to make this part easier. > > What about all the current kernels? > We'd start with a new API and hide the old kernel code behind that > interface. We come up with a new implementation structure and how to > load it. Thus, we can progressively convert to "new-style" implementations. > > Another bonus: std::simd > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib > would allow us to eventually use std::simd in VOLK and thus make Comms > DSP algorithms more optimized on more platforms. > > Cheers > Johannes > >
PMT thoughts
I appreciate the effort that you guys have put into cleaning up gnuradio
and making it easier to work with over the past few years (python2 -
python3, swig to pybind11). I see that you are going to improve the
logging as well which is great.
I've recently been doing some message based processing, and been using
PMTs. I think that PMTs could use an overhaul too.
Here are some of my concerns:
The interface is inconsistent. Here are a few examples:
is_integer, but from/to_long
is_dict, is_vector, not no is_list
make_dict, make_vector, but list1, list2, etc
Type safety doesn't really work in several cases:
# apt install of gr 3.9 on ubuntu 20.04
a = pmt.make_dict()
a = pmt.dict_add(a, pmt.intern("a"), pmt.intern("a"))
pmt.is_dict(a) # True
a = pmt.list_add(a, pmt.intern("b")) # I believe that this changes the
dictionary to a list
pmt.is_dict(b) # False
I could come up with more examples, but they illustrate roughly the same
point. I should note that something changed in GR3.9. It was even worse
in 3.8. For example, on a list, pmt.is_dict() returns True. I can call
some of the dict functions which return unexpected results, while others
raise an error.
The interface doesn't feel like modern C++. The pmt object doesn't really
have any useful functions associated with it. You have to use the
functions in pmt namespace to operate on any pmt. I believe that PMTs are
using boost::any under the hood. I can get why some of the choices were
made, but I think that there may be some alternatives available that could
lead to an easier interface.
I've been playing around with std::variant (in c++17, boost::variant prior
to that). I have some ideas for how we could use it to wrap the scalar
types as well as the vector and dynamic types. I would be happy to explore
the idea if there is interest. We could also use variadic templates to
avoid things like list1, ..., list6.
Using std::variant, I would envision an interface like:
pmt my_dict();
my_dict["abc"] = 4.0 // Automatically convert the string and the number to
the proper type.
std::get(my_dict["abc"]))
pmt_list my_list();
my_list.append(pmt(my_dict));
for (auto& element : my_list) {
// Do something
}
std::cout << my_list.type() << " " << my_list << std::endl;
We should be able to deprecate, but maintain the current functions for
dealing with PMTs. I believe that these changes could be made without
breaking existing code.
To be clear, I haven't implemented any of this. My goal right now is just
to see if there is interest in doing something like this. If there is, I
am happy to look into it and try to create a proof of concept. I'm also
open to suggestions and feedback.
Thanks,
John
