Hello Remco: There's probably a better way to do the job, but here's something that I can suggest:
What you need to do to find out the maximum sustainable rate of your program is feeding in dummy data to it. I don't know how do this without replacing the USRP input stream to a stream of samples read from a pre-recorded complex data (preferably stored in a tmpfs as a data file). Then you can add some kind of a counter to count number of samples that your program processes per a second to see the processing speed of your program. With that information, you can try optimising your software or upgrading your hardware to match the required processing rate. If that is a bit troublesome and if you are unsure whether your processing speed or the USB interface between the device and the PC is the main bottleneck, then you can perhaps try running benchmark_rate at a bit higher rate or a bit longer duration and see if any samples are dropped. If it does not drop any samples, then the processing speed (or the processing power) is probably the culprit. Regards, Kyeong Su Shin ________________________________ 보낸 사람: Remco Vink via USRP-users <usrp-users@lists.ettus.com> 대신 USRP-users <usrp-users-boun...@lists.ettus.com> 보낸 날짜: 2019년 8월 30일 금요일 오전 12:17 받는 사람: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> 제목: Re: [USRP-users] Overrun on USB vs Ethernet Thank you Kyeong for the input. I was able to find the "probe rate" in Gnuradio, but unfortunately my program is indeed not build in Gnuradio. Does anyone know of a way to achieve this by the use of C++ and the UHD Driver? Op wo 28 aug. 2019 om 18:00 schreef <usrp-users-requ...@lists.ettus.com<mailto:usrp-users-requ...@lists.ettus.com>>: Send USRP-users mailing list submissions to usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To subscribe or unsubscribe via the World Wide Web, visit http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com or, via email, send a message with subject or body 'help' to usrp-users-requ...@lists.ettus.com<mailto:usrp-users-requ...@lists.ettus.com> You can reach the person managing the list at usrp-users-ow...@lists.ettus.com<mailto:usrp-users-ow...@lists.ettus.com> When replying, please edit your Subject line so it is more specific than "Re: Contents of USRP-users digest..." Today's Topics: 1. Re: RFNoc Testbench / EOB (Timothy Kurp) 2. e320 GPIO pinout (Aaron Holtzman) 3. Re: e320 GPIO pinout (Robin Coxe) 4. Overrun on USB vs Ethernet (Remco Vink) 5. Re: Overrun on USB vs Ethernet (Kyeong Su Shin) 6. Re: RFNoc Testbench / EOB (Jonathon Pendlum) 7. Re: RFNoc Testbench / EOB (Timothy Kurp) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 Aug 2019 12:06:54 -0400 From: Timothy Kurp <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> To: Jonathon Pendlum <jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> Cc: usrp-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] RFNoc Testbench / EOB Message-ID: <CABsifTk8doL0VhOP+=OP9EPuXxPNqA0kuXmyM-s=b8cz9yy...@mail.gmail.com<mailto:b8cz9yy...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Hi Jon, This doesn't answer my question, perhaps I didn't convey the problem clearly. I am trying to test the case where TLAST occurs on an odd sample, at the same time as EOB. Push word provides access to tlast, but not EOB. To throw eob I need to use send() which takes in pkt.payload and pkt.header. I can manipulate eob in the metadata there. pkt.payload is of type cvita_payload_t, which is 64 bits wide. Send() will throw tlast at the end of the packet, which will always contain a multiple of 2 complex samples since the payload is defined at 64 bits. That is my problem. There is no way to throw eob and tlast on a packet that contains an odd number of i/q samples. Tim On Tue, Aug 27, 2019 at 12:21 AM Timothy Kurp <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> wrote: > Thanks! I will look at that example. > > Tim > > On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < > jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote: > >> Hi Tim, >> >> Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit >> sample by sample basis. Unfortunately, if you want to do sizes smaller than >> 32-bit, you'll need to write your own version of send()/recv() or >> push_word()/pull_word() from sim_rfnoc_lib.svh. >> >> Jonathon >> >> On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users < >> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: >> >>> Hey Users! >>> >>> I think this may be a possible deficiency in the test bench >>> architecture, or perhaps I just don't know how to instrument it properly. I >>> have a custom block that performs a 2:1 rate change roughly, performing >>> compression of the 16 bit I/Q from the radio down to a 16 bit word that is >>> compressed, I won't describe how. There is a corner case if EOB occurs when >>> there is an odd number of samples received from the radio. I have handled >>> this by using simple mode = 0, manipulating cvita header manually and >>> throwing tlast to make packets, with success. The noc block works, but I am >>> struggling with how to exercise the corner case in the testbench. >>> >>> From what I have seen, the testbench only allows for EOB to be >>> manipulated on sample counts that are a multiple of 2 (send() operates on >>> 64 bits, or 2 samples of 16 bit I/Q). We have looked at the source and >>> there doesn't seem to be an easy way to throw EOB/TLAST on odd samples.We >>> also think it is not guaranteed that this will never happen from the radio. >>> Thoughts? >>> >>> Tim >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190827/432a32e0/attachment-0001.html> ------------------------------ Message: 2 Date: Tue, 27 Aug 2019 15:47:32 -0400 From: Aaron Holtzman <aholt...@gmail.com<mailto:aholt...@gmail.com>> To: USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> Subject: [USRP-users] e320 GPIO pinout Message-ID: <caehvi8sp6fcxo83bnn-_f3p0yx_6kw6-1qmfti6ixweqtzl...@mail.gmail.com<mailto:caehvi8sp6fcxo83bnn-_f3p0yx_6kw6-1qmfti6ixweqtzl...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" The pinout for the e320 GPIO connector at https://files.ettus.com/manual/page_gpio_api.html does not indicate which pin is used for the return current. Is it pin 17 (non-mini HDMI) which HDMI uses for the single ended signal return? On a related note, will the schematics for e320 ever be released? Thanks. cheers, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190827/1d3175f3/attachment-0001.html> ------------------------------ Message: 3 Date: Tue, 27 Aug 2019 15:50:04 -0700 From: Robin Coxe <c...@quanttux.com<mailto:c...@quanttux.com>> To: Aaron Holtzman <aholt...@gmail.com<mailto:aholt...@gmail.com>> Cc: Ettus Mail List <USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>> Subject: Re: [USRP-users] e320 GPIO pinout Message-ID: <cakjydkluhxmpwmelawbamts7up0wjqenwmmxspo1_qbwa3o...@mail.gmail.com<mailto:cakjydkluhxmpwmelawbamts7up0wjqenwmmxspo1_qbwa3o...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" [image: e320_mini_hdmi.png] Here's the pinout of the E320 GPIO connector. Someone from Ettus Support (i.e., who is still employed by NI) will have to comment on when the E320 schematics will be available. On Tue, Aug 27, 2019 at 1:06 PM Aaron Holtzman via USRP-users < usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: > The pinout for the e320 GPIO connector at > https://files.ettus.com/manual/page_gpio_api.html does not indicate which > pin is used for the return current. Is it pin 17 (non-mini HDMI) which HDMI > uses for the single ended signal return? > > On a related note, will the schematics for e320 ever be released? > > Thanks. > > cheers, > Aaron > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190827/0e5bbef6/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: e320_mini_hdmi.png Type: image/png Size: 78640 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190827/0e5bbef6/attachment-0001.png> ------------------------------ Message: 4 Date: Wed, 28 Aug 2019 09:00:36 +0200 From: Remco Vink <r.v...@opnt.nl<mailto:r.v...@opnt.nl>> To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Overrun on USB vs Ethernet Message-ID: <CAJ4BvYETtM==u1nrfyjmetdykp6nnuk0b3ewamyj3ibkj-z...@mail.gmail.com<mailto:u1nrfyjmetdykp6nnuk0b3ewamyj3ibkj-z...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" All, I am experiencing some issues with overruns stopping the streamer of our USB B200 devices. Currently the computers in use are not the fastest in their kind, but I am wondering where the limitation is coming from. I haven't found a way to measure the throughput of the USB, so it might either be the USB controller or processor which is not fast enough to handle all the data. The benchmark_rate seems to run fine at the rx_rate the program is running on. If for instance I would to switch to a network based device and have the connection over ethernet, would this possibly fix the issue or would the processor or some other bottleneck still arise. Would like to hear your thoughts on this overrun and most likely bottleneck problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190828/ecd8ec60/attachment-0001.html> ------------------------------ Message: 5 Date: Wed, 28 Aug 2019 08:47:21 +0000 From: Kyeong Su Shin <kss...@postech.ac.kr<mailto:kss...@postech.ac.kr>> To: "usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>" <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>, Remco Vink <r.v...@opnt.nl<mailto:r.v...@opnt.nl>> Subject: Re: [USRP-users] Overrun on USB vs Ethernet Message-ID: <sl2p216mb0938126b83f61183b049d0fa93...@sl2p216mb0938.korp216.prod.outlook.com<mailto:sl2p216mb0938126b83f61183b049d0fa93...@sl2p216mb0938.korp216.prod.outlook.com>> Content-Type: text/plain; charset="euc-kr" Hello Remco: If benchmark_rate runs fine at the target rx rate, the processing speed of the CPU is probably the main bottleneck. If you want to test it further, you can check the "maximum throughput" of your software (maximum rx rate that your software can keep up). If your program is in GNU Radio, one thing that you can do is replacing the "USRP Source" to a file source with pre-recorded data (or maybe a random source, if the performance of your flow graph is not affected by the incoming data), and attaching a "Probe Rate" and a"Message Debug" right after that. If the processing rate, printed to stdout, is slower than the target sampling rate, then your your CPU is not keeping up. If it is keeping up, the problem could be caused by some other issues, including but not limited to two-clock issues, USB controller issues, and USB connection issues (faulty USB 3.0 connection; it does happen!). You should be able to do something similar even if your program is not in GNU Radio (I don't have directions for that, though). In my experience, Ethernet-based USRPs (like N200s and X300s) are indeed a bit better at this. However, if the bottleneck is caused by the software, then replacing the SDR board won't fix the problem. Regards, Kyeong Su Shin ________________________________ ?? ??: Remco Vink via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> ?? USRP-users <usrp-users-boun...@lists.ettus.com<mailto:usrp-users-boun...@lists.ettus.com>> ?? ??: 2019? 8? 28? ??? ?? 4:00 ?? ??: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> ??: [USRP-users] Overrun on USB vs Ethernet All, I am experiencing some issues with overruns stopping the streamer of our USB B200 devices. Currently the computers in use are not the fastest in their kind, but I am wondering where the limitation is coming from. I haven't found a way to measure the throughput of the USB, so it might either be the USB controller or processor which is not fast enough to handle all the data. The benchmark_rate seems to run fine at the rx_rate the program is running on. If for instance I would to switch to a network based device and have the connection over ethernet, would this possibly fix the issue or would the processor or some other bottleneck still arise. Would like to hear your thoughts on this overrun and most likely bottleneck problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190828/4642a81b/attachment-0001.html> ------------------------------ Message: 6 Date: Thu, 29 Aug 2019 00:23:13 +0900 From: Jonathon Pendlum <jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> To: Timothy Kurp <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> Cc: usrp-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] RFNoc Testbench / EOB Message-ID: <cal7q81vnqfzbhh3ivbrbkpbjoten2qwnp2ywcera+ut9koz...@mail.gmail.com<mailto:cal7q81vnqfzbhh3ivbrbkpbjoten2qwnp2ywcera%2but9koz...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Hi Tim, My mistake on my original reply, you should use push_pkt()/pull_pkt(). You provide the header to that function (along with the payload), which is how you will be able to set EOB and a packet size with an odd number of 16-bit samples. If you really dig into sim_rfnoc_lib.svh, sim_cvita_lib.svh, and noc_block_export_io.v, you'll see that push_pkt() interfaces with noc_shell not axi_wrapper. Even though cvita_payload_t is a 64-bit wide queue, the packet size in the header is what matters. You'll also need to remove or modify line 236 in push_pkt() in sim_cvita_lib.svh, as that assertion checks if the header's packet size is a multiple of 4 bytes. Jonathon On Wed, Aug 28, 2019 at 1:07 AM Timothy Kurp <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> wrote: > Hi Jon, > > This doesn't answer my question, perhaps I didn't convey the problem > clearly. I am trying to test the case where TLAST occurs on an odd sample, > at the same time as EOB. Push word provides access to tlast, but not EOB. > To throw eob I need to use send() which takes in pkt.payload and > pkt.header. I can manipulate eob in the metadata there. pkt.payload is of > type cvita_payload_t, which is 64 bits wide. Send() will throw tlast at the > end of the packet, which will always contain a multiple of 2 complex > samples since the payload is defined at 64 bits. That is my problem. There > is no way to throw eob and tlast on a packet that contains an odd number of > i/q samples. > > Tim > > On Tue, Aug 27, 2019 at 12:21 AM Timothy Kurp > <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> > wrote: > >> Thanks! I will look at that example. >> >> Tim >> >> On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < >> jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote: >> >>> Hi Tim, >>> >>> Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit >>> sample by sample basis. Unfortunately, if you want to do sizes smaller than >>> 32-bit, you'll need to write your own version of send()/recv() or >>> push_word()/pull_word() from sim_rfnoc_lib.svh. >>> >>> Jonathon >>> >>> On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users < >>> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: >>> >>>> Hey Users! >>>> >>>> I think this may be a possible deficiency in the test bench >>>> architecture, or perhaps I just don't know how to instrument it properly. I >>>> have a custom block that performs a 2:1 rate change roughly, performing >>>> compression of the 16 bit I/Q from the radio down to a 16 bit word that is >>>> compressed, I won't describe how. There is a corner case if EOB occurs when >>>> there is an odd number of samples received from the radio. I have handled >>>> this by using simple mode = 0, manipulating cvita header manually and >>>> throwing tlast to make packets, with success. The noc block works, but I am >>>> struggling with how to exercise the corner case in the testbench. >>>> >>>> From what I have seen, the testbench only allows for EOB to be >>>> manipulated on sample counts that are a multiple of 2 (send() operates on >>>> 64 bits, or 2 samples of 16 bit I/Q). We have looked at the source and >>>> there doesn't seem to be an easy way to throw EOB/TLAST on odd samples.We >>>> also think it is not guaranteed that this will never happen from the radio. >>>> Thoughts? >>>> >>>> Tim >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190829/4d443d30/attachment-0001.html> ------------------------------ Message: 7 Date: Wed, 28 Aug 2019 11:32:03 -0400 From: Timothy Kurp <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> To: Jonathon Pendlum <jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> Cc: usrp-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] RFNoc Testbench / EOB Message-ID: <CABsifT=gitkqefu8++rxdtrqybucw_uc-kbdq8dx8gib0oc...@mail.gmail.com<mailto:gitkqefu8%2b%2brxdtrqybucw_uc-kbdq8dx8gib0oc...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" That sounds like it will do it. Thanks! Tim On Wed, Aug 28, 2019 at 11:23 AM Jonathon Pendlum < jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote: > Hi Tim, > > My mistake on my original reply, you should use push_pkt()/pull_pkt(). You > provide the header to that function (along with the payload), which is how > you will be able to set EOB and a packet size with an odd number of 16-bit > samples. If you really dig into sim_rfnoc_lib.svh, sim_cvita_lib.svh, and > noc_block_export_io.v, you'll see that push_pkt() interfaces with noc_shell > not axi_wrapper. Even though cvita_payload_t is a 64-bit wide queue, the > packet size in the header is what matters. You'll also need to remove or > modify line 236 in push_pkt() in sim_cvita_lib.svh, as that assertion > checks if the header's packet size is a multiple of 4 bytes. > > Jonathon > > On Wed, Aug 28, 2019 at 1:07 AM Timothy Kurp > <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> > wrote: > >> Hi Jon, >> >> This doesn't answer my question, perhaps I didn't convey the problem >> clearly. I am trying to test the case where TLAST occurs on an odd sample, >> at the same time as EOB. Push word provides access to tlast, but not EOB. >> To throw eob I need to use send() which takes in pkt.payload and >> pkt.header. I can manipulate eob in the metadata there. pkt.payload is of >> type cvita_payload_t, which is 64 bits wide. Send() will throw tlast at the >> end of the packet, which will always contain a multiple of 2 complex >> samples since the payload is defined at 64 bits. That is my problem. There >> is no way to throw eob and tlast on a packet that contains an odd number of >> i/q samples. >> >> Tim >> >> On Tue, Aug 27, 2019 at 12:21 AM Timothy Kurp >> <timothy.k...@gmail.com<mailto:timothy.k...@gmail.com>> >> wrote: >> >>> Thanks! I will look at that example. >>> >>> Tim >>> >>> On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < >>> jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote: >>> >>>> Hi Tim, >>>> >>>> Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit >>>> sample by sample basis. Unfortunately, if you want to do sizes smaller than >>>> 32-bit, you'll need to write your own version of send()/recv() or >>>> push_word()/pull_word() from sim_rfnoc_lib.svh. >>>> >>>> Jonathon >>>> >>>> On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users < >>>> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: >>>> >>>>> Hey Users! >>>>> >>>>> I think this may be a possible deficiency in the test bench >>>>> architecture, or perhaps I just don't know how to instrument it properly. >>>>> I >>>>> have a custom block that performs a 2:1 rate change roughly, performing >>>>> compression of the 16 bit I/Q from the radio down to a 16 bit word that is >>>>> compressed, I won't describe how. There is a corner case if EOB occurs >>>>> when >>>>> there is an odd number of samples received from the radio. I have handled >>>>> this by using simple mode = 0, manipulating cvita header manually and >>>>> throwing tlast to make packets, with success. The noc block works, but I >>>>> am >>>>> struggling with how to exercise the corner case in the testbench. >>>>> >>>>> From what I have seen, the testbench only allows for EOB to be >>>>> manipulated on sample counts that are a multiple of 2 (send() operates on >>>>> 64 bits, or 2 samples of 16 bit I/Q). We have looked at the source and >>>>> there doesn't seem to be an easy way to throw EOB/TLAST on odd samples.We >>>>> also think it is not guaranteed that this will never happen from the >>>>> radio. >>>>> Thoughts? >>>>> >>>>> Tim >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190828/7473e877/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ------------------------------ End of USRP-users Digest, Vol 108, Issue 26 ******************************************* -- Met vriendelijke groet/With kind regards, Remco Vink OPNT B.V. | Time provisioning De Boelelaan 1081 | Gebouw W&N |1081 HV Amsterdam E: r.v...@opnt.nl <mailto:r.v...@opnt.nl> | www.opnt.nl<http://demo.altium.com/0a6ae56f2bc6e9fbbe>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
