Re: [Discuss-gnuradio] GNU Radio on different platforms.

[John Kent]

Hi Brian,

Thanks for your reply.

Brian Padalino wrote:
> In the general application of how it is generally used, I believe you
> are correct.  Basically the USRP will get the signal down to 1 sample
> per symbol, and the rest of the processing is done on the host side.
>
> It should be noted that the Python scripting language is NOT where all
> the work takes place.  The Python is strictly used to stitch the
> pieces together - all the heavy lifting is done in C++ underneath it
> all.
OK ... I did see some C++ files in the repository.
It sounds a bit like the wish interface on Tcl/Tk.
> A simpler way might just be to buy an MPEG PCI card to put into a PC,
> and just have that run.  Moreover, if there is a hardware encoder,
> there is usually a hardware decoder within the same card.
Yes ... I guess that would make more sense.

> By itself, it might be large enough - it has a good amount of block
> RAM and flops in there, but within the entire system I highly doubt
> it.  It's a little over 90% filled right now using the standard setup.
> You can slim it down if you take out a few RX chains, but I am not
> sure you could slim it down enough.
Are they using a NIOS processor for the USB interface by any chance ?

> I believe Matt is working on a USRP2 which will host a Xilinx Spartan3
> chip with embedded multipliers and all that snazzy jazz.  He has some
> files within the svn repository if you feel like taking a peek, but
> they are obviously under much construction.
>
>  http://gnuradio.org/trac/browser/gnuradio/branches/developers/matt/u2f
Ok ... Thanks ... I'll take a look at that ...
You could certainly do some more DSP stuff with a few multipliers if the 
Altera
device does not have them.

> The main differences between Altera and Xilinx targeting really is the
> use of the SRL16 blocks within streaming applications.  Memories seem
> to port over pretty easily, though Xilinx likes to use 16kbit sizes
> whereas Altera likes 4kbit sizes.
The Spartan 3 uses 16Kbit RAMs. It sounds like the Altera device more 
closely
resembles the Spartan 2.
I have not played with the SRL16 blocks, but it sounds like I should 
read up on them.

> Generally just retargeting for the new chip will be good enough
> between the two different architectures.
You'd have to be a little careful about not using SRL16, multipliers and 
so on
to make the design compatible.

> I believe the new USRP2 is supposed to have Gigabit ethernet instead
> of USB as a main interface.  This could allow for better chaining of
> systems together and possibly a pseudo-distributed model for how data
> gets transmitted back and forth.  The possibilities are endless!
Sounds very Groovy !

> Now, as a side note, it seems as if your main concern was transmission
> of HDTV signals over the air.  If you started with an MPEG source that
> you were working from, did the required interleaving and FEC encoding
> on the PC and just sent down the raw packet bits to the USRP over USB.
> If you wrote an 8-VSB modulator in Verilog for the FPGA (much easier
> than writing an MPEG encoder), then you would probably be in business
> for at least transmission of HDTV.
I'm not too sure if the interleaving and FEC need to be done on the PC
or in the FPGA. I've got no real preference on that, although I would have
thought it would off load some of the work by putting it into the FPGA.

All the FPGA code I have written so far has been in VHDL rather than 
Verilog.
I'm not sure there is really a big difference.

I have an ATV kit for the 1296 MHz band. It uses FM modulation rather 
than AM.
The 1296 MHz PA I bought was a linear Mitsubishi module.
I guess I would be looking to use a commercial Digital TV receiver to 
decode the
video, so it would have to be compatible with that.

We had a talk at the North East Radio Group a couple of years ago on 
digital TV
and the guy there talked about encoding the video stream on 1024 separate
carriers. It might have been for a repeater system transmitting on the same
frequency though. I'm a bit hazy on the details.
> On the RX side, much of the processing is done in any equalization of
> the waveform and getting samples to end up as bits through the FEC
> most likely (and can be proven by profiling the code).  If this is the
> case, you can probably write the equalizer to work within the FPGA and
> possibly even an FEC decoder.  This way, you are just transmitting
> back interleaved (and already decoded) packets back.  The host PC
> would then just have to deinterleave and send to the appropriate MPEG
> decoder.
To be honest ... I have to read up on interleaving. As I said ... I was not
really up on the framing of the video signal for Broadcast transmission.
I'd also have to read up on equalizer design. I remember studying
equalizers for digital transmission back in my under graduate course
25 years ago, but I must admit I'm a bit rusty on how to adapt the
delay co-efficients.
> I had thought about writing a modulator for the FPGA which would do
> simple constellation mappings given a number of bits per symbol and a
> look up table then sending it through a raised cosine filter then the
> interpolating CIC filter.  This could decrease the amount of traffic
> over USB and shift the processing over to the FPGA.
I remember doing a 4 x 4 QAM encoder for a design project in my
undergraduate engineering course too. It was not particularly hard.
Actually as I recall it handled a variety of constellations. Some of the
data bits were used for differential phase shift and some for amplitude
> I hope I have answered your questions.  It seems as if today was a big
> FPGA question day.  I'd be glad to try to answer any others if you had
> them, though my FPGA experience is relatively limited as well.
Yes ... the information was very useful. It gave me a few things to 
follow up on.

> Brian
>
> PS - Sorry for such a long and lengthy post!
Yes ... I was thinking my original post was a bit long :-)
Oh well ... that is what these list are for !

Thanks for your reply ... It's much appreciated.
Maybe I'll get back to you after I have read up a few Xilinx app notes 
on the topic.

John.

--
http://www.johnkent.com.au
http://members.optushome.com.au/jekent