[USRP-users] Adding my custom RX module inside the FPGA (USRP b205mini)

Varban Metodiev varban.metodiev at gmail.com
Sat Jan 4 07:58:02 EST 2020


Hi Marcus,

That's a bit unusual, but cool :) This is a curious community, so if
you have any references to the system and its motivations, I think
there might be interest :)
---> Well... I attached some pics that I managed to get from GNURadio. In
short, I multiply the 1/2 period of a sine wave with zeros in order to
create a pulse with a certain length (thus achieving PWM in base band).
Of course, using  square pulses is also possible, but with the sine waves
the spectrum looks denser without using any additional filters.

My motivations are the following:
1) Because there are quite a few cost efficient FPGA on the market
nowadays, instead of using enough sampling rate (according to the sampling
theorem), I try to set it to be as high as possible in order to scale the
resolution of the pulse (and being to carry more symbols, respectively).
2) I want to test it against the QAM - in case I get better SNR results
compared to 4/16QAM, this will be cool for my thesis. :D
3) I want to test the maximum symbol rate that I will manage to achieve -
that is why I strive to focus more on the FPGA part.
4) I also tested the "PWM"-idea over both I and Q channels on the USRP - I
achieved readable outputs. That means that the I/Q modulator has the
potential to serve as a multiplexer for this "modulation".


As a development hint: do implement
equivalent functionality for an unmodified USRP on your PC first, so
that you have a "known good" implementation to test against!
---> I have done some experiments with my custom module for GNURadio now.
But I will also try to (re)write it with the UHD framework - I think it is
much more flexible and has lower overall resource footprint.

See that `sample` output that is put into `sample_rx`, and the
`strobe_rx`? Those are the signals you're looking for!

You can simply add your module to radio_legacy.v and connect it to
these two signals.

Now, you can try to hook the output of your module to new_rx_framer
(which normally "consumes" sample_rx), but be aware that that framer is
meant for continuous operation as long as flow control tells it. So,
maybe for the beginning, you'd want to design your module to be
*synchronous*, e.g. by emitting "0" in the sample clock until actual
data is available.
---> Thanks for this, really! However, I didn't get the idea of the
"strobe" signal. Is it something telling "new sample arrived"? And if so,
can I attach my clock directly to it?

If anyone is keen on the idea, I can share my thesis written in (my broken)
German with the USRP community as soon as I finish it.

Thanks and regards,
Varban
[image: sym1_und2.PNG]
[image: sym7_und8.PNG]

On Fri, Jan 3, 2020 at 2:02 AM Marcus Müller <marcus.mueller at ettus.com>
wrote:

> Hi Varban,
>
> On Tue, 2019-12-31 at 21:27 +0200, Varban Metodiev wrote:
> > Hi Marcus,
> >
> > I am doing something like a PWM over radio. I need to measure the
> > length of the pulse that is being received. My Verilog module does
> > this and outputs a 16-bit variable that stores the samples count
> > present in my PWM pulse.
>
> That's a bit unusual, but cool :) This is a curious community, so if
> you have any references to the system and its motivations, I think
> there might be interest :)
>
> As a development hint: do implement
> equivalent functionality for an unmodified USRP on your PC first, so
> that you have a "known good" implementation to test against!
>
> > you can either get the DDC output
> > ---> That would be great (and enough at this point). May you please
> > help me where to attach my inputs and outputs (see the attached block
> > diagram - inputs width will be changed to 32 ot 64bit, of course).
>
> So, you'd usually find `ddc_chain` in radio_legacy.v:
>
> ddc_chain #(.BASE(SR_RX_DSP), .DSPNO(0), .WIDTH(24),
> .NEW_HB_DECIM(NEW_HB_DECIM), .DEVICE(DEVICE)) ddc_chain
>      (.clk(radio_clk), .rst(radio_rst), .clr(1'b0),
>       .set_stb(set_stb),.set_addr(set_addr),.set_data(set_data),
>       .rx_fe_i({rx_fe[31:16],8'd0}),.rx_fe_q({rx_fe[15:0],8'd0}),
>       .sample(sample_rx), .run(run_rx), .strobe(strobe_rx),
>       .debug(debug_ddc_chain) );
>
>
> See that `sample` output that is put into `sample_rx`, and the
> `strobe_rx`? Those are the signals you're looking for!
>
> You can simply add your module to radio_legacy.v and connect it to
> these two signals.
>
> Now, you can try to hook the output of your module to new_rx_framer
> (which normally "consumes" sample_rx), but be aware that that framer is
> meant for continuous operation as long as flow control tells it. So,
> maybe for the beginning, you'd want to design your module to be
> *synchronous*, e.g. by emitting "0" in the sample clock until actual
> data is available.
>
> > Additionally, how can I expose the register read/write over custom
> > UHD modification?
>
> In radio_legacy.v, there's a section called 'user_settings', that comes
> with example code :)
>
> >
> > what's the specific motivation to do things on the FPGA?
> > ---> At some point I would try to test my PWM approach at 50Msps
> > rates.
>
> Hm, I'm surprised that should work within the maximum sampling rate of
> 61.44 MS/s of the ADC, and it still sounds like it'd be sensible to do
> it in software (a simple state machine, after all), but I see where
> you're coming from!
>
> Best regards,
> Marcus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200104/6a620785/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sym1_und2.PNG
Type: image/png
Size: 61539 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200104/6a620785/attachment.PNG>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sym7_und8.PNG
Type: image/png
Size: 59873 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200104/6a620785/attachment-0001.PNG>


More information about the USRP-users mailing list