Re: [Discuss-gnuradio] 8 bit usrp samples (My first verilog code)

[Berndt Josef Wulf]

G'day,

I've been following this thread with great interest.

The links below point to URLs listing the features of DVB-T USB2.0 stick 
products from various manufacturers. These devices are extremely small and 
according to the specifications it appears that they rely on the host's CPU 
processing power. It would be interesting to find out the kind of hardware 
they employ to achieve the acclaimed performance.

Technotrend
http://www.dvbshop.net/product_info.php?products_id=296
http://www.technotrend.de

Freecom
http://www.freecom.com/ecProduct_detail.asp?ID=2234&nr=25451&prodn=DVB%2DT+USB+Stick

Yuan
http://www.yuan.com.tw/en/products/vdo_pd300.html

Typhoon
http://www.typhoon.de/de/art.php?p=826&pv=3

cheerio Berndt

On Fri, 26 Aug 2005 06:10 am, Martin Dvh wrote:
>  >Steve Schear wrote:
> >
> > I was one of the original GnuRadio team (I found the Microtune products
> > in 2001) but have not been too active on the list in a while.
>
> Hi Steve,
>
> > This is
> > mostly due to my limited programming skills and application interest
> > being well ahead of the current HW/SW capabilities. Although the goal of
> > SDR is to use simple but fast HW and perform as much as possible of the
> > receiver and transmitter functions in the host there are many
> > interesting applications which are currently beyond what either the
> > USRP, the USB 2.0 or the host PC can perform.  Your recent work at
> > modifying the FPGA code has given me new hope.
> >
> > I would like to discuss whether it might be possible with the current
> > USRP or a newer generation version, not too different from the current
> > model, to perform demodulation and acquisition in the FPGA?  This could
> > be especially useful for TV (especially HDTV reception) or wideband data
> > communication.
>
> I have been thinking about this too.
> One of the things you probably want is fft and QAM demodulation and
> absolute value of a complex signal (for fast agc)  in hardware. This can
> certainly be done but you probable need a more advanced fpga and/or an
> additional dsp.
>
> The main things we are missing right now is fixed or floating point
> multiplication, division and addition. The easiest way do get these is
> using an fpga which has hardware multiplier blocks. You probably also want
> a bit larger fpga to get all functions in there. It is also possible to
> construct multiplier blocks in a normal fpga but you nee a very large one
> (larger then we currently have)
>
> The other way to do it is adding a seperate DSP chip.
> But then you also have to communicate with this DSP and this consumes pins
> on the fpga.
>
> There is still the possibility to use other ways of processing when the
> signal has already transferred from the usrp to the pc. I have been working
> on building processing blocks which run on the graphics card. The fragment
> programs running on current graphics cards have a huge floating point
> processing power. I have a working fir-filter running on my very simple gpu
> (nvidia fx 5700LE) which is already a few factors faster as my cpu (duron
> 800)
>
> The main bottlenecks here are:
> bandwidth from usrp to pc (max 32 MB/s)
> bandwidth from cpu to graphics memory (max 2 GB/s on AGP/PCI-express)
> bandwidth from graphics memory to fragment program. (6.4 to 30 GB/s)
> bandwidth from graphics memory to cpu. (max 133 MB/s on AGP, much higher on
> pci-express)
>
> Although the bandwidth from graphics memory to fragment program is quite
> high this is still the limiting factor for my card. When you implement
> things like fft or fir-filter on the gpu you need to access every sample
> many times and gpus' are not as good in using cache as cpu's are.
>
> One other problem with gpu's is that although they are very good at
> floating point processing, they can't do integer operations or bitwise
> operations (bit shifting, and, or xor)
>
> So my bet is on two ways of getting to realtime digital
> demodulation/modulation. 1 Use the current usrp hardware.
>    Do as much preprocessing as you can in the fpga (I don't think we can do
> much more then we currently do, but I will keep on looking for ways) do
> floating point stuff on the gpu (videocard)
>    do bit-operations on the cpu
>    do post-processing on the cpu/gpu or usrp
>
> 2 design a new usrp with an advanced fpga with more gates and fixed-point
> multipliers
>
> Mat has already been talking about plans to use a more advanced fpga for
> future usrps on what-the hack.
>
> > If these may be practical, I may even be interested in posting a bounty
> > to develop some of the general or applications specific HW, FW and SW
> > enhancements.
>
> Well this sounds really interesting. This would really motivate me.
>
> I currently am out of a job and would really like to keep working on
> gnuradio and hopefully find ways of making a little money out of it. But I
> better find these ways quickly because I am running out of money fast and
> might have to spend all of my time in the very near future in simple jobs
> like  cleaning or burger-flipping :(    (The economy in The Netherlands is
> in a recession right now)
>
> I am already working on the fw and sw and have been thinking about
> designing a new kind of usrp (or improving th ecurrent design) using a pci
> or pci-express or gbit ethernet interface and a more advanced fpga. I
> haven't really gotten started yet because this is quite a big project.
>
> Although I also think Mat and Eric deserve such a bounty for all the work
> they have done already and keep on doing.
>
>  > One of my applications is for a very high process gain,
>  > low data rate, satellite communication.  Another for GSM/CDMA mobile
>  > communication.
>
> Could you be a bit more specific.
> If it is low-data-rate it might even be possible to just implement it in
> software.
>
> Greetings,
> Martin
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

pgpRE2K7J6cf4.pgp
Description: PGP signature