Forum: GNU Radio Re: Advice on I/Q control using USRP

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Shaiful (Guest)
on 2007-04-11 15:01
(Received via mailing list)
Hi,

What is the expected delay if I do the I/Q processing
in the PC instead?

Do you have any simple example how to perform complex
I/Q processing for the path RX->FPGA->PC->TX.

Thanks,

Regards,
Shaiful

On Tue, Apr 10, 2007 at 10:22:35AM -0700, Shaiful
wrote:
> Hi,
>
> I want to control I/Q signal going through USRP by
the
> path of DEMOD->RX->FPGA->TX->MOD, quite similar to
> what have been done by Jon Jacky in the following
> presentation:
>
>
http://www.research.cornell.edu/KIC/events/MRFM200...
>
> The main different is that I'm going to use I/Q
signal
> from analogue DEMOD instead of doing the digital
> demodulation.
>
> I've been thinking about the easiest way on how to
> achieve this aim. Do I need to program the FPGA
using
> Verilog or can I just get away with higher level
> C++/Python code?
>
> How about the delay for the processing, is it
possible
> to get less than 1 us delay?

To achieve 1us delay, you'll need to keep all the
signal processing on
the FPGA.  We can't get to the host in back in that
time.

Eric

> Regards,
> Shaiful Hashim,
> Cardiff School of Engineering, UK



____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo!
Games.
http://videogames.yahoo.com/platform?platform=120121
Eric B. (Guest)
on 2007-04-11 19:15
(Received via mailing list)
On Wed, Apr 11, 2007 at 04:00:21AM -0700, Shaiful wrote:
> Hi,
>
> What is the expected delay if I do the I/Q processing
> in the PC instead?
>
> Do you have any simple example how to perform complex
> I/Q processing for the path RX->FPGA->PC->TX.

That's pretty much all we ever do.  Look at any of the examples
in gnuradio-examples/python

Eric
Shaiful (Guest)
on 2007-04-12 15:49
(Received via mailing list)
Hi,

Sorry, my mistake, I think for my application the
correct signal path is RX->FPGA->PC->FPGA->TX, because
I want to do the I/Q signal processing in the PC.
>From my survey, for this path the delay going to be
around 100 ms.

Presumably, I can get much better delay at around 1 us
if I want use another path, which is similar to MRFM,
RX->FPGA->TX, but I'll need to re-program the FPGA.

For the first approach may be I live with the delay by
doing some delay compensation inside the PC, since my
input signal is repetitive.  Personally, I'd prefer
this approach since I can re-use most of the codes
that has been written for GNU Radio and it is more
flexible as well.

For the latter approach, if I re-program the FPGA like
in MRFM application, can I still use the GNU Radio
codes and utility?  For example, I need to display the
transmitted signal on a Smith Chart using my PC.

Regards,
Shaiful

--- Eric B. <removed_email_address@domain.invalid> wrote:

> > I/Q processing for the path RX->FPGA->PC->TX.
>
> That's pretty much all we ever do.  Look at any of
> the examples
> in gnuradio-examples/python
>
> Eric
>




____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
Johnathan C. (Guest)
on 2007-04-12 20:52
(Received via mailing list)
Shaiful wrote:

> For the latter approach, if I re-program the FPGA like in MRFM
> application, can I still use the GNU Radio codes and utility?  For
> example, I need to display the transmitted signal on a Smith Chart
> using my PC.

Yes.  As long as you keep the receive buffer and related blocks of the
FPGA intact, you can still send data into a PC flowgraph and do
processing with it.

--
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
This topic is locked and can not be replied to.