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>: > Send USRP-users mailing list submissions to > 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 > > You can reach the person managing the list at > 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> > To: Jonathon Pendlum <jonathon.pend...@ettus.com> > Cc: usrp-users <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] RFNoc Testbench / EOB > Message-ID: > <CABsifTk8doL0VhOP+=OP9EPuXxPNqA0kuXmyM-s= > 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> > wrote: > > > Thanks! I will look at that example. > > > > Tim > > > > On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < > > 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> 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 > >>> 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> > To: USRP-users@lists.ettus.com > Subject: [USRP-users] e320 GPIO pinout > Message-ID: > < > 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> > To: Aaron Holtzman <aholt...@gmail.com> > Cc: Ettus Mail List <USRP-users@lists.ettus.com> > Subject: Re: [USRP-users] e320 GPIO pinout > Message-ID: > < > 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> 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 > > 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> > To: usrp-users@lists.ettus.com > Subject: [USRP-users] Overrun on USB vs Ethernet > Message-ID: > <CAJ4BvYETtM== > 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> > To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>, Remco > Vink <r.v...@opnt.nl> > Subject: Re: [USRP-users] Overrun on USB vs Ethernet > Message-ID: > < > 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> ?? > USRP-users <usrp-users-boun...@lists.ettus.com> > ?? ??: 2019? 8? 28? ??? ?? 4:00 > ?? ??: usrp-users@lists.ettus.com <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> > To: Timothy Kurp <timothy.k...@gmail.com> > Cc: usrp-users <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] RFNoc Testbench / EOB > Message-ID: > < > cal7q81vnqfzbhh3ivbrbkpbjoten2qwnp2ywcera+ut9koz...@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> > 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> > > wrote: > > > >> Thanks! I will look at that example. > >> > >> Tim > >> > >> On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < > >> 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> 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 > >>>> 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> > To: Jonathon Pendlum <jonathon.pend...@ettus.com> > Cc: usrp-users <usrp-users@lists.ettus.com> > Subject: Re: [USRP-users] RFNoc Testbench / EOB > Message-ID: > <CABsifT= > gitkqefu8++rxdtrqybucw_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> 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> > > 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> > >> wrote: > >> > >>> Thanks! I will look at that example. > >>> > >>> Tim > >>> > >>> On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < > >>> 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> 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 > >>>>> 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 > 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 <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
