Re: [Discuss-gnuradio] Synchronization within the same USRP
Sorry, right now i'm not using VM. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
So, are you running this in a VM or not? I'm confused even more right now? On 19.10.2016 17:24, Aldalbahi, Adel wrote: > At my work i have a second PC that has both Linux and windows, and was > reading about this > http://www.virten.net/2013/02/migrate-e1000-adapter-to-vmxnet3-with-linux-virtual-machines/. > I was trying to find the shortest path. Sorry for the confusion. > > > > ___ > 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
Re: [Discuss-gnuradio] Synchronization within the same USRP
At my work i have a second PC that has both Linux and windows, and was reading about this http://www.virten.net/2013/02/migrate-e1000-adapter-to-vmxnet3-with-linux-virtual-machines/. I was trying to find the shortest path. Sorry for the confusion. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
Wait, how does a VM come into play here? On 19.10.2016 17:11, Aldalbahi, Adel wrote: > Marcus, > > Thank you , I wasn't aware of this. There are lots of articles online > regarding this issue. Since this required changing the e1000e kernel > drive, any advice for the alternative choices? have seen ppl using > different drivers on top of VM but mine not a dual OS. > > Thanx again > > > ___ > 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
Re: [Discuss-gnuradio] Synchronization within the same USRP
Marcus, Thank you , I wasn't aware of this. There are lots of articles online regarding this issue. Since this required changing the e1000e kernel drive, any advice for the alternative choices? have seen ppl using different drivers on top of VM but mine not a dual OS. Thanx again ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
Hi! 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 f7d0 (32-bit, non-prefetchable) [size=128K] > Memory at f7d39000 (32-bit, non-prefetchable) [size=4K] > I/O ports at f080 [size=32] > Capabilities: > 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 :( > > Marcus, > 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, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) Subsystem: Dell Device 0577 Flags: bus master, fast devsel, latency 0 Capabilities: Kernel driver in use: ivb_uncore 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0577 Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at f780 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at [disabled] Capabilities: Kernel driver in use: i915 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell Device 0577 Flags: bus master, medium devsel, latency 0, IRQ 26 Memory at f7d2 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd 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 f7d0 (32-bit, non-prefetchable) [size=128K] Memory at f7d39000 (32-bit, non-prefetchable) [size=4K] I/O ports at f080 [size=32] Capabilities: Kernel driver in use: e1000e 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Dell Device 0577 Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at f7d38000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) Subsystem: Dell Device 0577 Flags: bus master, fast devsel, latency 0, IRQ 31 Memory at f7d3 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: f7c0-f7cf Prefetchable memory behind bridge: f000-f00f Capabilities: Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) Subsystem: Dell Device 0577 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at f7d37000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci 00:1f.0 ISA bridge: Intel Corporation Q77 Express Chipset LPC Controller (rev 04) Subsystem: Dell Device 0577 Flags: bus master, medium devsel, latency 0 Capabilities: Kernel driver in use: lpc_ich 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0]) Subsystem: Dell Device 0577 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 27 I/O ports at f0d0 [size=8] I/O ports at f0c0 [size=4] I/O ports at f0b0 [size=8] I/O ports at f0a0 [size=4] I/O ports at f060 [size=32] Memory at f7d36000 (32-bit, non-prefetchable) [size=2K] Capabilities: Kernel driver in use: ahci 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) Subsystem: Dell Device 0577 Flags: medium devsel, IRQ 10 Memory at f7d35000 (64-bit, non-prefetchable) [size=256] I/O ports at f040 [size=32] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: TP-LINK Technologies Co., Ltd. TG-3468 Gigabit PCI Express Network Adapter Flags: bus master, fast devsel, latency 0, IRQ 28 I/O ports at e000 [size=256] Memory at f7c0 (64-bit, non-prefetchable) [size=4K] Memory at f000 (64-bit, prefetchable) [size=16K] Capabilities: Kernel driver in use: r8169 Marcus, 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 a
Re: [Discuss-gnuradio] Synchronization within the same USRP
Can you share what "lspci -v" says? The output of ifconfig isn't helpful here. Anyway, a 0.0075 BER sounds reasonable, what's wrong with that? do the math on how many bits you need to receive incorrectly at the very beginning of your reception to get to that level within your observational window. Then, also, do the math for error probability for your modulation. Real-world transmissions are *never* perfect. That's why you have all the fancy receivers! Best regards, Marcus On 18.10.2016 21:43, Aldalbahi, Adel wrote: > Hello Marcus, > > PC is connected to USRP via 1G ethernet cable. Here is my NIC for > this specific setup: > > eth1 Link encap:Ethernet HWaddr 34:17:eb:a5:5a:f1 > inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 > inet6 addr: fe80::3617:ebff:fea5:5af1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:38828790 errors:0 dropped:0 overruns:0 frame:0 > TX packets:37442520 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:55487116438 (55.4 GB) TX bytes:45938732293 (45.9 GB) > Interrupt:20 Memory:f7d0-f7d2 > > > USRP add was changed to .3. One more thing to mention going back to > flow graph, the unpack k bits block if K set to 8 then i guess in this > case I'm comparing bit by bit since K was mentioned in document to > unpack bytes to bits according to the set k value. The BER gives > 0.0078 after changing K, bits per symbols and unpacked to packed while > bypassing the delay block. After simulating the same setup without the > USRP i found 0.0075 BER instead of zero!! since there was no error > introduced in the simulation. > > Any suggestion ? > > Thank you > > > ___ > 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
Re: [Discuss-gnuradio] Synchronization within the same USRP
Hello Marcus, PC is connected to USRP via 1G ethernet cable. Here is my NIC for this specific setup: eth1 Link encap:Ethernet HWaddr 34:17:eb:a5:5a:f1 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::3617:ebff:fea5:5af1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38828790 errors:0 dropped:0 overruns:0 frame:0 TX packets:37442520 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:55487116438 (55.4 GB) TX bytes:45938732293 (45.9 GB) Interrupt:20 Memory:f7d0-f7d2 USRP add was changed to .3. One more thing to mention going back to flow graph, the unpack k bits block if K set to 8 then i guess in this case I'm comparing bit by bit since K was mentioned in document to unpack bytes to bits according to the set k value. The BER gives 0.0078 after changing K, bits per symbols and unpacked to packed while bypassing the delay block. After simulating the same setup without the USRP i found 0.0075 BER instead of zero!! since there was no error introduced in the simulation. Any suggestion ? Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
"D" is much worse than an underrun, especially at such low sampling rates; it means "Dropped Network packet". Something is very very wrong with your networking. How are you connecting your USRP to your PC? What is your Network card? Best regards, Marcus On 18.10.2016 17:24, Aldalbahi, Adel wrote: > Hello Marcus, > > > Thank you again for your help last time. I'm using both LFTX > daughterboard and LFRX daughterboard 0-30 Mhz on top of the N210. Also > I reduced the sampling rate to a rate that the USRP can support. I > removed the throttle and the BER block reading was 0.112. To me 11% > lose considered high at distance of 10cm. I don't see any overrun sign > on the console but "D" and it fixed after assigning 200K sample rate. > i know the input for the modulation is packet and output of demod is > bytes to get bits I have to unpack them but and this what I did but > One more question is the input to the BER block equal? am I missing to > adjust important parameter? > > Thank you. > > > > > > > > > ___ > 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
Re: [Discuss-gnuradio] Synchronization within the same USRP
Hello Marcus, Thank you again for your help last time. I'm using both LFTX daughterboard and LFRX daughterboard 0-30 Mhz on top of the N210. Also I reduced the sampling rate to a rate that the USRP can support. I removed the throttle and the BER block reading was 0.112. To me 11% lose considered high at distance of 10cm. I don't see any overrun sign on the console but "D" and it fixed after assigning 200K sample rate. i know the input for the modulation is packet and output of demod is bytes to get bits I have to unpack them but and this what I did but One more question is the input to the BER block equal? am I missing to adjust important parameter? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
Hello Adel, first of all: *never* use throttle together with hardware; the console should have warned you about that! Even worse: The N210 does NOT support your sampling rate of 600kHz – and you will definitely have gotten a warning about that! So you will need to read your console! Then: I forgot whether you've already said that, but which daughterboard are you using (it's a bit hard to figure out our discussion if you just reply to the digests – if you can, go into the mailing list settings, and deativate the digest and instead get individual mails, to which you can directly respond. Much easier, in my opinion!). > The delay block helps for few seconds only. Well, the TX-RX delay will not magically be a full number of sampling periods; so you will always be relying on the timing correction abilities of the PSK demod block. But that's OK, that's why *every* communication system has some synchronization (and yours has it, too). The reason this is breaking is probably the throttle. Throttle blocks the sample flow for as long as necessary to achieve roughly the average sampling rate it's set to. It's only useful for simulation-only flowgraphs, and must never be used with hardware, because otherwise, your PC's clock will compete with your sampling hardware's clock, and that will at some point lead to underruns, and broken signal. Are you seeing "U"s on the console? > Also the BER output is not correct after adding the delay block > because once I move rx few cm from tx i get almost constant BER for > the distance after! and let me guess, the BER value then approaches 0.5 ? You change the TX->RX distance, thus changing the "in-flight" times of your signal. Best regards, Marcus On 17.10.2016 01:10, Aldalbahi, Adel wrote: > Hello Marcus, > > Thank you for the quick replay. Attached is the flow graph, more about > the channel is a visible light channel using a simple LED drive that > is connected to a DC bias and a photodetector at the receiving end. As > I mentioned earlier the communication is working fine > except that I do have delay which cause losing of sync. The delay > block helps for few seconds only. Also the BER output is not correct > after adding the delay block because once I move rx few cm from tx i > get almost constant BER for the distance after! > > Any help is very appreciated. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization within the same USRP
Dear Adel, well, it's hard to tell why you lose sync if you don't share your flow graph, what kind of channel you have, and an overall overview of your system. Anyway, synchronizers do work with stochastic properties of the receive signal. There's absolutely no 100% guarantee sync stays on forever; it's a stochastic thing that the communication engineer needs to optimize to work best with the signal and channel. Best regards, Marcus On 15.10.2016 05:36, Aldalbahi, Adel wrote: > > Dear All, > > I have been working with a single USRP N210 to measure BER using BER > Error block. The communication is working perfect and I can transmit > and receive. Also I can see the constellation points of 4PSK at the > receiver. One thing I was totally confused about is that how to > synchronize both tx and rx blocks using single usrp? I used polyphase > clock, equalizer, also costa loop but still I lose synchronization > after few seconds? is there is anyway or example I can look at to help > me solve this problem? since I know I have phase offsite because of > the channel but how to solve this ? How to solve the delay problem > between tx and rx? > > Thank you in advance. > > > > > ___ > 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
