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/MRFM2006/pdfs/Jacky%20talk/jacky-talk.html
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
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
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. [email protected] 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/
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