Hi Brian,
Thanks for your reply.
Brian P. 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