Hi Dario, Of course I can try to use software workarounds duplicating functionality that doesn't work correctly in B210. But let's at least try to find an answer what might cause the problem. Then maybe let's try to estimate how hard it would be to make B210 behave better.
I know that B210 is low cost product (in comparison with other USRPs) and it's also low on a list of priorities in terms of support. But this settling time whenever there is start of burst or an underflow seems to be a symptom of a bigger problem. 300us can't be explained by the time to turn on amplifier. It might mean for example that every time there is start of transmission ad9361 chip is restarted. If yes it might be worth to fix this as UHD's burst mode might not be the only victim of this approach. Best Regards, Piotr Krysik W dniu 24.09.2017 o 05:56, Dario Fertonani pisze: > Hi Piotr, > > Because of the problem you described, and other similar limitations > for stop-and-go usage of the tx_streamer (I'm referring to the C++ UHD > API here), I suggest keeping the tx_streamer always on and just > feeding it with IQ zeros when you don't want to transmit anything. > This solution is a tradeoff: On the pro side the stop-and-go > transients will go away, while on the con side you won't get a > perfectly zero RF output when you feed IQ zeros (e.g., because of > carrier leakage and other RF effects). > > Best, > Dario > > On Sat, Sep 23, 2017 at 4:27 AM, Piotr Krysik via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hi all, > > I'm currently trying to find out how much USRPs B210 are capable of > doing in different tasks. > > One of these tasks is transmission of burst with use of UHD's > burst api. > To access it I have implemented a GNU Radio app that uses tx_time and > packet_len tags. > Particularly the application was configured to send bursts containing > complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is > 2ms, so there should be 0.5us of gap between bursts. > > The result of recording of this signal is shown on the attached > picture > and it is not what is expected: the gap is about 800us and the > length of > pulse is about 1.7ms. About 300us of signal is not transmitted at all. > > What it means is that it is problematic to send bursts with use of > burst > api. I can attach 300us of signal at the beginning of a burst but what > if there are two bursts in a row that are closer than 300us? One of my > aims is to add ability to transmit gsm bursts to gr-gsm. GSM > bursts are > spaced by 8.25us of guard periods... Probably I could find some other > workaround with use of hacks that probably will fail in specific > situations and the whole simplicity provided by burst api will go away > anyway. But I would prefer to not do that if it's possible. > > I checked on USRP X310 and everything is fine there - it starts to > transmit almost immediately. > > > Why does it take so long (and loss of 0.3ms of signal at the > beginning) > for USRP B210 to start transmit anything? > Do you know how to make it start transmit faster (100x faster > definitely > would make burst api in B210 much more usable). > > (UHD used for the test was 3.9.2, carrier frequency of the signal was > 940MHz) > > -- > Best Regards, > Piotr Krysik > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
