Hi Ihab
Exactly what we're saying!For frequency higher than 6 Ghz, a down converter can be used to over come this problem.
You might be wrong! As said, this is a hard task, and it's very hard to make things scale up on many CPUs, especially if there's dependence between data or steps - as is the case for anything decision aided, things like iterative decoders, long convolutional codes, etc.I think it can handle this rate. Please correct me if i'm Wrong.
If you successfully implement something that does this high-rate decoding on your CPUs alone, it'd definitely grab quite some attention from the SDR community.
You can! But they are special-purpose for DVB-T. They might or might not be appropriate for your application and your channel.
- There are (synchronizers, equalizers, channel codes etc) blocks in the gr-dvbt project why I cant use them?
Because Channel coding is what you do to get a good BER with limited SNR, and it is typically a trade-off between computational complexity, error recovery/detection performance and suitability for the type of symbol error combinations you're expecting.
- when you mentioned channel coding do you mean that i need to create a new one? and Why would I need it?
Sorry, I don't understand
- If i need BCH performance Why is difficult to achieve?
Start small! Have you been through the GNU Radio tutorials on http://tutorials.gnuradio.org? If you feel comfortable after reading these, dive into adapting existing things (gr-dvbt is really a good choice), and find out where your transceiver BER bottlenecks and where your computational bottlenecks come from.
- 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?
Best regards,
Marcus
On 24.08.2016 16:12, Ihab Zine 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_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 20On-line CPU(s) list: 0-19Thread(s) per core: 2Core(s) per socket: 10Socket(s): 1NUMA node(s): 1Vendor ID: GenuineIntelCPU family: 6Model: 63Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHzStepping: 2CPU MHz: 1553.804CPU max MHz: 3300.0000CPU min MHz: 1200.0000BogoMIPS: 5197.32Virtualization: VT-xL1d cache: 32KL1i cache: 32KL2 cache: 256KL3 cache: 25600KNUMA 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?
RegardsIhab
On 23 August 2016 at 14:34, Ihab Zine <ihab.zine13@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.zine13@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.
ThanksIhab
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment