On 6/15/07, John Kent <[EMAIL PROTECTED]> wrote:
I am an amateur radio enthusiast, and am interested in implementing Digital TV. I believe, reading the GNU Radio web site, that that was one of the motivations of some of the members here. I have seen some screen shots of HDTV receiver pictures on the web site, but browsing through the archives I could not see much in the way of IP for the FPGA or MPEG encoders and so on for the transmitter. The web site looked as though the USRP is just used as a decimating front end and that all the signal processing is done in the PC with Python scripts. I would imagine an MPEG encoder would not lend itself particularly well to a scripting language and would have to be implemented as hardware in the FPGA.
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.
I have a bit of an idea about how an MPEG encoder might work, but I am a bit foggy on how the data stream is encapsulated and transmitted. I recently attended an Avnet/Xilinx XFest seminar where they gave a talk about implementing video over ethernet, but their solution was to simply go out and buy an MPEG encoder core, which I thought was a bit rich. At least outside the price range of the average hobbyist.
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.
I understand most of the work here is on the USRP Ettus Research Altera board. Is the Altera device on the USRP large enough for an MPEG encoder ?
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.
I would like to use my existing Xilinx boards if possible. I have a Virtex4 FX12 board with high speed dual ADC and DAC P160 module and a XC3S1000 board which I thought might be large enough for the video encoder. I thought I could connect the boards together over ethernet and use one as the encoder and one as the transmitter. It's pretty much pie in the sky stuff at this stage, and the labor involved in designing the MPEG encoder may well dwarf the cost of the boards anyway.
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
If the IP is designed well it maybe possible to port it from Xilinx to Altera and vice versa. I think the only real difference is in the implementation of on chip memory although of course the hardware implementation would be different. I'm not sure if the USRP uses a processor, but that may be another consideration.
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. Generally just retargeting for the new chip will be good enough between the two different architectures.
The USRP uses USB as the interface. Has any though been given to connecting the boards over ethernet so multiple boards can communicate between themselves ?
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! 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. 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. 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 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. Brian PS - Sorry for such a long and lengthy post! _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
