Re: [USRP-users] USRP's B210 sluggish start of transmission
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> 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 > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] C674 fail on B210 rev 4
Billy, On Fri, Sep 22, 2017 at 8:23 PM, Billy Jones via USRP-users < > usrp-users@lists.ettus.com> wrote: > snip > > I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed. I > > was using a 9V, 1.5A wall wart as the power supply and had the USB3 cable > > connected to my PC. > > > > Thanks, > > Billy It is possible that the cap failure is "just one of those things" but your comment about the 9V wall wart may be important. There are some pretty gross wall warts out there. Some even manage to produce not-very-good-almost-DC with lots of hash. Others have poor isolation between one of the output terminals and the input (mains) connection. The UL or CE tag on the case may just mean that Uncle Larry or Cousin Eddie signed their names to it. I long ago avoided the problem for my N200 (6V DC) with a very high quality DC/DC converter driven either by a not-so-portable battery or by a lab power supply. I often run my B210 from a 12V linear bench supply. I'm assuming your 9V wall wart was supposed to produce DC. It is likely a switcher. (Designing an affordable well regulated linear DC supply that can source 1.5A is hard if it has to stick to the wall socket.) Switchers are fine -- when they are well designed. In fact page 7/8 (the last page in the B200 drawing set) shows two very nicely designed switching converters to generate the 1.2 and 1.8 volt supplies for the FPGAs. Badly designed or cheaply made switching regulators, however, are noise generators, and not very good at that. They have spectral peaks all over the place, the spikes up and down in frequency, and they are dirty, wide, and rich in noxious harmonics. So, unless your 9V wall wart was particularly clean, you might try a good bench supply or a stout battery. You'll get a cleaner RF environment and may even save some wear-and-tear on the input filter caps. matt ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] USRP's B210 sluggish start of transmission
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
