Nick,
I went back through the loopback tricks you sent and found that my at_reset parameter on the SR_RX_CTRL_OUTPUT_FORMAT settings register had not been switched to 0, so I have corrected that. and timestamping should now be disabled. I have been using rfnoc_rx_to_file as reference for making my own C++ example and it seems that the 'uhd::device3' class does not have the 'set_rx_streamer' function. As a result, I have been calling the function using the 'uhd::rfnoc::radio_ctrl' class to set the streamer and issue the stream command via 'radio_ctrl->set_rx_streamer(true, radio_chan)' 'radio_ctrl->set_tx_streamer(true, radio_chan)' 'radio_ctrl->issue_stream_cmd(stream_cmd)' Is that fine for activating and issuing the streamers or should I 'make()' my device using the 'uhd::usrp::multi_usrp' class instead? Thanks, Adam ________________________________ From: Nick Foster <bistrom...@gmail.com> Sent: Friday, February 23, 2018 2:16:19 PM To: Adam Kurisko Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] [E310 RFNoC] TX RX Loopback bypassing the ARM processor Have you verified timestamps are disabled? And have you issued a stream command to the RX as well as set_rx_streamer()? To be clear, I haven't tried E310 loopback with any UHD version later than the date of the article (4/22/17), but I don't believe significant changes have happened which would affect loopback since then (maybe someone from Ettus could chime in). I don't think you'll be able to run at full DSP clock rate -- set the device to stream at (say) 10Msps on RX and TX first and then increase it from there. send() and recv() are strictly functions to submit and receive data from the ARM (PS) to the FPGA (PL) and vice versa. They are not necessary for loopback. Nick On Fri, Feb 23, 2018 at 10:26 AM Adam Kurisko <adamk...@outlook.com<mailto:adamk...@outlook.com>> wrote: Hey Nick, Thanks for the quick reply. I have already disabled time stamping and initiated the streamers and it compiles and runs on my board, however when I run it the LEDs on the RX2 and TRX frontend do not light up, so I am lead to believe that it actually might not be streaming. Just for clarification, Do the 'uhd::tx_streamer::send()' and 'uhd::rx_streamer::recv()' functions route the signal to buffers on the ARM host or the fpga? I ask that because those functions seem to be the only way that I can get those LEDs on the frontend to light up signifying that the device is actually streaming. Thanks, Adam ________________________________ From: Nick Foster <bistrom...@gmail.com<mailto:bistrom...@gmail.com>> Sent: Friday, February 23, 2018 1:01:42 PM To: Adam Kurisko Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [E310 RFNoC] TX RX Loopback bypassing the ARM processor 1. yes 2. RFNoC I refer back to a post I wrote detailing loopback in the FPGA. It doesn't work "out of the box" but can be made to with minor modification. https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ If you haven't used RFNoC before you should probably take on the Getting Started guide first: https://kb.ettus.com/Getting_Started_with_RFNoC_Development Nick On Fri, Feb 23, 2018 at 9:28 AM Adam Kurisko via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: Hello all, I am trying to utilize the full performance of the E310 and it seems like the Arm processor is the bottleneck in this scenario. I know the AD9361 is wired straight into the fpga, so it would make sense that a strictly bare metal loopback is possible. Is it possible to stream data straight from RX to TX without sending or receiving from the host ARM processor? And if so, how would I do this? Please let me know. Thank you, Adam _______________________________________________ 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
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
