|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Is 100 Mbps PSK demodulation in GNU RADIO possible? (x310 HW) |
Date: | Fri, 14 Apr 2017 20:45:23 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
Dear Mehmeto, need to stress one thing, here: Your "assuming that the HW support such a speed" is kind of doing
the wrong thing – you need to make your software run fast enough
on your hardware, which very, very likely is too slow, and as far
as I can tell, that's a real challenge at these rates. The USRP
will happily flood your PC with 100MS/s or more – the hard thing
is keeping up with that. As Dan highlights, you might be able to do that with GNU
Radio blocks – there's no inherent limit on "how fast they can
go". The question is just: how well does your transceiver (mainly:
the decoder, synchronizer) work on general-purpose CPUs, and can
you maybe split it to make use of more processor parallelism
(especially when you go to the GPU); that's programming, and we
can't tell you how well you'll do with that. Those are really pretty general purpose blocks that make a few "typical" choices (a specific digital AGC, and for timing recovery, for example, they use a RRC filter in a PFB filterbank clock sync, and for frequency recovery, a FLL band edge approach). I don't think these fit your high-bandwidth case overly well. You'd probably not make the same assumptions! So, no, out of the box you can't simply click this together and let it run at these high rates; you'll have to dig a bit deeper into GNU Radio, and the DSP theory and possible optimizations within. Luckily, GNU Radio lends itself greatly to that: Start with 5 MS/s, so something like 2.5 Mbd, make it work with bare minimum functionality, e.g. without channel coding, framing. Identify the CPU hogs. Increase to 10 MS/s, 5 Mbd, experiment with alternatives for the different elements in the receiver chain. Maybe optimize something manually (write better code – much of GNU Radio is hand-optimized including custom assembler kernels (see VOLK), but far from all), move up again, to maybe 25 MS/s. Identify whether your choices regarding frequency and timing recovery still make sense, and so on. Add Channel Coding (you probably want that for a high-rate link, right?!), rinse, repeat. Identify components of your system where acceleration, be it your own code on the X310's FPGA, be it something on the GPU, be it a custom accelerator card, or be it by simple optimization of software, makes most sense. Don't forget that copying data to and from the GPU puts additional load on your system! It might be a good idea to consider your PC's bus layout. The point here really is that you're very much working on the edge of the bandwidths that PC-architecture buses can carry around, and will be doing a lot of more or less strictly sequential algorithms on millions of elements per second – it's hence always going to be a bit "custom" what you're doing (noone else knows the channel and desired ROCs you're working with as good as you!), and it's kind of hard to offer the "universally great" transceiver for that. Best regards, Marcus On 14.04.2017 20:16, Dan CaJacob wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |