Re: [Discuss-gnuradio] GNURadio master and UHD RFNOC Version Issue
Just to close this issue. We have several custom blocks in RFNOC. After upgrading Vivado we were able to build the image using new source code and had no issues. The problem was that our images were built with incorrect version. In source code, where do you find the version number of the UHD software? Thanks, John On Fri, May 25, 2018 at 7:41 AM, Derek Kozel wrote: > Hello John, > > I'm looking at this right now and can confirm that the head of rfnoc-devel > is compatible with the latest GNU Radio. Can you please try rerunning cmake > on UHD with -DRFNOC_ENABLE=true? > > The error I saw when switching branches was that the header > was not installed. That is a core RFNoC header and isn't > installed if the RFNOC_ENABLE is false. The rfnoc-devel branch should have > that enabled automatically, but I suspect that you have RFNOC_ENABLE set to > false in CMakeCache.txt from an earlier master branch build. > > Regards, > Derek > > On Fri, May 25, 2018 at 2:20 PM, John Medrano > wrote: > >> Hello, >> >> I apologize for my terminology, it is causing some confusion. >> >> If you download the source from https://github.com/EttusResearch/uhd. >> You can compile this version and it should work fine with latest version of >> GNU Radio. But this version is missing additional modules that are >> available in branch rfnoc-devel. I inspected /host/lib/rfnoc for both the >> master and rfnoc-devel branches; there are several modules from rfnoc-devel >> branch such as sig_gen that are not available in master branch. That is >> what I am referring to as RFNOC UHD. I would like to continue using >> rfnoc-devel branch, and hence the issue that I am having. Since the version >> we were instructed that works with that branch, no longer compiles in >> latest version of Fedora. That version being v3.7.10.2. >> >> When we build source, we typically install all dependencies and it the >> proceeds to build with no issue. But in this latest version of Fedora, we >> received compilation errors while trying to build v3.7.10.2. Since latest >> version of GNU Radio built with no issue, I suspected that changes had been >> made to correct for newer version. >> >> Where in the source code, do they check the version of UHD for >> compatibility? This will help me to look back at and see which GNU Radio >> versions are compatible with the rfnoc-devel branch. >> >> Thank you again. >> >> On Fri, May 25, 2018 at 6:46 AM, Müller, Marcus (CEL) >> wrote: >> >>> Hi John, >>> On Fri, 2018-05-25 at 06:39 -0600, John Medrano wrote: >>> > Thank you for the response. >>> > >>> > The issue that we have is that the latest UHD RFNOC version is not >>> compatible with latest version of GNU Radio. >>> >>> That's simply not true. UHD, to GNU Radio, is just a library. >>> >>> > >>> > So I must either compile older version in with newer compiler, >>> >>> the compiler version has little to nothing to do with this, luckily :) >>> >>> > or downgrade to a version that is compatible with UHD RFNOC. >>> >>> You need to use a UHD version that supports what you need (RFNoC); "UHD >>> RFNOC" is not a thing. RFNoC is an architectural aspect of the FPGA >>> designs running on some USRPs. So, you need an _UHD_ version that comes >>> with compatibility for these. >>> >>> > Upgrading UHD to latest version will not allow us to use RFNOC. I may >>> be wrong, but that is my understanding. >>> >>> You'll probably need to manually build UHD, anyway. >>> After that, you need to build GNU Radio against that UHD version. >>> >>> Best regards, >>> Marcus >> >> >> >> ___ >> 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] GNURadio Help
Hello, I see you are using an E310, now this seems to make a bit more sense as to what you are trying to do. Although you can use RFNOC to increase the processor ability to do FFT function, it is actually not needed for initial testing. In GNU radio, there are many ways to enhance your design, but there is a simple approach that will work. RADIO->STREAM TO VECTOR->FFT->CUSTOM BLOCK The FFT block will pass data to your custom blocks of X data points. Where X is your FFT Size. Your custom block would then store 1 block of X data points, and then set a flag to indicate that it has data. So your custom block should have functions to check flag and retrieve data. The rest of the work you can do in Python. while 1: tb.start() time.sleep(1.0) tb.stop() tb.wait() tb.store_data() tb.change_freq() tb.store_data() will check your custom block to see if data there, and if yes will store it to file in whatever format you want. tb.change_freq() will basically change the frequency of radio component to new frequency setting. You would need to add code in Python that transmits to host when all data blocks have been collected. One big problem with E310 though, I doubt if you are going to be able to process with a sample rate of 30 MHz. You may have to go down to as low as 5 MHz. The only approach that would increase band width would to move your custom block and FFT back into FPGA with RFNOC. But this is very complex endeavor. On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk wrote: > I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a > frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to > the buffer. And so up to 6GHz. Then when the buffer is full, I transfer > the data to the host machine (I use the USRP E310 board) to display the > data. > In fact, it should be such a broadband spectrum analyzer not in real time. > > 2018-06-13 17:57 GMT+03:00 John Medrano : > >> Hello. >> >> If I understand what you are saying correctly, you would like to process >> wide band data. And you mention 70 MHz to 6 GHz. >> >> Even with RFNOC there is a limitation on the amount of data you can >> process simultaneously, and that is about 200 MHz. There is no way possible >> to simultaneously process a 6GHz band with one host and radio. You would >> need an array of radios. >> >> Please provide more details on design requirements, it hard to understand >> what you are trying to accomplish. >> >> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk >> wrote: >> >>> In the future, I would also like to use the RFNoC >>> >>> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk : >>> >>>> I need to rebuild the frequency, do fft and then transfer the whole >>>> array from 70 to 6GHz to the host machine. I do not quite imagine how >>>> you can do this with standard blocks in gnuradio. >>>> >>>> >>>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) : >>>> >>>>> Dear Ivan, >>>>> >>>>> you don't pass data to a block yourself. >>>>> >>>>> You write a block that does a clearly-limited signal processing job, >>>>> and use GNU Radio to connect that to other blocks: >>>>> >>>>> https://tutorials.gnuradio.org >>>>> >>>>> In your case, instantiating a USRP source in your block makes >>>>> absolutely no sense, for example. You'd build a flow graph containing >>>>> the USRP source, and your custom-written block, and you'd connect these >>>>> two. >>>>> >>>>> It's sadly not really clear what you want to achieve, so I'm afraid I'm >>>>> not able to help you here. >>>>> >>>>> Generally, GNU Radio pretty much takes the idea of "draw a block >>>>> diagram of what you want to achieve with your signal processing", and >>>>> directly translates it to "using existing blocks and writing new ones, >>>>> and letting GNU Radio take care of how the data gets around". >>>>> >>>>> Also, wideband signal processing and implementing a sync_block in >>>>> Python... do not work well together. >>>>> >>>>> So, I think you might really be a bit confused about the architecture >>>>> of GNU Radio – I really hope the tutorials explain that better than I >>>>> could. >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchu
Re: [Discuss-gnuradio] GNURadio Help
This is much more doable. May I ask why you want to buffer all the data in the radio? On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk wrote: > I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a > frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to > the buffer. And so up to 6GHz. Then when the buffer is full, I transfer > the data to the host machine (I use the USRP E310 board) to display the > data. > In fact, it should be such a broadband spectrum analyzer not in real time. > > 2018-06-13 17:57 GMT+03:00 John Medrano : > >> Hello. >> >> If I understand what you are saying correctly, you would like to process >> wide band data. And you mention 70 MHz to 6 GHz. >> >> Even with RFNOC there is a limitation on the amount of data you can >> process simultaneously, and that is about 200 MHz. There is no way possible >> to simultaneously process a 6GHz band with one host and radio. You would >> need an array of radios. >> >> Please provide more details on design requirements, it hard to understand >> what you are trying to accomplish. >> >> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk >> wrote: >> >>> In the future, I would also like to use the RFNoC >>> >>> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk : >>> >>>> I need to rebuild the frequency, do fft and then transfer the whole >>>> array from 70 to 6GHz to the host machine. I do not quite imagine how >>>> you can do this with standard blocks in gnuradio. >>>> >>>> >>>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) : >>>> >>>>> Dear Ivan, >>>>> >>>>> you don't pass data to a block yourself. >>>>> >>>>> You write a block that does a clearly-limited signal processing job, >>>>> and use GNU Radio to connect that to other blocks: >>>>> >>>>> https://tutorials.gnuradio.org >>>>> >>>>> In your case, instantiating a USRP source in your block makes >>>>> absolutely no sense, for example. You'd build a flow graph containing >>>>> the USRP source, and your custom-written block, and you'd connect these >>>>> two. >>>>> >>>>> It's sadly not really clear what you want to achieve, so I'm afraid I'm >>>>> not able to help you here. >>>>> >>>>> Generally, GNU Radio pretty much takes the idea of "draw a block >>>>> diagram of what you want to achieve with your signal processing", and >>>>> directly translates it to "using existing blocks and writing new ones, >>>>> and letting GNU Radio take care of how the data gets around". >>>>> >>>>> Also, wideband signal processing and implementing a sync_block in >>>>> Python... do not work well together. >>>>> >>>>> So, I think you might really be a bit confused about the architecture >>>>> of GNU Radio – I really hope the tutorials explain that better than I >>>>> could. >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote: >>>>> > Hello. I'm trying to write a block in gnuradio for broadband >>>>> reception. >>>>> > The main problem at the moment is to transfer data to the fft >>>>> block. >>>>> > I'm new to python and so it's hard for me to figure this out.import >>>>> numpy as np >>>>> > >>>>> > I need an array of data to pass to the gnuradio.fft.fft.vcc block >>>>> > >>>>> > from gnuradio import gr >>>>> > from gnuradio import uhd >>>>> > from gnuradio import fft >>>>> > >>>>> > class blk(gr.sync_block): # other base classes are basic_block, >>>>> decim_block, interp_block >>>>> > """Embedded Python Block example - a simple multiply const""" >>>>> > >>>>> > def __init__(self, >>>>> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6): >>>>> # only default arguments here >>>>> > """arguments to this function show up as parameters in GRC""" >>>>> > gr.sync_block.__init__( >>>>> > self, >
Re: [Discuss-gnuradio] GNURadio Help
Hello.
If I understand what you are saying correctly, you would like to process
wide band data. And you mention 70 MHz to 6 GHz.
Even with RFNOC there is a limitation on the amount of data you can process
simultaneously, and that is about 200 MHz. There is no way possible to
simultaneously process a 6GHz band with one host and radio. You would need
an array of radios.
Please provide more details on design requirements, it hard to understand
what you are trying to accomplish.
On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk
wrote:
> In the future, I would also like to use the RFNoC
>
> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>
>> I need to rebuild the frequency, do fft and then transfer the whole array
>> from 70 to 6GHz to the host machine. I do not quite imagine how you can
>> do this with standard blocks in gnuradio.
>>
>>
>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>>
>>> Dear Ivan,
>>>
>>> you don't pass data to a block yourself.
>>>
>>> You write a block that does a clearly-limited signal processing job,
>>> and use GNU Radio to connect that to other blocks:
>>>
>>> https://tutorials.gnuradio.org
>>>
>>> In your case, instantiating a USRP source in your block makes
>>> absolutely no sense, for example. You'd build a flow graph containing
>>> the USRP source, and your custom-written block, and you'd connect these
>>> two.
>>>
>>> It's sadly not really clear what you want to achieve, so I'm afraid I'm
>>> not able to help you here.
>>>
>>> Generally, GNU Radio pretty much takes the idea of "draw a block
>>> diagram of what you want to achieve with your signal processing", and
>>> directly translates it to "using existing blocks and writing new ones,
>>> and letting GNU Radio take care of how the data gets around".
>>>
>>> Also, wideband signal processing and implementing a sync_block in
>>> Python... do not work well together.
>>>
>>> So, I think you might really be a bit confused about the architecture
>>> of GNU Radio – I really hope the tutorials explain that better than I
>>> could.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
>>> > Hello. I'm trying to write a block in gnuradio for broadband reception.
>>> > The main problem at the moment is to transfer data to the fft block.
>>> > I'm new to python and so it's hard for me to figure this out.import
>>> numpy as np
>>> >
>>> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
>>> >
>>> > from gnuradio import gr
>>> > from gnuradio import uhd
>>> > from gnuradio import fft
>>> >
>>> > class blk(gr.sync_block): # other base classes are basic_block,
>>> decim_block, interp_block
>>> > """Embedded Python Block example - a simple multiply const"""
>>> >
>>> > def __init__(self,
>>> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
>>> # only default arguments here
>>> > """arguments to this function show up as parameters in GRC"""
>>> > gr.sync_block.__init__(
>>> > self,
>>> > name='Python Block', # will show up in GRC
>>> > in_sig=None,
>>> > out_sig=[np.complex64,np.complex64]
>>> > )
>>> > # if an attribute with the same name as a parameter is found,
>>> > # a callback is registered (properties work, too).
>>> > self.gain = gain
>>> > self.start_freq=start_freq
>>> > self.stop_freq=stop_freq
>>> > self.samp_rate=samp_rate
>>> > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
>>> > uhd.stream_args(
>>> > cpu_format="fc32",
>>> > otw_format="sc16",
>>> > chanels=range(1),
>>> > ),
>>> > )
>>> >
>>> >
>>> > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
>>> > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
>>> > self.uhd_usrp_source_0.set_gain(self.gain, 0)
>>> > self.uhd_usrp_source_0.set_antenna("RX2", 0)
>>> > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
>>> > self.range_freq=(self.stop_freq-self.start_freq)/self.samp_
>>> rate
>>> >
>>> > def work(self, input_items, output_items):
>>> > """example: multiply with constant"""
>>> > for i in np.range(self.range_freq):
>>> > self.uhd_usrp_source_0.set_ce
>>> nter_freq(self.start_freq+self.samp_rate*i)
>>> > data=np.array(self.uhd_usrp_s
>>> ource_0.finite_acquisition(8192))
>>> > output_items[0][:] = input_items[0] * self.example_param
>>> > return len(output_items[0])
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> >
Re: [Discuss-gnuradio] Custom block not showing up in gnuradio-companion blocks list (but ok in Linux)
You need to check directory " /opt/local/share/gnuradio/grc/blocks" to see if your xml file is present. If it is not, then look at output from "sudo make install" to see if file is being installed or updated. >From what it looks like, given that it works in on previous and other platforms. I suspect file is not being installed. If that is the case, then you need to look at output from cmake to see if it give any clues as to why. On Sat, Jun 2, 2018 at 12:17 AM, Chris Kuethe wrote: > I think you may be missing the .xml file. > > Clearly you've got the python that implements the actual signal > processing, eg. https://github.com/ckuethe/gr-nmea/blob/master/ > python/nmea_gpsd.py > Now you need to show gnuradio-companion how to use it, eg. > https://github.com/ckuethe/gr-nmea/blob/master/grc/gps_nmea_gpsd.xml > > On Sun, May 27, 2018 at 6:16 AM Brad Hein wrote: > >> >> For some reason my custom block won't show up in gnuradio on my mac (but >> works fine on my Linux servers). I've tried various things over the past >> few weeks. Not making much progress so posting here to get some >> suggestions. >> >> OS: OSX/Mac High Sierra. >> gnuradio is installed with Macports, Version 3.7.11. >> >> $ which gnuradio-companion >> /opt/local/bin/gnuradio-companion >> >> $ port installed|grep -i gnuradio >> gnuradio @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+ >> qtgui+sdl+swig+uhd+wavelet+zeromq >> gnuradio @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+ >> qtgui+sdl+swig+uhd+wavelet+wxgui+zeromq (active) >> >> My custom block installs elsewhere and even on my previous mac, but not >> on this new one. Something must be different. >> >> $ mkdir build-mac >> $ cmake ../ >> $ make >> [ 8%] Built target gnuradio-powerquality >> [ 21%] Built target test-powerquality >> [ 30%] Built target _powerquality_swig_doc_tag >> [ 39%] Built target powerquality_swig_swig_doc >> [ 47%] Built target _powerquality_swig_swig_tag >> [ 69%] Built target powerquality_swig_swig_2d0df >> [ 78%] Built target pygen_swig_8ae51 >> [ 86%] Built target _powerquality_swig >> [ 95%] Built target pygen_python_5cd9b >> [ 95%] Built target pygen_apps_9a6dd >> [100%] Built target doxygen_target >> >> $ sudo make install >> [ 8%] Built target gnuradio-powerquality >> [ 21%] Built target test-powerquality >> [ 30%] Built target _powerquality_swig_doc_tag >> [ 39%] Built target powerquality_swig_swig_doc >> [ 47%] Built target _powerquality_swig_swig_tag >> [ 69%] Built target powerquality_swig_swig_2d0df >> [ 78%] Built target pygen_swig_8ae51 >> [ 86%] Built target _powerquality_swig >> [ 95%] Built target pygen_python_5cd9b >> [ 95%] Built target pygen_apps_9a6dd >> [100%] Built target doxygen_target >> Install the project... >> -- Install configuration: "Release" >> -- Up-to-date: /usr/local/lib/cmake/powerquality/powerqualityConfig.cmake >> -- Up-to-date: /usr/local/include/powerquality/api.h >> -- Up-to-date: /usr/local/include/powerquality/getfreqcpp.h >> -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.1.0.0git.dylib >> -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.dylib >> -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/_ >> powerquality_swig.so >> -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/ >> powerquality_swig.py >> -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/ >> powerquality_swig.pyc >> -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/ >> powerquality_swig.pyo >> ...snip... >> >> (Start up gnuradio-companion) >> >> <<< Welcome to GNU Radio Companion 3.7.11 >>> >> Block paths: >> /usr/local/lib/python2.7/site-packages >> /opt/local/share/gnuradio/grc/blocks >> >> >> gnuradio-companion even lists the precise location where my custom block >> was installed, as one of the block paths. >> >> $ ls -ltrh /usr/local/lib/python2.7/site-packages/powerquality/ >> total 600 >> -rw-r--r-- 1 root admin 1.1K Aug 21 2017 __init__.py >> -rw-r--r-- 1 root admin18K Apr 10 12:37 powerquality_swig.py >> -rw-r--r-- 1 root admin27K Apr 10 12:37 powerquality_swig.pyo >> -rw-r--r-- 1 root admin27K Apr 10 12:37 powerquality_swig.pyc >> -rwxr-xr-x 1 root admin 210K Apr 10 12:37 _powerquality_swig.so >> -rw-r--r-- 1 root admin 369B Apr 10 12:37 __init__.pyo >> -rw-r--r-- 1 root admin 369B Apr 10 12:37 __init__.pyc >> >> >> But the block (block name getfreqcpp) is not showing up in the list... >> >> At the commandline I can import the block in Python. >> >> $ python >> Python 2.7.10 (default, Oct 6 2017, 22:29:07) >> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import powerquality >> >>> from powerquality import getfreqcpp >> >>> getfreqcpp >> >> >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >>
Re: [Discuss-gnuradio] qa test failed!
Your line: self.tb.connect(detec. dst) Should be: self.tb.connect(detec, dst) You have period instead of comma. On Mon, May 28, 2018 at 3:55 PM, Linda20071 wrote: > I created a module named detector0 with one input argument: int len. In > the python qa file, I set the len to 20. However, when I issued the > command: ctest -V -R detector0, I got the following error: > > 2: Test timeout computed to be: 9.99988e+06 > 2: E > 2: = > 2: ERROR: test_001_detector0 (__main__.qa_detector0) > 2: -- > 2: Traceback (most recent call last): > 2: File "qa_detector0.py", line 42, in test_001_detector0 > 2: self.tb.connect(detec. dst) > 2: AttributeError: 'detector0_sptr' object has no attribute 'dst' > > My related python codes are as follows: > > src = blocks.vector_source_f(src_data) > d_len = 20 > detec = detectors.detector0(d_len) > dst = blocks.vector_sink_f() > self.tb.connect(src, detec) > self.tb.connect(detec. dst) > # set up fg > self.tb.run () > # check data > result_data = dst.data() > self.assertFloatTuplesAlmostEqual(expected_result, result_data, 6) > > I couldn't see any problems in the connection: self.tb.connect(detec. > dst). > > Any advice on solving this AttributeError? > > ___ > 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] GNURadio master and UHD RFNOC Version Issue
Hello, I apologize for my terminology, it is causing some confusion. If you download the source from https://github.com/EttusResearch/uhd. You can compile this version and it should work fine with latest version of GNU Radio. But this version is missing additional modules that are available in branch rfnoc-devel. I inspected /host/lib/rfnoc for both the master and rfnoc-devel branches; there are several modules from rfnoc-devel branch such as sig_gen that are not available in master branch. That is what I am referring to as RFNOC UHD. I would like to continue using rfnoc-devel branch, and hence the issue that I am having. Since the version we were instructed that works with that branch, no longer compiles in latest version of Fedora. That version being v3.7.10.2. When we build source, we typically install all dependencies and it the proceeds to build with no issue. But in this latest version of Fedora, we received compilation errors while trying to build v3.7.10.2. Since latest version of GNU Radio built with no issue, I suspected that changes had been made to correct for newer version. Where in the source code, do they check the version of UHD for compatibility? This will help me to look back at and see which GNU Radio versions are compatible with the rfnoc-devel branch. Thank you again. On Fri, May 25, 2018 at 6:46 AM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Hi John, > On Fri, 2018-05-25 at 06:39 -0600, John Medrano wrote: > > Thank you for the response. > > > > The issue that we have is that the latest UHD RFNOC version is not > compatible with latest version of GNU Radio. > > That's simply not true. UHD, to GNU Radio, is just a library. > > > > > So I must either compile older version in with newer compiler, > > the compiler version has little to nothing to do with this, luckily :) > > > or downgrade to a version that is compatible with UHD RFNOC. > > You need to use a UHD version that supports what you need (RFNoC); "UHD > RFNOC" is not a thing. RFNoC is an architectural aspect of the FPGA > designs running on some USRPs. So, you need an _UHD_ version that comes > with compatibility for these. > > > Upgrading UHD to latest version will not allow us to use RFNOC. I may > be wrong, but that is my understanding. > > You'll probably need to manually build UHD, anyway. > After that, you need to build GNU Radio against that UHD version. > > Best regards, > Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio master and UHD RFNOC Version Issue
Thank you for the response. The issue that we have is that the latest UHD RFNOC version is not compatible with latest version of GNU Radio. So I must either compile older version in with newer compiler, or downgrade to a version that is compatible with UHD RFNOC. Upgrading UHD to latest version will not allow us to use RFNOC. I may be wrong, but that is my understanding. So I am trying to figure out what it is that I need to do to get the older version to compile, or is there a newer version that will compile that is compatible with UHD RFNOC? Thanks On Fri, May 25, 2018 at 6:31 AM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Hi John, > GNU Radio versioning is totally independent from UHD versioning, and > that's what's defining the compatibility with the FPGA image. > So, you need to install the UHD that fits your FPGA image (or use an > FPGA image that fits your installed UHD). > > Best regards, > Marcus > On Thu, 2018-05-24 at 13:21 -0600, John Medrano wrote: > > Recently we built GNURadio and UHD from source on a Fedora 28. Since we > use RFNOC we were compiling GNURadio version v3.7.10.2, and using > rfnoc-devel branch from UHD. > > > > Building on Fedora 28 we received compiling errors when we were building > v3.7.10.2. So we decided to build the master branch instead. > > > > The problem is that the master branch is not compatible with UHD > firmware for RFNOC. Expecting firmware version 85 and found version 83. > > > > Is the current UHD RFNOC branch in github compatible with master branch > of GNURadio? > > > > What is latest version of GNURadio that we can use? Can we compile in > Fedora 28? > > > > Please advise, > > > > Thank you, > > John > > ___ > > 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] GNURadio master and UHD RFNOC Version Issue
Recently we built GNURadio and UHD from source on a Fedora 28. Since we use RFNOC we were compiling GNURadio version v3.7.10.2, and using rfnoc-devel branch from UHD. Building on Fedora 28 we received compiling errors when we were building v3.7.10.2. So we decided to build the master branch instead. The problem is that the master branch is not compatible with UHD firmware for RFNOC. Expecting firmware version 85 and found version 83. Is the current UHD RFNOC branch in github compatible with master branch of GNURadio? What is latest version of GNURadio that we can use? Can we compile in Fedora 28? Please advise, Thank you, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
