[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Synchronization within the same USRP

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Synchronization within the same USRP
Date: Tue, 18 Oct 2016 23:12:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0


On 18.10.2016 23:00, Aldalbahi, Adel wrote:

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
    Subsystem: Dell Device 052c
    Flags: bus master, fast devsel, latency 0, IRQ 29
    Memory at f7d00000 (32-bit, non-prefetchable) [size=128K]
    Memory at f7d39000 (32-bit, non-prefetchable) [size=4K]
    I/O ports at f080 [size=32]
    Capabilities: <access denied>
    Kernel driver in use: e1000e

Uh-oh. You've got the only malfunctioning Intel gigabit ethernet controller known to mankind :( It is known to drop packets sometimes. You must use a different one :(

when I unplug the RX dautherboread from the  USRP or 
block the photodetector  and run the flow graph i get the same BER mentioned above i.e 0.007... how can this be possible even if there is nothing  at receiver to compare with?  I totally agree with you there is no perfect results in real world but I think the BER block should react at least when blocking path. do you still agree with me that there is something wrong with the flow graph and not the network?
No. The network is 100% broken when you see a single "D".

I don't know about the BER sink, this might be a separate issue, but as long as packets are dropped, every effort on your side to optimize transmission is in vain.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]