Re: Regarding missing osmocom source

2020-11-04 Thread Mohamed Yaaseen
Hello,

Yes, as Christiophe mentioned i don't think we have a working version of gr
osmocom that is compatible with gnuradio 3.9.
If your ppa version of gnuradio that you have downloaded is 3.8.2 then you
just need to build osmocom sdr by pulling from its master branch.
You can find the gnuradio version by using the command
"gnuradio-config-info"
I have been using bladeRF for quite some time now. Currently running
gnuradio 3.8.2 with osmocom under ubuntu 20.04 LTS. Both of them build from
source.  BladeRF is running seamlessly.
You can also try soapySDR to get BladeRF support.


Cheers,
Yaseen



On Wed, 4 Nov 2020, 1:24 pm Rozana Alam,  wrote:

> Thank you for the information. I have installed GRC byUbuntu ppa and I
> believe that it has installed the latest version.in that case should I
> delete and build the GRC from the beginning from source? please guide me.
>
> On Wed, 4 Nov 2020, 6:58 pm Christophe Seguinot, <
> christophe.segui...@orange.fr> wrote:
>
>> Hi
>>
>> You must install gr-osmosdr to use SDR dongle ( I don't use Blade RF and
>> don't know if there are other gr tools for Blade RF source/sink )
>>
>> at the end of september, for Linux distribution (Ubuntu 20.04 in my case):
>>
>>- gr-osmosdr is not compatible with GR 3.9 (see some recent mail on
>>this list) so don't use GR 3.9 (Some guys are trying to port gr-osmosdr to
>>3.9 )
>>- 3.8.2 is the default GR version under Ubuntu 20.04 (using
>>ppa:gnuradio/gnuradio-releases)
>>- if you install gr-osmosdr from package,* it won't work under GR*
>>- if you build gr-osmosdr from source, *you can get a working GR3.8
>>with osmo-sdr sources as well as GQRX too*.
>>
>> See my email on this list
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00124.html
>> for furter information
>>
>> Sincerely
>> On 04/11/2020 09:39, Rozana Alam wrote:
>>
>> Hello community,
>> I want to generate simple continuous wave with bladeRF using gnu radio
>> and am a Linux user.but in the gnu platform I am not getting any osmocom
>> source.i have downloaded the gnu from ppa .is there any supplement of
>> osmocom source to generate signal by bladeRF?
>> Your suggestions are highly appreciated.
>> Best regards,
>> Rozana.
>>
>>
>>


Re: [USRP-users] How to find and link OOT module with gnuradio 3.8?

2020-07-01 Thread Mohamed Yaaseen
Hello EJ Kreinar,

I have somehow made gr-ettus and rfnoc mod tools to work with gnuradio 3.8.
I created, built and installed the gain rfnoc oot module. And it was
working as it should be.

I created a new branch called working-maint-3.8 for gr-ettus and pushed it
to my personal repository.

I have  just modified the cmake files and doxygen file (which was problem
during make process)

Here is the link:
https://github.com/yaaseen-dev/gr-ettus.git

This is my first time I am dealing with cmake stuff, so, I am also not sure
if this is the correct way to modify it. Because as you said, entire rfnoc
mod tools need to be updated to gr3.8
similar to gr_modtools
.
But, these fixes worked for me.

You can clone this, and check if it works for you also.

Hope this helps you also


Regards,
Yaaseen


On Wed, 1 Jul 2020 at 02:44, EJ Kreinar  wrote:

> Ron,
>
> Yes, that looks right on target with my results... A little baffling to me
> though... linking against OOTs seems like a fairly standard use case but
> maybe it's less common than I thought. It's definitely needed for rfnoc
> though.
>
>
> Mohamed Yaaseen,
>
> The change that worked for me was to update GR_CMAKE_DIR in gr-ettus to
> ${CMAKE_MODULES_DIR)/gnuradio-ettus. Then I rebuilt and installed gr-ettus,
> and my OOT could then call find_package(gnuradio-ettus) and link against
> gnuradio-ettus.
>
> But I'm really not a cmake expert in any way, so I don't know if this is
> the "right" answer. Personally I'm satisfied with the GR_CMAKE_DIR change,
> but it does change the package name for downstream users...
>
> I guess the broader question is then... What is "desired" behavior provided
> by default from gr_modtool for finding and linking OOTs?
>
> EJ
>
> On Tue, Jun 30, 2020, 10:53 AM Mohamed Yaaseen 
> wrote:
>
>> Hello EJ Kreinar,
>>
>> I just came across this situation. I was trying to create a rfnoc gain
>> tutorial oot module using rfnomodtools. But, when I was doing cmake I got
>> some errors with respect to find_package(ettus).
>> I was just fiddling around with cmakefiles as I am not familiar with
>> cmake and stuff.
>>
>> But, I found a problem with the gr-ettus module itself. In the gr-ettus
>> module ettutsConfig.cmake file, there is a line
>> *include("${CMAKE_CURRENT_LIST_DIR}/ettusTarget.cmake"). *
>> This is the file that rfnoc OOT searches in order to find the
>> package ettus. But, while make && make install gr-ettus module installs 
>> *gnuradio-ettusTargets.cmake
>> *file at the location. Hence, rfnoc OOT module throws an error message
>> during cmake.
>>
>> When I corrected the line in gr-ettus and reinstalled it, my OOT module
>> was able to compile  successfully.
>>
>> But, I am now facing errors during the make process.
>>
>> I believe the rfnocmodtools template code present inside gr-ettus has not
>> been migrated for 3.8 even though gr-ettus is migrated.
>>
>> In the meantime I will also try to fix the error which is thrown during
>> make process. And update you in this thread if I have any success
>>
>> If you are able to get past the make process also and install it in gr
>> 3.8. It would be really great...!!!
>>
>> Regards,
>> Mohamed Yaaseen
>>
>> On Tue, 30 Jun 2020 at 16:01, EJ Kreinar via USRP-users <
>> usrp-us...@lists.ettus.com> wrote:
>>
>>> Hi gnuradio and usrp-users,
>>>
>>> I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).
>>>
>>> But I'm having trouble finding and linking to gr-ettus specifically, and
>>> I wonder how we're supposed to call find_package() and then link to
>>> OOT modules in general with the updated cmake workflow... Trying to find
>>> and link gr-ettus, I've tried a few things...
>>>
>>> 1) find_package(ettus)
>>>
>>> I believe this worked against gnuradio-3.7. Now, I get the following
>>> error during cmake configure...
>>>
>>> ```
>>> --   No package 'ettus' found
>>> CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
>>>   include could not find load file:
>>> /usr/local/lib/cmake/ettus/ettusTarget.cmake
>>> ```
>>>
>>> 2) find_package(gnuradio-ettus)
>>>
>>> This seems more promising, since GR_LIBRARY_FOO seems to
>>> install gnuradio-ettus cmake files into the lib/cmake/ettus install
>>> location. This fails in cmake configure with the following error:
>>>
>>> ```
>>> CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
>>>   By not providing &

Re: [USRP-users] How to find and link OOT module with gnuradio 3.8?

2020-06-30 Thread Mohamed Yaaseen
Hello EJ Kreinar,

I just came across this situation. I was trying to create a rfnoc gain
tutorial oot module using rfnomodtools. But, when I was doing cmake I got
some errors with respect to find_package(ettus).
I was just fiddling around with cmakefiles as I am not familiar with cmake
and stuff.

But, I found a problem with the gr-ettus module itself. In the gr-ettus
module ettutsConfig.cmake file, there is a line
*include("${CMAKE_CURRENT_LIST_DIR}/ettusTarget.cmake"). *
This is the file that rfnoc OOT searches in order to find the
package ettus. But, while make && make install gr-ettus module
installs *gnuradio-ettusTargets.cmake
*file at the location. Hence, rfnoc OOT module throws an error message
during cmake.

When I corrected the line in gr-ettus and reinstalled it, my OOT module was
able to compile  successfully.

But, I am now facing errors during the make process.

I believe the rfnocmodtools template code present inside gr-ettus has not
been migrated for 3.8 even though gr-ettus is migrated.

In the meantime I will also try to fix the error which is thrown during
make process. And update you in this thread if I have any success

If you are able to get past the make process also and install it in gr 3.8.
It would be really great...!!!

Regards,
Mohamed Yaaseen

On Tue, 30 Jun 2020 at 16:01, EJ Kreinar via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> Hi gnuradio and usrp-users,
>
> I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).
>
> But I'm having trouble finding and linking to gr-ettus specifically, and I
> wonder how we're supposed to call find_package() and then link to OOT
> modules in general with the updated cmake workflow... Trying to find and
> link gr-ettus, I've tried a few things...
>
> 1) find_package(ettus)
>
> I believe this worked against gnuradio-3.7. Now, I get the following error
> during cmake configure...
>
> ```
> --   No package 'ettus' found
> CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
>   include could not find load file:
> /usr/local/lib/cmake/ettus/ettusTarget.cmake
> ```
>
> 2) find_package(gnuradio-ettus)
>
> This seems more promising, since GR_LIBRARY_FOO seems to
> install gnuradio-ettus cmake files into the lib/cmake/ettus install
> location. This fails in cmake configure with the following error:
>
> ```
> CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
>   By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
>   project has asked CMake to find a package configuration file provided by
>   "gnuradio-ettus", but CMake did not find one.
>
>   Could not find a package configuration file provided by "gnuradio-ettus"
>   with any of the following names:
>
> gnuradio-ettusConfig.cmake
> gnuradio-ettus-config.cmake
>
>   Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or
> set
>   "gnuradio-ettus_DIR" to a directory containing one of the above files.
> If
>   "gnuradio-ettus" provides a separate development package or SDK, be sure
> it
>   has been installed.
> ```
>
>
> Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to
> ${CMAKE_MODULES_DIR)/gnuradio-ettus (
> https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69),
> then the gnuradio-ettus cmake modules get installed to
> lib/cmake/gnuradio-ettus. Then, in my OOT module, calling
> find_package(gnuradio-ettus) finds gr-ettus, and
> target_link_libraries( gnuradio-ettus) links successfully.
>
> So: Is this right? Am I missing something obvious here? Should gnuradio
> OOT modules set their GR_CMAKE_DIR to gnuradio-?
>
> Thanks for the help!
> EJ
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


Re: Symbol timing estimator block and CPM modulations

2020-06-28 Thread Mohamed Yaaseen
Hello Alex,

  Few months ago, I was also having some similar issues, with respect
to GFSK modulation. I was using a M TED and I was getting a loss
percentage of about 7% mainly due to having a large amount of tx packets
(100 pkts/s) . So, it was suggested to me to use a correlator sync block to
pre sync the packets, and then do timing recovery.
But, since I also couldn't find a M-fsk or MSK modulation class I start
doing some research and I found that the timing recovery block works
perfectly if there are no noise in the demodulated output, so I created my
own version of demodulator which outputs values only of signal is present,
and in case of noise I just output some negative value, say like -5. It
just a concept if signal power is above a threshold then it is actual tx if
not it is a noise

 I am not sure if this can solve your problem. Thought  just in case you
may find it useful. Cheers.!


Regards,
Mohamed Yaaseen


On Sun, 28 Jun 2020 at 02:43, Alex Roberts  wrote:

> Andy,
>
> I’m not sure how integrate the correlation sync block with gmsk. It
> expects modulated symbols and I’m not sure how to generate a modulated
> vector of gmsk symbols.  There doesn’t seem to be a gmsk class that can be
> used by the modulate vector block.
>
> Thanks,
> Alex
>
> On Thursday, June 25, 2020, Andy Walls 
> wrote:
>
>> Recommend reading
>>
>> https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf
>>
>> Yeah, the MSK TED selections for the symbol sync block expect the
>> constant envelope FSK waveform on the input.  Demodulation from FSK to
>> baseband pulses should happen after the symbol sync block.
>>
>


Re: [USRP-users] NEED HELP: RFNoC OOT tutorial

2020-06-26 Thread Mohamed Yaaseen
Hello Cherif,
  I followed the same tutorial, it is the same as in AN here:
https://kb.ettus.com/Getting_Started_with_RFNoC_Development
But, uhd 4.0 mentioned in there is the pybombs recipes, I am not sure which
source used to built these recipes, but I guess it should be uhd
rfnoc-devel branch
The UHD-3.15 branch of uhd repository is the current stable version and
master branch corresponds to UHD-4.0.0.


Regards,
Mohamed Yaaseen


On Fri, 26 Jun 2020 at 17:51, cherif chibane 
wrote:

> Hi Moahmmed,
>
> I am in the process going that RFOC tutorial in:
>
> https://www.youtube.com/watch?v=j-EfyPVpaJ8
>
> He seems to be using UHD 4.0.0 and yet  he uses XML for binding the RFNoC
> module he created. Am I missing something?
>
> Thanks,
> Cherif
>
>
>
> On Fri, Jun 26, 2020 at 11:14 AM Mohamed Yaaseen via USRP-users <
> usrp-us...@lists.ettus.com> wrote:
>
>> Hello Guys,
>>
>> I am following the rfnoc getting started tutorial, to develop a gain
>> block. I am using the following branches of UHD, gr-ettus, gnuradio.
>> UHD - 3.15 LTS
>> gr-ettus - maint-3.8
>> gnuradio - maint-3.8
>> All installed in a custom prefix without using pybombs:
>> ~/workspace/installs/stable
>>
>> I have created the gain oot module using rfnocmodtool with all the
>> testbench and also have created the FPGA image. Now to create a gnuradio
>> grc bindings, the tutorial uses the xml file.
>> Since I am using gnuradio 3.8, it requires a yaml file. But even though I
>> am using gr-ettus maint-3.8 branch it's rfnocmodtools is not updated to
>> have yaml files. So, I am  stuck with xml.
>> Yea, I can just convert xml to yaml file manually, But, I find many extra
>> parameter with the xml file
>> and I am also not sure  how  I should change the CMakeLists.txt so that
>> the yaml files get installed correctly, while installing the OOT module.
>> I need some help on how I can create a yaml file for rfnoc oot in a
>> proper way ?
>>
>> My second question is: Currently, I can see that in the master branch of
>> UHD, the entire RFNoC work flow is  changing. I couldn't find
>> uhd_image_builder.py and gr-ettus is going to be removed etc.
>> I will  be working with RFNoC for the next couple of months, so I would
>> like to know If I should be moving to UHD 4.0.0 before I begin developing
>> my actual rfnoc application. And if so, is there any guide or how-to page
>> for RFNoC getting started UHD - 4.0.0 ? The current AN seems pretty
>> outdated even for UHD-3.15-LTS version
>>
>> Looking forward to your suggestions, tips and answers ..!!
>>
>> Thanks, stay safe and healthy !!
>>
>> Regards,
>> Mohamed Yaaseen
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>


NEED HELP: RFNoC OOT tutorial

2020-06-26 Thread Mohamed Yaaseen
Hello Guys,

I am following the rfnoc getting started tutorial, to develop a gain
block. I am using the following branches of UHD, gr-ettus, gnuradio.
UHD - 3.15 LTS
gr-ettus - maint-3.8
gnuradio - maint-3.8
All installed in a custom prefix without using pybombs:
~/workspace/installs/stable

I have created the gain oot module using rfnocmodtool with all the
testbench and also have created the FPGA image. Now to create a gnuradio
grc bindings, the tutorial uses the xml file.
Since I am using gnuradio 3.8, it requires a yaml file. But even though I
am using gr-ettus maint-3.8 branch it's rfnocmodtools is not updated to
have yaml files. So, I am  stuck with xml.
Yea, I can just convert xml to yaml file manually, But, I find many extra
parameter with the xml file
and I am also not sure  how  I should change the CMakeLists.txt so that the
yaml files get installed correctly, while installing the OOT module.
I need some help on how I can create a yaml file for rfnoc oot in a  proper
way ?

My second question is: Currently, I can see that in the master branch of
UHD, the entire RFNoC work flow is  changing. I couldn't find
uhd_image_builder.py and gr-ettus is going to be removed etc.
I will  be working with RFNoC for the next couple of months, so I would
like to know If I should be moving to UHD 4.0.0 before I begin developing
my actual rfnoc application. And if so, is there any guide or how-to page
for RFNoC getting started UHD - 4.0.0 ? The current AN seems pretty
outdated even for UHD-3.15-LTS version

Looking forward to your suggestions, tips and answers ..!!

Thanks, stay safe and healthy !!

Regards,
Mohamed Yaaseen


ERROR: cannot build gr-clenabled OOT module; fails during make process

2020-06-09 Thread Mohamed Yaaseen
Hello guys,

 I am trying to install, gr-clenabled. cmake works fine but I am
getting error during make

/usr/bin/ld: cannot find -lgnuradio-blocks
> /usr/bin/ld: cannot find -lgnuradio-fft
> /usr/bin/ld: cannot find -lgnuradio-filter
> collect2: error: ld returned 1 exit status
> make[2]: *** [lib/CMakeFiles/gnuradio-clenabled.dir/build.make:432:
> lib/libgnuradio-clenabled.so.6b9969c4] Error 1
> make[1]: *** [CMakeFiles/Makefile2:417:
> lib/CMakeFiles/gnuradio-clenabled.dir/all] Error 2
> make: *** [Makefile:141: all] Error 2
>


I have a gnuradio maint-3.8 installed to a custom prefix
~/workspace/installs/stable/
without using pybombs
so during cmake step I gave
-DCMAKE_INSTALL_PREFIX=~/workspace/installs/stable

What am I missing here ?

Regards,
Yaaseen


Re: HELP: needed with RFNoC & gr-ettus & PFB

2020-06-09 Thread Mohamed Yaaseen
Hello EJ Kreinar,

 Thank you for your reply. I am planning to use theseus.On a side
note I was seeing your talk on GRCon 18 when I was writing this email :)
Great talk by the way !!
As a first step I am trying to make a working POC, so if no. of channels
are restricted to powers of 2,  I will choose 64MHz spectrum splitting into
32x 2 MHz channels.
But, I need all the 32 channels into my GRC, which need to be further
demodulated, perform symbol synchronization etc. Currently, with the 20
channels, with just channelizers running in GRC with null sink connected I
am seeing overflows.
I need figure out how can I handle this.
I have one question though, in your talk you had mentioned that the
channels are interleaved like 0 | 1 | .| N -1  where N is the total no.
of channels. So, for example if I take 4 MHz bandwidth and split it into 4x
1 MHz in normal GRC PFB I will get 4 streams of 1 Msps each but if I use
RFNoC implementation then my stream will be looking like 0 | 1 | 2 | 3
samples interleaved between channels, so what is rate of this interleaved
stream, still 4Msps ?

Regards,
Mohamed Yaaseen



On Sat, 6 Jun 2020 at 13:17, EJ Kreinar  wrote:

> Hi Mohamed,
>
> I'll see if I can field a few of your questions...
>
> 3. I am currently pseudo-maintaining theseus-cores repo:
> gitlab.com/theseus-cores/theseus-cores By that I mean Im not currently
> actively developing anything for it (my spare time available to work on
> open source fpga has decreased), but I haven't given up on it :p I've
> tested these builds against UHD 3.15 as of approx December 2019.
>
> Part of this repo includes a M/2 polyphase filter bank implementation that
> includes fpga-based channel selection (so you don't need to return all
> channels from fpga to processor). A couple caveats for your application: I
> believe the number of channels is constrained to a power of 2, and I
> suspect there's a bug with channel selection for more than 64 channels. But
> overall it's probably a decent place to start; several people have used
> theseus-cores successfully to test polyphase filtering. Happy to field any
> related questions here.
>
> 4. I've found the rfnoc 4.0 spec as an app note here:
> https://files.ettus.com/app_notes/RFNoC_Specification.pdf
>
> While I'm excited for the 4.0 update, Im afraid I can't provide any better
> context on rfnoc 4.0 progress or tooling maturity at this point, hopefully
> others can step in with that info!
>
> Hope this helps,
> EJ
>
> On Sat, Jun 6, 2020, 5:35 AM Mohamed Yaaseen 
> wrote:
>
>> Hello Guys,
>>   recently I have started looking into the RFNoC platform. I have
>> successfully installed RFNoC and was able to build fpga images with
>> default pre-built modules like fft etc. I haven't; however started with the
>> gain module from "Getting started tutorial"  .
>>
>> My system setup,
>>
>> USRP x310  with XG image (connected to PC using dual 10 Gig Ethernet)
>>
>> uhd -  UHD 3.15 LTS branch
>> gnuradio --   maint-3.8   branch
>> gr-ettus-- maint-3.8  branch
>> vivado system edition (with HLS, Model Composer, DSP system generator)
>> - 2018.03v
>>
>> fpga images and code was submoduled as part of uhd hence they are at\
>>  ~/{UHD SRC DIR}/fpga-src/usrp3/..
>>
>> all installed in a custom prefix (~/workspace/installs/stable) without
>> pybombs.
>> I have couple of questions and errors I got  that I want help with
>>
>>
>>1.  As of this branch UHD 3.15 LTS, it was mentioned I should use
>>uhd_image_builder_gui.py or uhd_image_builder.py script. So, when I used
>>it, I couldn't find target type  X310_RFNOC_HLS_HG . Is it removed or what
>>up with that ?
>>2.  Second is with respect to gr-ettus (I came to know that there are
>>some major changes going with this in upcoming UHD 4.0 I will come to that
>>in later points). So, as per tutorial we have to use rfnodmodtools which 
>> is
>>part of gr-ettus to create our own OOT  RFNoC module. But, I faced one
>>error with it and I  fixed that error (I am not sure if it is a correct
>>fix). I have raised an issue here in gr-ettus repo. please anyone let me
>>know if this is a issue or if I was doing something wrong. Because the is
>>is with respect to path of rfnocmodtools template. Here is the link for 
>> the
>>issue: https://github.com/EttusResearch/gr-ettus/issues/45
>>3. Third, as this will be my first time working with RFNoC and FPGA
>>(atleast with Xilinx, I have some experience from my studies).  My main
>>interest with RFNoC is that I wanna create a channelizer, for 160MHz and
>&

HELP: needed with RFNoC & gr-ettus & PFB

2020-06-06 Thread Mohamed Yaaseen
Hello Guys,
  recently I have started looking into the RFNoC platform. I have
successfully installed RFNoC and was able to build fpga images with
default pre-built modules like fft etc. I haven't; however started with the
gain module from "Getting started tutorial"  .

My system setup,

USRP x310  with XG image (connected to PC using dual 10 Gig Ethernet)

uhd -  UHD 3.15 LTS branch
gnuradio --   maint-3.8   branch
gr-ettus-- maint-3.8  branch
vivado system edition (with HLS, Model Composer, DSP system generator)
- 2018.03v

fpga images and code was submoduled as part of uhd hence they are at\
 ~/{UHD SRC DIR}/fpga-src/usrp3/..

all installed in a custom prefix (~/workspace/installs/stable) without
pybombs.
I have couple of questions and errors I got  that I want help with


   1.  As of this branch UHD 3.15 LTS, it was mentioned I should use
   uhd_image_builder_gui.py or uhd_image_builder.py script. So, when I used
   it, I couldn't find target type  X310_RFNOC_HLS_HG . Is it removed or what
   up with that ?
   2.  Second is with respect to gr-ettus (I came to know that there are
   some major changes going with this in upcoming UHD 4.0 I will come to that
   in later points). So, as per tutorial we have to use rfnodmodtools which is
   part of gr-ettus to create our own OOT  RFNoC module. But, I faced one
   error with it and I  fixed that error (I am not sure if it is a correct
   fix). I have raised an issue here in gr-ettus repo. please anyone let me
   know if this is a issue or if I was doing something wrong. Because the is
   is with respect to path of rfnocmodtools template. Here is the link for the
   issue: https://github.com/EttusResearch/gr-ettus/issues/45
   3. Third, as this will be my first time working with RFNoC and FPGA
   (atleast with Xilinx, I have some experience from my studies).  My main
   interest with RFNoC is that I wanna create a channelizer, for 160MHz and
   split up into 80 channels each of 2 MHz (critically sampled). and take
   everything to the PC for 80x demod & 80x symbol sync. What is the latest
   development in that direction? I got to know a repo called gr-theseus. Is
   it maintained still ? Can I start from there or should I start from
   scratch. I am looking to connect with is anyone working/worked with PFB
   4. Last one, how is the structure gonna change in future with UHD 4.0 &
   gr-ettus gonna, it would really helpful if someone could explain (very
   confucsed with this coz i couldn't find uhd_image_builder etc.) this
   workflow with new updates and what you guys recommend should start with
   3.15 LTS or switch UHD 4.0 because by the I finish PFB i might have to port
   to a completely new workflow. But in any case, I need gnuradio integration


I know it is a lot of questions, sorry guys. But, when I started setup with
RFNoC, I faced many questions like this, and I felt others might have these
too. These points will allow people who might need them to get their
answers in a single place.

Any help, answers, suggestions  or improvements  for these questions will
be really helpful and are highly welcomed !

Thanks and Regards.
Yaaseen


Re: ERROR: using usrp source gnu-radio block with XG image (RFNoC enabled)

2020-06-04 Thread Mohamed Yaaseen
It got fixed finally. I just removed the device parameter all together. And
let the block itself decide it.
And it worked like a charm..!

Thanks & regards,
Mohamed Yaaseen

On Thu, 4 Jun 2020, 5:15 pm Mohamed Yaaseen, 
wrote:

> Yes, I tried including the "type=x300" in the device address.  Still it is
> not working. Throwing the same error. I am attaching a screenshot of the
> parameters.
>
> I have even tried ping the device which works perfectly fine. Both the
> dual 10-Gig interface can be pinged
>
> I am not sure what is the issue here !
>
> *ya-seen@sdr-linux-machine*:*~*$ ping 192.168.30.2
>> PING 192.168.30.2 (192.168.30.2) 56(84) bytes of data.
>> 64 bytes from 192.168.30.2: icmp_seq=1 ttl=32 time=0.677 ms
>> 64 bytes from 192.168.30.2: icmp_seq=2 ttl=32 time=0.651 ms
>> 64 bytes from 192.168.30.2: icmp_seq=3 ttl=32 time=0.652 ms
>> 64 bytes from 192.168.30.2: icmp_seq=4 ttl=32 time=0.632 ms
>> ^C
>> --- 192.168.30.2 ping statistics ---
>> 4 packets transmitted, 4 received, 0% packet loss, time 3064ms
>> rtt min/avg/max/mdev = 0.632/0.653/0.677/0.016 
>> ms*ya-seen@sdr-linux-machine*:*~*$ ping 192.168.40.2
>> PING 192.168.40.2 (192.168.40.2) 56(84) bytes of data.
>> 64 bytes from 192.168.40.2: icmp_seq=1 ttl=32 time=0.647 ms
>> 64 bytes from 192.168.40.2: icmp_seq=2 ttl=32 time=0.647 ms
>> 64 bytes from 192.168.40.2: icmp_seq=3 ttl=32 time=0.646 ms
>> 64 bytes from 192.168.40.2: icmp_seq=4 ttl=32 time=0.621 ms
>> ^C
>> --- 192.168.40.2 ping statistics ---
>> 4 packets transmitted, 4 received, 0% packet loss, time 3067ms
>> rtt min/avg/max/mdev = 0.621/0.640/0.647/0.011 ms
>>
>>
>
> On Thu, 4 Jun 2020 at 01:49, Marcus D. Leech 
> wrote:
>
>> On 06/03/2020 07:45 PM, Mohamed Yaaseen wrote:
>>
>> I have created a new flow graph for the non-RFNoC , one without any
>> device3 block.
>> in the device parameter of the usrp source I am using
>> "addr0=192.168.30.2, addr1=192.168.40.2"  this string
>>
>> should I have to use "type=x300" ?
>>
>> Yes. Since simply specifying an IP address isn't enough to unambiguously
>> identify the device type, AFAIR, although from your previous log,
>>   it looks like it figured it out.
>>
>> Also, when this is happening, can you ping those addresses, outside of
>> any Gnu Radio or UHD application, just can you ping them as
>>   normal IP devices?
>>
>> Also, I've copied usrp-users, where this conversation should probably be
>> moved.
>>
>>
>>
>>
>> regards,
>> Mohamed Yaaseen
>>
>>
>>
>> On Thu, 4 Jun 2020 at 01:04, Marcus D. Leech 
>> wrote:
>>
>>> On 06/03/2020 05:27 PM, Mohamed Yaaseen wrote:
>>>
>>> Hello Guys,
>>> I am using usrp x310 with default XG image. I have also setup the
>>> RFNoC platform in GNURadio with gr-ettus.
>>> RFNoC ddc example using RFNoC blocks works perfectly with 100MHz of
>>> bandwidth. But when I go back to using normal usrp source block which is a
>>> normal gr-uhd block, it throws the following error.
>>>
>>>
>>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
>>>> UHD_3.15.0.0-16-ga3ece4f2
>>>> [INFO] [X300] X300 initialization sequence...
>>>> [INFO] [X300] Maximum frame size: 8000 bytes.
>>>> [INFO] [X300] Maximum frame size: 8000 bytes.
>>>> [INFO] [X300] Radio 1x clock: 200 MHz
>>>> [INFO] [X300] Radio 1x clock: 200 MHz
>>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>>> 0xF1F0D000)
>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1296 MB/s)
>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>>> 0x12AD1001)
>>>> [INFO] [0/Radio_1] Initializing block control (NOC ID:
>>>> 0x12AD1001)
>>>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>>>> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
>>>> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C000000000)
>>>> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>>>> terminate called after throwing an instance of 'uhd::io_error'
>>>>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no
>>>> response packet - AssertionError: bool(buff)
>>>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
>>>> [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long
>>>> unsigned int]
>>>>   at /home/ya-seen/workspace/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:151
>>>>
>>>
>>>
>>> what is this issue ? what am I doing wrong here ? Help, suggestions
>>> highly appreciated
>>>
>>> thanks in advance !!
>>>
>>> Regards,
>>> Mohamed Yaaseen
>>>
>>> What is in the device arguments for the normal USRP block?  Are they the
>>> same as the device3 block?  Did you leave the device3 block in your
>>>   non-RFNOC flow-graph?
>>>
>>>
>>>
>>


ERROR: using usrp source gnu-radio block with XG image (RFNoC enabled)

2020-06-03 Thread Mohamed Yaaseen
Hello Guys,
I am using usrp x310 with default XG image. I have also setup the RFNoC
platform in GNURadio with gr-ettus.
RFNoC ddc example using RFNoC blocks works perfectly with 100MHz of
bandwidth. But when I go back to using normal usrp source block which is a
normal gr-uhd block, it throws the following error.


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_3.15.0.0-16-ga3ece4f2
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1296 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no
> response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long
> unsigned int]
>   at /home/ya-seen/workspace/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:151
>


what is this issue ? what am I doing wrong here ? Help, suggestions highly
appreciated

thanks in advance !!

Regards,
Mohamed Yaaseen


ERROR: using usrp source gnu-radio block with XG image (RFNoC enabled)

2020-06-03 Thread Mohamed Yaaseen
Hello Guys,
I am using usrp x310 with default XG image. I have also setup the RFNoC
platform in GNURadio with gr-ettus.
RFNoC ddc example using RFNoC blocks works perfectly with 100MHz of
bandwidth. But when I go back to using normal usrp source block which is a
normal gr-uhd block, it throws the following error.


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
> UHD_3.15.0.0-16-ga3ece4f2
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1296 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no
> response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long
> unsigned int]
>   at /home/ya-seen/workspace/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:151
>


what is this issue ? what am I doing wrong here ? Help, suggestions highly
appreciated

thanks in advance !!

Regards,
Mohamed Yaaseen