Right, I should have mentioned that high rates are very CPU-intense.
In fact, it's not seldom that getting 50MS/s into a PC and processed
occupies a single CPU core completely. After all, we're talking
about 1.6 Gb/s in pure samples, before they're even converted to
what likely is floating point, to be processed. The load that
handling the USB controller of your PC poses in this situation isn't
negligible. Doing something useful with the signal is a whole
different story, again.
I'd recommend you start with much lower rates, identify the
computational bottlenecks and then scale up, until you hit a
maximum, not start with 100s of data-megabits per second
immediately. Just to illustrate:
Assume you had a receiver that could use a single 3.6 GHz CPU core
on its own, and you'd want to do 180 Mb/s. That leaves you with 20
CPU cycles per bit (including filtering, sync and things like
channel decoders...); assuming (and you usually can't do that)
perfect multicore scalability, you can double the number of CPU
cycles to spend per bit by doubling the number of cores. Notice that
arithmetic CPU instructions often do not have a throughput of 1
instruction per CPU cycle – using SIMD is a must, here. Also, Memory
bandwidth quickly becomes critical; you want to design your receiver
in a manner that keeps as much data that'll be needed as close as
possible to the CPU registers, ie. very wisely fetch data from RAM,
avoiding any Cache thrashing.
So, yes, this is technically doable, but it's not easy to achieve
high rates.
Best regards,
Marcus
On 23.08.2016 16:15, Ron Economos
wrote:
Agree with all of Marcus' comments. However, the 150 to 326
Mbps requirement may be quite difficult. To put things in
perspective, my run of the mill 3 GHz E5-1607 Xeon x86 processor
can just barely decode 16QAM DVB-T at 16 Mbps. You'll probably
need a high-end CPU with as many cores as you can afford.
On the DVB-T receiver, the most amount of CPU cycles are spent
on the Viterbi decoder which is why I asked what the FEC is. If
you need LDPC/BCH, performance is even more difficult to
achieve.
Ron
On 08/23/2016 06:52 AM, Marcus Müller
wrote:
Hi Ihab,
1)
Frequency range: 1.5 - 38 GHz
since the B205 mini only goes up to 6 GHz, you're bound to
use an external mixer. The device you chose for that will
completely depend on your specific application's needs. Also
note that finding something that works as well at 1.5 GHz as
it does on 38 GHz is probably pretty expensive, so and finding
antennas that work across that range isn't trivial, either. So
I'd recommend that, at least for a first prototype, you
restrict yourself to a smaller frequency range. If you stay
below 6GHz, the B205 can do that on its own
2)
Bandwidth range : 2 - 56 MHz
The B205 mini can definitely dot 56 MHz of bandwidth; the
question is whether your PC can process them fast enough and
whether your USB3 controller can sustain these rates.
3)
Modulation : Qpsk - 256 QAM
Well, that's just a question of software that you'll write :)
4) Data
rate range : 150Mbit/s - 326Mbit/s.
That sounds doable, considering the only limit here is Shannon's
channel capacity and your ability to write good software
including synchronizers, equalizers, channel codes etc.
5) Error
correction method : i thinks it is FEC.
Most definitely you'd want some channel coding.
Best regards,
Marcus
On 23.08.2016 15:34, Ihab Zine
wrote:
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|