Hi all, I'm trying to write an RFNoC application which generates very short bursts -- 20 samples or less -- which are then upsampled. I'm running into problems with the radio underflowing which I believe has to do with the DUC.
I can reduce the problem to the following -- create an RFNoC graph (UHD only, no gr-ettus) with a radio and a DUC. Wire the DUC to the radio and get a tx_streamer pointing to the DUC. Set the DUC to interp=1024. Start the streamer via calling the radio's set_tx_streamer(). Now send a packet to the DUC, a short one. Try 20 samples. You'll see a bunch of underflows come back, and if you set EOB then the radio will stop transmitting. (Incidentally, why is that? If I set EOB and the transmission results in an underflow, subsequent bursts won't transmit at all.) If I pull the radio out of the loop and gather the DUC output on the host, Wireshark shows I'm receiving a whole slew of length-88 packets. That's 20 samples after the 64-bit header. So, it looks to me like axi_rate_change inside the DUC isn't resizing the output packets, it's just sending out *lots of them* -- in this case, 1024 20-sample packets for every input packet. This doesn't make a whole lot of sense to me as it's inefficient, and I can fully believe the radio is underflowing while trying to swallow a whole mess of short packets at full radio rate. So: is this intended behavior, and is there anything I can do to change that behavior besides padding my bursts? Nick
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
