Hi Ihab, that's great!!
So, I see that others already pointed out the very handy htop / top utilities, which can give you a rough idea of where the CPU is spent within the blink of an eye, as well as the far more involved, but also far more detailed controlport approach that can also tell you exactly where your sample flow is uneven or even stalling. On an algorithmic level, have a look at "perf", which is an awesome tool that actually measures how much time is spent in individual C/C++ functions. It takes a bit of experience (read: trial and error) till you get the "perf report" to show exactly what you want to know, but often, this information really points out which function needs to be optimized. I can't find a post right now, but please go to the USRP-users and discuss-gnuradio mailing list archives and search for "perf report"; I'm pretty optimistic I wrote a usable guide for these once. Now, regarding "BER Bottlenecks": Where the computational bottlenecks were to be solved using software engineering, this is very much in the domain of communication engineering (and the fact that these two disciplines are so closely linked is one of the most exciting aspects of SDR, in my opinion :) ). That means you'll have to come up with a lot of hypotheses on where your transmission system can be optimized. You'd first of all, as you did, derive a boundary of what is possible (i.e. Shannon capacity), including all analog aspects that you can't change (transceiver noise figures/equiv. noise temperature); you'd do a bit of measuring to see whether maximum TX power is actually the optimum for RX SNR, or whether operating your TX amplifier at maximum power might lead to nonlinearities leading to self-interference. You'd analyze your typical channel – how flat is it, how deep does fading get? What is its coherency time, doppler spectrum? Does your equalizer reflect those facts? Can you reduce the amount of spectrum*time you dedicate to estimating the channel in favor of transmitting more bits, or do you need to spend more time on getting CSI in order to improve SNR post-equalizer? Then: do your packet lengths reflect your application's transmission needs well? Do they work good with your channel code? Is this a one-way system, or do you have the chance to ARQ? What's the ARQ/FEC-redundancy tradeoff? Contention Windows? So, that really gets very dependent on what you actually want to do with the link; notice that different wireless standards developed at the same time use vastly different technology based on the specifics of the channel and wireless system they're used for (e.g. DVB-S was developed around 2000–2005 and used 8PSK-32APSK with pretty long LDPCs, which reflects the properties of the satellite-ground channel and the high-latency-tolerant, large-block-size-tolerant receivers respectively, whereas 3G/UMTS-CDMA typically use things like much shorter turbo codes with rate=1/3, reflecting a completely different channel, and a lower tolerance for latency). Hope that points you in the right direction, Best regards, Marcus On 29.08.2016 15:46, Ihab Zine wrote: > Hi Marcus, > > I have been through the GNU RADIO tutorials , I also dived into > adapting gr-dvbt, and it worked for me. But how can i find out where > my transceiver BER bottlenecks and where my computational bottlenecks > come from? Is the a method or steps i can follow? I need some hints on > this. > > Best Regards > Ihab > > On 24 August 2016 at 15:12, Ihab Zine <ihab.zin...@gmail.com > <mailto:ihab.zin...@gmail.com>> wrote: > > Hi Ron and Marcus, > > For frequency higher than 6 Ghz, a down converter can be used to > over come this problem. > > for the data rate and bandwidth, the PC i'm using has the > following specifications: > > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 20 > On-line CPU(s) list: 0-19 > Thread(s) per core: 2 > Core(s) per socket: 10 > Socket(s): 1 > NUMA node(s): 1 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 63 > Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz > Stepping: 2 > CPU MHz: 1553.804 > CPU max MHz: 3300.0000 > CPU min MHz: 1200.0000 > BogoMIPS: 5197.32 > Virtualization: VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 25600K > NUMA node0 CPU(s): 0-19 > > I think it can handle this rate. Please correct me if i'm Wrong. > > i have other questions: > > * There are (synchronizers, equalizers, channel codes etc) > blocks in the gr-dvbt project why I cant use them? > * when you mentioned channel coding do you mean that i need to > create a new one? and Why would I need it? > * If i need BCH performance Why is difficult to achieve? > * if the data requirement is fine (CPU and etc), what is the > best way to start building the receiver? How can I figure out > the blocks That i need for this receiver? > > > Regards > Ihab > > > On 23 August 2016 at 14:34, Ihab Zine <ihab.zin...@gmail.com > <mailto:ihab.zin...@gmail.com>> wrote: > > Hi Ron, > > 1) Frequency range: 1.5 - 38 GHz > > 2) Bandwidth range : 2 - 56 MHz > > 3) Modulation : Qpsk - 256 QAM > > 4) Data rate range : 150Mbit/s - 326Mbit/s. > > 5) Error correction method : i thinks it is FEC. > > Ihab > > On 22 August 2016 at 12:33, Ihab Zine <ihab.zin...@gmail.com > <mailto:ihab.zin...@gmail.com>> wrote: > > Hi All, > > I'm working on a project using GnuRadio And USRP 205 mini, > i'm at the stage where i need to demodulate a microwave > link signal. > > Anyone has an experience with Microwave link or tried to > do something similar? Is it possiable to do it in > gnuradio? or is there another approaches to do it? > > I'd appreciate any information you could give me. > > Thanks > Ihab > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
