General issue: Pybombs recipe 3.7 vs. 3.8 ??
I am starting the process to port an OOT over the 3.8 / Python3. There is an existing pybombs recipe for the 3.7 version, this recipe references my master branch on GitHub. Question: how should my git repository be structured so that the 3.7 version or the 3.8 version is pulled correctly when someone installs the OOT? If the existing master branch is switched to branch 3.7 then the existing recipe will become broken. If a new branch 3.8 is created, how does the pybombs pull/build know to checkout that instead of master? I went through something similar to this problem yesterday when installing gnuradio using pybombs - the recipe apparently pulled the wrong branch from UHD. Fortunately Vasil helped me do a manual workaround for this. -- Tom, N5EG
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
Wow, Sylvain, this is awesome! Especially: thank you for handling the "obscure" special 3.7+qt5 case. Cheers, Marcus On Sun, 2019-12-08 at 21:31 +0100, Sylvain Munaut wrote: > Hi, > > I have just pushed updates to various osmocom repositories, updating > them to run on gnuradio 3.8. > > Here's the status per project : > > * gr-iqbal : >- Old gnuradio 3.7 version been forked into a 'gr3.7' branch and > will remain there. It won't be maintained and will most likely never > receive any further updates. >- 'master' now contains the gnuradio 3.8 compatible code and the > latest version has also been tagged. > > * gr-fopshor : >- The gnuradio 3.7 version actually got updated a bit with some new > functionality, then moved over to also a 'gr3.7'. Again, I won't > backport future features to it so I don't really expect any further > updates. >- Because I know some distribution still maintain a gnuradio 3.7 > package but removed Qt4 (and so ported gnuradio to Qt5), I also > created a 'gr3.7-qt5' branch that's designed to work with gnuradio 3.7 > but using Qt5 instead of Qt4. >- Finally, 'master' contains the gnuradio 3.8 compatible code. ATM > there is no functional (as in 'fosphor features') differences with the > two others, it's just Qt5 support and Makefile changes. >- A couple of the interesting new features that have been added : > . Fixes the long standing bug of NVidia CL/GL sharing not working > (thanks Aaron Giles for figuring out root cause) > . Memory leak fix (thanks Emil Berg for reporting) > . Improved CL device compatibility check before trying to use > them (thanks to Ethan Trewhitt) > . Allow explicit selection of the CL device via FOSPHOR_CL_DEV > env var if you have several CL platform/devices. > > * gr-osmosdr : > - 'master' is still 3.7 version, same code as before but has been > tagged and a 'gr3.7' branch has been created in anticipation that > master will become 3.8 > - An experimental 'gr3.8' branch has been added that contains an > upgrade to Gnuradio 3.8 (based off the work from Mickey Vänskä and > Maitland Bottoms). > . I tested it with UHD / Blade RF / Hack RF which are all the > devices I have available. > . It also adds support for the Airspy HF courtesy of Alexandru Csete > . Still feel free to use it as base for packaging and report any > additional patch you have to apply for the build. > . Once I have enough success report, this will land in master. > . Currently the utilities in apps _have_not_ been ported to 3.8 > (especially GUI changed to Qt5) ... if anyone wants to do that and > send me a diff, that would be _very_ welcome and I'll include that in > this branch. > > > Cheers, > > Sylvain Munaut > > PS: bcc'd package maintainer I thought of. > smime.p7s Description: S/MIME cryptographic signature
Best way (architecture) to perform frequency hopping in GRC
Hi, I am wondering what is the best way to perform frequency hopping in gnuradio on an *architectural* level. I have a frequency vector [ f1 , f2 , f3 ]. GRC should tune the TX to f1, f2, f3, f1, f2, ... and the RX to 2*f1, 2*f2, 2*f3, 2*f1, 2*f2, ... Denote the time interval for each frequency as Tf and a complete sweep as Tsweep=3*Tf with Tf = Tsettle + Tvalid. During each Tvalid, the TX sends modulated data and waits for a modulated response. After processing (filtering, clock recovery, decimation etc) the response consists of N (e.g. N=100) bits. After each Tsweep, the three responses acquired for each frequency (i.e. 3x100 bits) should be passed to the next block at a rate 1/Tsweep. What is the best way to implement this in GRC reusing as many standard blocks from GRC as possible? - Is it a good idea to use "Message Strobe" to generate a message to change frequency for the USRP Source/Sink blocks at a rate 1/Tf? - Is it a better idea to change a python variable "center_freq"? - What is the best way to update such a python variable? - Is it a good idea to create Signal Source Saw Tooth and use "Probe Signal"? - Is it a good idea to use the "lo_locked" sensor or just make "Tsettle" big enough? How to use "lo_locked" from within Gnuradio? - What is the best way to combine the results for each frequency into one item that is passed at a rate 1/Tsweep? - Is it a good idea to use "Stream to Vector"? - How do I ensure that for each frequency, exactly the same number of output samples are generated? Thanks, Luke PS: This sounds like something fairly trivial but 99% GRC examples are using a straight-forward data stream flow. I worked through the tutorials but they really only touch on this point briefly. Now I need to dynamically change the behavior of the signal flow over time while ensuring that everything stays time-aligned properly and to combine data from very different points in time into a single data point.
OOT blocks in 3.8 not working
Hello,
I am trying move a project I have from gnuradio 3.7 to 3.8 and I am having
some difficulties.
I have went through the gr_modtool tutorial in 3.8, and was able to get the
square_fft block to build and run inside of gr-howto, but making the same
block in my module (gr-nuclear) doesn't work.
Some of the errors I suspected were from dependencies, and I think that I
have added them in correctly. Those dependencies are UHD and libomnithread:
To include UHD I:
* Added the following to the CMakeLists.txt based on gr-foo: (in the
gr-nuclear's directory, not in /lib/)
I added this to the Compiler Specific setup section:
find_package(UHD)
if(NOT UHD_FOUND)
message(STATUS "UHD library not found, no support for timed
TX")
set(UHD_INCLUDE_DIRS "")
set(UHD_LIBRARY_DIRS "")
set(UHD_LIBRARIES "")
else()
message(STATUS "UHD library found.")
set(UHD_INCLUDE_DIRS "")
set(UHD_LIBRARY_DIRS "")
set(UHD_LIBRARIES "")
endif()
and I added this in the project setup section:
list(INSERT CMAKE_MODULE_PATH 0 "/path/to/uhd/module")
* Added the following to the CMakeList.txt in the /lib/ directory
Added <${UHD_INCLUDE_DIRS}> to include_directories()
Added <$UHD_LIBRARY_DIRS}> to link_directories()
To include libomnithread4 I;
* I had to purge all of libomnithread, and install the latest omniorb
package. After that I added the following to the target_link_libraries()
list in the CMakeLists.txt file in /lib/
/usr/lib/x86_64-linux-gnu/libomnithread.so.4
* I was getting an error that omnithread.h was not in the include
folder while building, so I moved omnithread.h to the include/nuclear/
directory, and after that I was able to build the project without errors.
But once I try to launch my project I get "AttributeError: module 'nuclear'
has no attribute 'radio_init', which is one of the blocks of my OOT module.
I'm not sure if this is related, but while launching I also get the warning:
"Warning: restarting the docstring loader (crashed while loading
'uhd_amsg_source')"
When I go into the build/swig directory and run python3.6, I tried to import
my module the same way that __init__.py uses it and I get this error
How I imported:
from .nuclear_swig import *
Error I get:
ModuleNotFoundError: No module named '__main__.nuclear_swig'; '__main__' is
not a package
I have tried removing the '.' Which was recommended when I looked into this
problem online, but that did not solve it
Before include the two modules, trying to import .nuclear_swig was
segfaulting, so it seems like I have made at least some progress.
Does anyone have some ideas of what I could be missing/doing wrong?
Thank you
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: gr-ieee802-11 with USRP N210 and B200mini problems
Hello Hamzeh, Sorry, but I think we need more details about your configurations (maybe flowgraphs, pictures of the hardware, captured data, etc) in order to answer your questions properly. But here are a few generic answers to the question: 1. It depends. There is no single answer. 2. You can either implement a software-level automatic gain control (harder), or do this experimentally. Try to choose the gain level that maximises the SNR of the received signal. Plotting out the periodogram of the signals is helpful (USRP Source -> QT Frequency Sink). Some USRP boards and daughterboards have hardware AGCs on them. This includes USRP B series units, if I recall correctly. You can try enabling that. This not not necessarily optimal, however. 3. Yes, different SDR transceivers have different RF frontends and therefore different gain stages. It is less application-dependent, but some applications work well on non-linear conditions while others dont, so applications matter, too. You should figure this out experimentally (easier) or by actually going thorugh hardware schematics and software source codes (harder). 4. I don't know, there are insufficient information to tackle your problem. Maybe your flowgraph has issues. Maybe the spectrum is too crowded. Maybe you used wrong antennas (RP-SMA) or antenna ports. There are too many possibilities. One thing that you should try is plotting the received data, before actually putting them into the processing chain. You can try hooking up a QT Frequency Sink to the USRP source on GNU Radio and see if the periodogram makes sense (looks OFDM-ish). Regards, Kyeong Su Shin 보낸 사람: hamzeh elsayed 대신 Discuss-gnuradio 보낸 날짜: 2019년 12월 10일 화요일 오후 6:33 받는 사람: discuss-gnuradio@gnu.org 제목: gr-ieee802-11 with USRP N210 and B200mini problems Dear all, I installed the gr-ieee802-11 project and run the wifi_loopback.grc file and the output is correct. Then I edited the file to transmit and receive from socket using “socket PDU” block, also the output is correct. After that, I tried to transmit and receive from USRP SDRs, the following are the tested I done: 1- I transmit and receive from the same SDR “B200mini” with the same configuration found in the wifi_transceiver.grc file. a. If the rx_gain and tx_gain are approximately 0.27 (normalized) and encoding BPSK 1/2 , then the sent data are received for (95%) and the constellation sink is approximately good. b. If the rx_gain and tx_gain are less than or greater than 0.27 and encoding BPSK 1/2 , then any data id not received and the constellation sink is very bad. c. If the encoding is anyone except BPSK ½ for example 16 QAM ½ etc.. any data is not received for any value of gain. 2- I transmit and receive from the same SDR “N210” with the same configuration found in the wifi_transceiver.grc file. Any data is not received for any gain and encoding configurations. 3- I transmit from USRP N210 and received from B200mini also any data is not received for any gain and encoding configurations. 4- I transmit from USRP B200mini and received N210 from B200mini also any data is not received for any gain and encoding configurations. Tests were done by using the following: OS: Ubuntu 16.04 LTS Gnuradio: 3.7.11 First SDR: USRP N210 with CBX daughter board Second SDR: B200mini Frequency: 2.415Ghz Bandwidth: default (0) Therefore, 1- what are the best settings I have to select in order to transmit and receive data correctly for all cases? 2- how to select the best gain for any SDR? 3- Is there any relation between the SDR type and gain and the application? 4- In general, where is the problem or the mistake I am doing? in advance, thanks for your time and help. Best Regards, Hamzeh Elsayed
Installing version 3.8 via ppa
Hello everybody, I have a question. I've installed GR on Ubuntu 18.04 via ppa:gnuradio/gnuradio-master. To my surprise I've got 3.9 version instead 3.8. Is it possible to install 3.8 vvia PPA?Thanks,Michal
