Ryan, Tks a lot for your prompt reply this is the printout of running the usrp GNU C++ version 5.4.0 20160609; Maybe this requires some compilation flag? I am building usrp from source according to ettus guidelines using cmake and make
Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/ Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Carmichael, Ryan <ryan.carmich...@dynetics.com> Sent: Wednesday, September 16, 2020 3:01 PM To: Ilay Nissim <il...@netlinetech.com>; usrp-users@lists.ettus.com Subject: RE: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Ilay, I got this exact error. You probably have a GCC < 5.3.0 and need to upgrade. That fixed it for me. * Ryan From: USRP-users <usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>> On Behalf Of Ilay Nissim via USRP-users Sent: Wednesday, September 16, 2020 3:51 AM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: EXTERNAL: [USRP-users] FW: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544976986495&sdata=Iul4f0SHhcUGudp3jslywWRQeFrKvICrBXzLXaC%2FowU%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Ilay Nissim Sent: Wednesday, September 16, 2020 11:50 AM To: 'Michael Dickens' <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> Cc: 'Ettus Research Technical Support' <supp...@ettus.com<mailto:supp...@ettus.com>>; Neel Pandeya (neel.pand...@ettus.com<mailto:neel.pand...@ettus.com>) <neel.pand...@ettus.com<mailto:neel.pand...@ettus.com>>; sam.rei...@ettus.com<mailto:sam.rei...@ettus.com> Subject: RE: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi trying to upgrade to uhd v4.0 /home/gig/uhd/host/lib/cal/database.cpp:200:2: error: converting to ‘std::tuple<uhd::usrp::cal::source, bool (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&), std::vector<unsigned char, std::allocator<unsigned char> > (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)>’ from initializer list would use explicit constructor ‘constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&& ...) [with _UElements = {uhd::usrp::cal::source, bool (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&), std::vector<unsigned char, std::allocator<unsigned char> > (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)}; <template-parameter-2-2> = void; _Elements = {uhd::usrp::cal::source, bool (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&), std::vector<unsigned char, std::allocator<unsigned char> > (*)(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)}]’ }}; ^ Reading through the forums it seems to be a c++ 14 issue, Do you have a way to pass this, or how to update the enviromate? Cmake also need to be upgraded to 3.8 I am using ubuntu 16.04 Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544976996496&sdata=PY1oWvumZy8VPtsovGZt1eCuq9Qrffz%2Fh26HmMg0cm0%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Ilay Nissim Sent: Thursday, September 10, 2020 8:59 AM To: 'Michael Dickens' <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> Cc: Ettus Research Technical Support <supp...@ettus.com<mailto:supp...@ettus.com>> Subject: RE: x310 gpsdo get_time_now() - uhd 3.14.0 bug? . Is your issue still relevant? Yes- 3.14.1 is the solution. But I would prefer 3.15. I need to mention that I do change frequencies and rates so I kill the rxstreamer each time }}} ==> You should not need to kill the rxstreamer to change frequencies. * I need to kill rxstreamer to change rates : You should also be able to kill and recreate streamers * On uhd 3.15 if you do it 256 times you get stuck < https://github.com/EttusResearch/uhd/issues/275<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEttusResearch%2Fuhd%2Fissues%2F275&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544976996496&sdata=NTCt5YybBJzcoL1MBQ0S5tBlaPplrIRrysC6DKs8xr0%3D&reserved=0> > ... looks like it is so. Looks internally like the issue was dropped for no apparent reason. * This is an isuue I opened, the issue is very much like this but only on version 3.15 Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977006494&sdata=BT4CScmbLVkFi4EkmXh9HARkp8f6ZPgH5xY9e0SQpfc%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Michael Dickens <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> Sent: Wednesday, September 9, 2020 5:37 PM To: Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> Cc: Ettus Research Technical Support <supp...@ettus.com<mailto:supp...@ettus.com>> Subject: Re: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi Ilay - Sorry for the very late reply; your email thread got lost in the support email noise. Is your issue still relevant? If so, are there any updates from your end that would be useful for me to know? Is this UHD issue 275 < https://github.com/EttusResearch/uhd/issues/275<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEttusResearch%2Fuhd%2Fissues%2F275&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977016484&sdata=ZMsnOEgHtJmJeqjYRvqZj%2Bc%2B%2Bg5Facj9OR%2BYMxCk9qQ%3D&reserved=0> > ... looks like it is so. Looks internally like the issue was dropped for no apparent reason. No problems on not being able to provide code; I'll do what I can on my end to replicate the issue, assuming you're still working on it -- after reviewing this whole email chain, since it's stale in my memory. You noted this in a past email: {{{ I need to mention that I do change frequencies and rates so I kill the rxstreamer each time }}} ==> You should not need to kill the rxstreamer to change frequencies. The UHD USRP objects should be able to change frequencies during runtime without being destroyed and recreated. THAT SAID: You should also be able to kill and recreate streamers as you note ... I'd expect eventually this will lead to issues for various reasons, but it should be doable ... it's just not how we recommend doing these things. Cheers! - MLD --- Dr Michael L Dickens Principal RF Applications Engineer Ettus Research Technical Support Email: supp...@ettus.com<mailto:supp...@ettus.com> Web: https://ettus.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fettus.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977016484&sdata=bEHj15X2jthUCEmNZv7t4uBSlbogLEjFxpHk0hlYnc4%3D&reserved=0> On Wed, Jul 8, 2020 at 4:25 AM Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> wrote: Hi Michael I found a another post saying how to reproduce it ---------- Forwarded message --------- From: Canadian Centre for Experimental Radio Astronomy <notificati...@github.com<mailto:notificati...@github.com>> Date: Tue, 21 Apr 2020 at 00:21 Subject: Re: [EttusResearch/uhd] unrecoverable Code crash x310, Fpga exceptio while rx capture - uhd 3.15.0 - IOError: Block ctrl (CE_01_Port_40) no response packet - (#321) To: EttusResearch/uhd <u...@noreply.github.com<mailto:u...@noreply.github.com>> Cc: ilayni <ilayor...@gmail.com<mailto:ilayor...@gmail.com>>, Author <aut...@noreply.github.com<mailto:aut...@noreply.github.com>> http://www.ccera.ca/files/rx_multi_samples.cpp<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ccera.ca%2Ffiles%2Frx_multi_samples.cpp&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977026480&sdata=TRLcN%2BDc4GwQ5wMgrMvSDunGkCaYeHAR5eQcnamc018%3D&reserved=0> easily reproduces this issue -- this is a variant of the standard version that takes an --iters parameter. I've found that the number of iterations required isn't consistent. But what IS necessary is that the number of channels requested needs to be varying between streaming sessions. If the channel count remains fixed, it will run to completion every time. Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977036476&sdata=GFLvEhPXB2Qe7PHwTLUFRsopWWlpvPM8Nb9NFTPZ0bU%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Michael Dickens <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> Sent: Wednesday, June 24, 2020 6:39 PM To: Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> Cc: Ettus Research Technical Support <supp...@ettus.com<mailto:supp...@ettus.com>> Subject: Re: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi Ilay - OK; so this sounds like an issue introduced into UHD between 3.14.1 and 3.15. Since 3.14.1 works for you, stick with it until there's a new UHD 3.15 release with the fix .. whatever & whenever it might be. I will try to do some testing to reproduce & verify the issue ... any code you can provide will greatly help expedite the process! - MLD --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com<mailto:supp...@ettus.com> Web: https://ettus.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fettus.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977036476&sdata=F0Bfx%2BX9fchqV13oGS%2B9JP0XP5NkhoenPJLoZS%2Fc%2Bjo%3D&reserved=0> On Wed, Jun 24, 2020 at 5:00 AM Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> wrote: Hi Michael Tks for the willingness to help I already answered most of those questions a few time. Shortly I would say my estimate this is not a networking issue due to cable, but due to cpu load I run the cores at 4.3 GHZ fix freq on ubuntu, but system is loaded. The system is working ok with 3.14.1 In 3.15 Since I switch bw on each sample you have an issue which I also detailed in previous mails that after 256 switches The system crashes. About the IO_ERROR. It usually happens more often when I use timed command. This is why I changed DSP_POLICY to MANUAL (see previous mails) My main concern about uhd that if I am late for some reason to reading the data the error is Irrecoverable meaning I would have to power up the usrp This is ofcourse unacceptable for a product. Hopes that helps If you want to reproduce write a continuously capturing 4 channels at 25Mhz with timed cmd In a while loop capture 650ms continuously. than switch some other bw say 20Mhz than back to 25Mhz and so on. Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977046473&sdata=LmK8kK7wUmo6PHROSk3UH7ylJ3hu0O0LpcJwBXg3xuY%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: Michael Dickens <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> Sent: Tuesday, June 23, 2020 7:03 PM To: Ettus Research Technical Support <supp...@ettus.com<mailto:supp...@ettus.com>> Cc: Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> Subject: Re: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi Ilay - OK so the error you note means that there is a networking issue. Since you are using an X310, this means that there is something going on in the networking between it and your host computer. The X310 has 2x SFP+ ports only -- no 1Gb ENET -- so something is either misconfigured or not totally working on the networking side. I've used the Intel X520-DA2 and it works fine on my host setup, though admittedly mine is pretty cutting edge hardware and the OS is Ubuntu 20.04. Thus, more questions: * How are the USRP and host computer connected? 1x SFP+ or 1x? DAC -> ENET -> DAC or just DAC -> DAC? Direct connect or through a switch? * What OS & version are you using on the host computer? * How is UHD installed on your host computer ... from source? From some pre-built package manager? * Have you set up "performance tuning" on your host computer -- for example setting all CPU cores to max core speed regardless of actual demand / usage? Anything special you can think of here? * Have you tried running the UHD utility/example "benchmark_rate" to test the raw RX capabilities of the setup? For most Linux, this utility is at "/usr/local/lib/uhd/examples". Hopefully the options are self-explanatory. * You note you tried UHD 3.15 and it didn't help. Did you experience the same issues as with UHD 3.14? You could have come upon a bug that's present in both, and so it would be worth pursuing here. * Do you have any code you can pass on for me to test? I can replicate your X310 + 2xTwinRX, and my host computer is compatible with yours. Even better is finding a stock UHD utility or example that shows this issue. Either way, the best way forward is for me to do local testing to verify that I see the issue too (or not), and then escalate to Ettus R&D. Cheers! - MLD --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com<mailto:supp...@ettus.com> Web: https://ettus.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fettus.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977056466&sdata=8IoCD8w4MtvIEhIGBzbcK2D84o0KMgGQq34GfbNCnxI%3D&reserved=0> On Thu, Jun 18, 2020 at 10:44 AM Ettus Research Technical Support <supp...@ettus.com<mailto:supp...@ettus.com>> wrote: Hi Ilay - I'm adding my personal Ettus email here; I'll reply from there. Please keep Ettus support on CC. - MLD On Thu, Jun 18, 2020 at 1:27 AM Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> wrote: Hi Michael, I was hoping this will be solved with 3.15 but it isn’t This error requires powerup of the usrp I have also opened issues about it in the uhd git reposiroty with all the details I am working with x310, 4 channels, timed cmd which seems to triger this issue I am changing rx freq and and the bw every 1-2 seconds The error I get uhd 3.15.0 Exception EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet - AssertionError: bool(buff) in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t = long unsigned int] at /home/gig/uhd/host/lib/rfnoc/ctrl_iface.cpp:151 while this doesn’t require power recycle I still don’t know how to recover I need to mention that I do change frequencies and rates so I kill the rxstreamer each time 3a. What PC hardware you're using LR: PC with core i7 intel (8700) 32GB memory 3b. What USRP hardware you are using (all motherboards and daughterboards involved) LR : USRPx310 (S/N: 316FCFB) with the 2 x TwinRX modules (S/N 317CB66 , 317CB68) 3c. How your USRPs are interfaced with your PC (PCIe, single/dual 10GbE links, etc.) LR : 10GbE link through - Ethernet Server Adapter X520-DA1/X520-DA2 Intel Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977056466&sdata=v1HD%2BYXRaC2DIkTA8B5LKgw7Yg0TKVPucRu39aElF8Q%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: michael.dick...@ettus.com<mailto:michael.dick...@ettus.com> <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> On Behalf Of Ettus Research Technical Support Sent: Wednesday, June 17, 2020 8:31 PM To: Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> Subject: Re: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi Ilay - OK; let's start this process again. Yes if you can provide details (again) that would be best. Can you explain why "ver 3.15 doesn't work"? UHD 3.15 has a lot of fixes from 3.14; if possible we highly recommend moving to it. - MLD --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com<mailto:supp...@ettus.com> Web: https://ettus.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fettus.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977066465&sdata=nEJCyT3jQBCe2R%2BOexj6TRqzvBhjc5ON7%2BYYWdX8dZo%3D&reserved=0> On Wed, Jun 17, 2020 at 1:01 PM Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> wrote: Hi Michael Yes is still an issue Please read back on the mail The issue is working with time cmd and x310 with 4 synced channels ver 3.15 doesn’t work if you cant catch up on the mail let me know and I will send you more details or schedule a call. Regards, Ilay Nissim RT Embedded Team Leader Netline Communications Technologies Ltd Tel: + (972) 36068171<tel:+972%203-606-8161> Fax: + (972) 36068101<tel:+972%203-606-8101> http://www.netlinetech.com/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netlinetech.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977076459&sdata=XPQbkvoaALVQTXwIaO09iqcGOjKd0Qdp7Kf%2BrmJa9Xc%3D&reserved=0> Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL From: michael.dick...@ettus.com<mailto:michael.dick...@ettus.com> <michael.dick...@ettus.com<mailto:michael.dick...@ettus.com>> On Behalf Of Ettus Research Technical Support Sent: Wednesday, June 17, 2020 7:21 PM To: Ilay Nissim <il...@netlinetech.com<mailto:il...@netlinetech.com>> Subject: Re: x310 gpsdo get_time_now() - uhd 3.14.0 bug? Hi Ilay - Sorry for the long delay; Sam left the company a while back and we're finally getting to his backlog of support queries. Is this still an issue for you, whatever the issue was? If so, please provide us an update on your latest efforts and we'll do what we can to help. - MLD --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com<mailto:supp...@ettus.com> Web: https://ettus.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fettus.com%2F&data=02%7C01%7CIlayn%40netlinetech.com%7Cbbc1d3518edf447b14e108d85a384208%7Cc8305e2ced754c6eb53e8ba0db504e52%7C0%7C0%7C637358544977076459&sdata=nD6SCv7vnWmfMrNWEN1Dc7KGVmIE0GAgS6dWo50sF4M%3D&reserved=0> ________________________________ The information contained in this message, and any attachments, may contain privileged and/or proprietary information that is intended solely for the person or entity to which it is addressed. Moreover, it may contain export restricted technical data controlled by Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR). Any review, retransmission, dissemination, or re-export to foreign or domestic entities by anyone other than the intended recipient in accordance with EAR and/or ITAR regulations is prohibited.
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
