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 <ejkrei...@gmail.com> 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 <mdyaaseen1...@gmail.com>
> 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
>>    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
>>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to