Wade, The following also fails using just 2 blocks and 2 attempts: host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS host_tx => Switchboard#1 => Switchboard#0 => host_rx // FAILURE (RX samples equal swapped I/Q of TX samples)
In addition to wanting to get this issue fixed, I also have a question about the best way to "reboot" the N310 which is what I need to do to fix the issue after it occurs. One way is to give the "reboot now" linux command. But, this takes a long time. Another way is to reprogram the FPGA image via uhd_image_loader. This is appreciably faster, but I'm thinking that this is not a great idea if the flash memory has a limited number of write cycles before failure. Is there another way to achieve a reboot other than these two? Rob On Fri, Dec 11, 2020 at 7:34 PM Rob Kossler <rkoss...@nd.edu> wrote: > AHA! I duplicated the issue with the Switchboard image. The way to > duplicate the issue is the run the following series of graphs: > host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS > host_tx => Switchboard#2 => Switchboard#3 => host_rx // SUCCESS > host_tx => Switchboard#0 => Switchboard#2 => host_rx // FAILURE (RX > samples equal swapped I/Q of TX samples) > Each of these 3 runs consists of running my application (similar to one of > the examples such as rfnoc_rx_to_file) such that the UHD object is > re-created each time. My guess is that you could use gnuradio to do it > instead. > > My working theory is that the problem is caused by the fact that the > Switchboard#2 input port was changed from being connected to the host in > test case 2 to then be connected to another RFNoC block in test case 3. > Or, I suppose it could be the output port on this block (same logic). > > If you want me to send you my FPGA image with the 4 Switchboard blocks, > let me know. > Rob > > > > On Fri, Dec 11, 2020 at 7:09 PM Rob Kossler <rkoss...@nd.edu> wrote: > >> Hi Wade, >> After thinking about it a bit, I would ignore the "negation" issue for >> now. This may be a byproduct of I/Q swapping related to my custom block. >> Rob >> >> On Fri, Dec 11, 2020 at 6:34 PM Rob Kossler <rkoss...@nd.edu> wrote: >> >>> Hi Wade, >>> Thanks for the info. I still do not know what's going on, but here are >>> a few updates: >>> >>> - I built a new N310 image with 4 switchboards (1x1) and 1 >>> splitstream (1x2) blocks in addition to the default blocks. All of the >>> additional blocks are connected to SEPs for dynamic linking. I tried my >>> best to get bad behavior using a chain of 1 to 4 switchboards, but I >>> could >>> not duplicate any I/Q swapping or negation issues. >>> - I went back to my custom image (that I described below) and found >>> different behavior today (sometimes things worked OK). So, this got me >>> to >>> thinking that I am somehow getting the FPGA in a bad state such that a >>> reboot (or FPGA re-flashing) fixes things. I have had some success with >>> re-booting and things working properly. But, I still do not have a true >>> handle on things and cannot adequately predict when things are going to >>> succeed or fail. >>> - One thing that has been constant is that I have never seen bad >>> behavior when I only have 1 block in my graph (no matter which block I >>> choose). Note that for all of my tests, the graph looks like this: >>> host_tx >>> => block_chain => host_rx, where block_chain is a sequential chain of 1 >>> or >>> more rfnoc blocks. >>> >>> I will send a follow up once I figure things out. >>> Rob >>> >>> >>> On Fri, Dec 11, 2020 at 6:22 PM Wade Fife <wade.f...@ettus.com> wrote: >>> >>>> Hi Rob, >>>> >>>> The SEPs do have the ability to swap I and Q. This is because on the >>>> host computer, I is usually in the lower bits and Q is in the upper bits of >>>> each 32-bit word, but in RFNoC, for historical reasons, I goes in the upper >>>> bits and Q in the lower bits. The software programs the IQ swapping when it >>>> sets up the graph. >>>> >>>> I assume you're using dynamic connections (through the crossbar) to >>>> control the number of FFTs the data is passed through, and not static >>>> connections? If that's the case then I wonder if software configures IQ >>>> swapping incorrectly in some configurations. I'll see if I can do some >>>> testing next week to confirm if it's working correctly. >>>> >>>> As for negation, I'm not aware of anywhere we do that off the top of my >>>> head. Is that behavior block dependent? I'll see if I can find anywhere >>>> this happens. >>>> >>>> Thanks, >>>> >>>> Wade >>>> >>>> On Thu, Dec 10, 2020 at 3:54 PM Rob Kossler via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> Hi, >>>>> I am encountering very strange behavior with a custom FPGA image >>>>> (N310). It appears that data streaming through SEPs can get swapped (I/Q) >>>>> and/or negated. Is anyone at Ettus aware of anything that could cause >>>>> this? Of course, the issue might be on my end, but I can't think of what >>>>> it might be given that all of my custom blocks work as expected in >>>>> isolation (if the block is the only block in graph). >>>>> >>>>> My custom image is the following: >>>>> >>>>> - default blocks of Radios, DDCs, DUCs (each 2x2 and statically >>>>> connected as in default image) >>>>> - custom blocks of two 1x1 windowed-fft blocks, two 1x1 vector-avg >>>>> blocks, and one 2x2 custom block. Note: each of these blocks is >>>>> connected >>>>> to its own SEP, so I can connect dynamically in any fashion. >>>>> >>>>> My test case is transmitting 8192 random samples from host to FFT >>>>> block and then optionally through a 2nd FFT block before back to host. In >>>>> the test case, the radios/DDCs/DUCs are not used. >>>>> >>>>> Here is what I observed: >>>>> >>>>> - If I only include 1 FFT block in my RFNoC graph, I get the >>>>> expected results (the output from the FPGA matches what I calculate in >>>>> Matlab for the FFT). This is true for either of the two FFT blocks. >>>>> - If I include both FFT blocks in series, I can only match the >>>>> FPGA output if I swap the I/Q values in between my Matlab FFTs. >>>>> - Note: that this issue is not FFT-related as I can also duplicate >>>>> this issue with the other blocks. >>>>> - If I use 3 blocks in series (each through SEP), I need to negate >>>>> certain data in order to get it to match the FPGA output >>>>> >>>>> My next step is likely to build a new image with Ettus-developed FIFOs >>>>> to prove that the data is getting swapped/negated when 2 or more are used >>>>> in series through SEPs. >>>>> >>>>> Let me know if you have any suggestions for other things to try. >>>>> >>>>> Rob >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> 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
