Re: [USRP-users] Input power limit for B2x0 series
I think (having gone through this before) that the real badness happens if you put -15 dBm in the front end *and* turn all the gain up to the maximum. Then some chip in the chain goes over its limit. Really though, with a real world system, over the air, I'd be shocked if you could blow up the front end. What you have to be careful about is when you cable it directly to a transmitter. Even USRP to USRP, I always use at least 30 dB of attenuation and preferably 60 dB, just to be safe. On Sat, Jul 8, 2017 at 4:04 AM Sivan Toledo via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, I am trying to understand the input-port limit of the B2X0 series, > which is specified as -15dBm in the User's Manual ( > http://files.ettus.com/manual/page_usrp_b200.html). > > The issue is that if I use external front-end components (masthead LNA and > a saw filter), it is difficult to limit power to -15dBm (limiting to a 0 or > single-digit dBm is possible with common limiters). > > Is the -15dBm the limit that will cause overload and distortion even on > the lowest gain setting, or is it a safely limit above which the unit may > get damanged? > > Looking at the schematics of the B210, the input if fed to a switch that > can sustain almost 1W, then through something that looks like a limiter > (U800 and U813), then through another switch, and then to the inputs of the > AD9361, which can tolerate up to 2.5dBm. So it's hard to see why anything > up to 2.5dBm will damage the B2x0, and assuming that U800 and U813 do have > some useful limiting function, maybe much more is safe. > > Can you please clarify? I am considering using B2x0 for an application > that may subject them to about 3dBm, maybe 3.5dBm (we use an LNA, followed > by a 6dBm-max limiter, then a SAW filter with an insertion loss around > 3dB), and I want to make sure that this is safe. > > Thanks, Sivan Toledo > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Input power limit for B2x0 series
If your LNA is pumping out at 1/4W, just add an attenuator inline near your
radio to bring your signal power down to safe levels - it won't hurt you in
any appreciable way since you've got a nice LNA upfront already.
On Sun, Jul 9, 2017 at 7:03 AM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Sivan,
>
> ah in that case, you'll probably be fine; NF would be (assuming all the
> limiter, the filter and a potential attenuator have a 0dB Noise Figure):
>
> $F_\text{total} = F_\text{LNA} +
> \frac{F_\text{AD936x}}{G_\text{LNA}G_\text{cable}G_\text{limiter}G_\text{filter}G_\text{attenuator}}$;
>
> The NF of the AD936x depends on the gain you use, and from rough memory
> varies between let's say 35 dB @0dB gain over 25 dB @25dB, to 15 dB @30dB
> to a final ca 5dB from 55dB onwards. Let's say we're in a strong-signal
> case and you operate the B2xx at 30dB gain, and guessing 9dB loss at 100m
> distance for the cable, and assuming the limiter is practically lossless,
> as well as a 6 dB attenuator
>
> $F_\text{total} = 10^{0.05} + \frac{10^{1.5}}{10^{1.7}\cdot 10^{-0.45}
> \cdot 1 \cdot 10^{-0.3} \cdot 10^{-0.6}}$;
>
> which amounts to
> $F_\text{total} = 10^{0.05} + {10^{1.5-1.7+0.45+0.3+0.6}}= 10^{0.05} +
> 10^{1.15}}\approx 11.5\text{ dB}$.
>
> Now, that doesn't read very impressive, but your mentioning of SAW filters
> might indicate that you're dealing with a narrowband signal, which might
> mean that with the oversampling-induced SNR gain you can effectively get a
> much nicer effective system temperature.
>
> Best regards,
> Marcus
>
>
> On 09.07.2017 11:37, Sivan Toledo wrote:
>
> Thanks Marcus!
>
> The 0dBm limit is much easier to work with than the -15. I indeed can add
> a 3 or 6dB attenuator to ensure that this is the case. Thanks a lot for the
> clarification regarding U800 and U813.
>
> I don't mind sharing the frequency band and the details of the receive
> chain.
>
> We operate at 434MHz, we use an LNA with a gain of 17dB and noise figure
> of 0.5dB, then a cable (up to 50m of LMR400), then a 6dBm limiter and a saw
> filter with about 3dB insertion loss. I guess that an attenuator will not
> have a dramatic influence on the noise figure.
>
> To Dan and others: The LNA is a high linearity LNA which automatically
> implies that it can generate a lot of power (about 1/4W); that's where my
> concern comes from.
>
> Sivan
>
>
> On Sun, Jul 9, 2017 at 11:55 AM, Marcus Müller via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Sivan,
>>
>> to add to what Dan already said: You're right, the -15 dBm limit is a bit
>> overzealous (though I really must stress it's better to be safe than sorry
>> on that side).
>>
>> We're actually in the process of relaxing the limits we're stating for
>> this; compare [1], where we already spec a maximum input power of 0dBm. Of
>> course, it's absolutely correct that the maximum input power is what we can
>> be sure that, even under maximum gain, will not lead to damage.
>>
>> Regarding U800/U813: these are ESD protection, not power limiter diodes!
>>
>> Now, at +0dBm power (and even more so at +3dBm), the signal will not be
>> distorted only on the very lowest gain settings. Consider adding a simple
>> attenuator; Friis' noise formulas contradict that (having attenuation (i.e.
>> reducing gain) should happen as late as possible in the signal chain to
>> minimize overall Noise Figure), but these assume amplifiers are still
>> linear, and you'd probably break that condition.
>>
>> If you could share the frequency bands you're working on (if preferable,
>> also in confidentiality directly with me), we can try to come up with a
>> NF-vs-gain and IIP3-vs-gain relationship that would help you choose the
>> optimal operating point.
>>
>> Best regards,
>>
>> Marcus
>>
>> [1] https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>
>> On 08.07.2017 10:03, Sivan Toledo via USRP-users wrote:
>>
>> Hi, I am trying to understand the input-port limit of the B2X0 series,
>> which is specified as -15dBm in the User's Manual (
>> http://files.ettus.com/manual/page_usrp_b200.html).
>>
>> The issue is that if I use external front-end components (masthead LNA
>> and a saw filter), it is difficult to limit power to -15dBm (limiting to a
>> 0 or single-digit dBm is possible with common limiters).
>>
>> Is the -15dBm the limit that will cause overload and distortion even on
>> the lowest gain setting, or is it a safely limit above which the unit may
>> get damanged?
>>
>> Looking at the schematics of the B210, the input if fed to a switch that
>> can sustain almost 1W, then through something that looks like a limiter
>> (U800 and U813), then through another switch, and then to the inputs of the
>> AD9361, which can tolerate up to 2.5dBm. So it's hard to see why anything
>> up to 2.5dBm will damage the B2x0, and assuming that U800 and U813 do have
>> some useful limiting function, maybe much more is safe.
>>
>> Can you please clarify? I am considerin
Re: [USRP-users] Input power limit for B2x0 series
I agree. When a B2XX has died for me, it's always this. On Wed, Jul 12, 2017 at 4:04 AM Ralph A. Schmid, dk5ras via USRP-users < usrp-users@lists.ettus.com> wrote: > About ESD protection, in my B210 the first switch U807 dies all the time; > these need some protection, too :) At the moment I have removed them... > > > > Ralph. > > > > *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf > Of *Marcus Müller via USRP-users > *Sent:* Sunday, July 9, 2017 10:56 AM > *To:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Input power limit for B2x0 series > > > > Hi Sivan, > > to add to what Dan already said: You're right, the -15 dBm limit is a bit > overzealous (though I really must stress it's better to be safe than sorry > on that side). > > We're actually in the process of relaxing the limits we're stating for > this; compare [1], where we already spec a maximum input power of 0dBm. Of > course, it's absolutely correct that the maximum input power is what we can > be sure that, even under maximum gain, will not lead to damage. > > Regarding U800/U813: these are ESD protection, not power limiter diodes! > > Now, at +0dBm power (and even more so at +3dBm), the signal will not be > distorted only on the very lowest gain settings. Consider adding a simple > attenuator; Friis' noise formulas contradict that (having attenuation (i.e. > reducing gain) should happen as late as possible in the signal chain to > minimize overall Noise Figure), but these assume amplifiers are still > linear, and you'd probably break that condition. > > If you could share the frequency bands you're working on (if preferable, > also in confidentiality directly with me), we can try to come up with a > NF-vs-gain and IIP3-vs-gain relationship that would help you choose the > optimal operating point. > > Best regards, > > Marcus > > [1] https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications > > > > On 08.07.2017 10:03, Sivan Toledo via USRP-users wrote: > > Hi, I am trying to understand the input-port limit of the B2X0 series, > which is specified as -15dBm in the User's Manual ( > http://files.ettus.com/manual/page_usrp_b200.html). > > > > The issue is that if I use external front-end components (masthead LNA and > a saw filter), it is difficult to limit power to -15dBm (limiting to a 0 or > single-digit dBm is possible with common limiters). > > > > Is the -15dBm the limit that will cause overload and distortion even on > the lowest gain setting, or is it a safely limit above which the unit may > get damanged? > > > > Looking at the schematics of the B210, the input if fed to a switch that > can sustain almost 1W, then through something that looks like a limiter > (U800 and U813), then through another switch, and then to the inputs of the > AD9361, which can tolerate up to 2.5dBm. So it's hard to see why anything > up to 2.5dBm will damage the B2x0, and assuming that U800 and U813 do have > some useful limiting function, maybe much more is safe. > > > > Can you please clarify? I am considering using B2x0 for an application > that may subject them to about 3dBm, maybe 3.5dBm (we use an LNA, followed > by a 6dBm-max limiter, then a SAW filter with an insertion loss around > 3dB), and I want to make sure that this is safe. > > > > Thanks, Sivan Toledo > > > > > > > ___ > > 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Redhawk SDR
I'd suggest installing GNURadio ;) On Sun, Jul 16, 2017 at 7:35 PM d.des via USRP-users < usrp-users@lists.ettus.com> wrote: > I know that this isn't a Redhawk forum but maybe someone here has a quick > pointer. Is there a step-by-step guide to making a simple recording using a > B210 and Redhawk 2.1.0? I'm running on a fresh Centos 7.2 installation, > which is one of their tested OS recomendations. None of the waveform > examples I've found include any RF sources and if I try to launch the > included rh.USRP_UHD device in the sandbox I get the cryptic: "...does not > provide EventChannelAccess, Event channel management is not allowed." The > UHD driver that came with the RH RPM installation work fine with the radio > outside of RH. > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Reducing USB Latency
Hi, I have a GnuRadio modem I've developed and I'd like to reduce latency. It does IP encapsulation and for testing, I use two USRPs to implement an OTA connection between the modems. I've reduced latency so far by 1) adding fill frames/bytes only at the very last block before the USRP sink and 2) increasing the sample rate to the device. This has gotten my slightly under 100 ms latency, which is good compared to what I started with, but I think we can do better. My assumption is that there is still some latency in the last buffer between the last block and the USRP sink and perhaps some in the USRP USB transport itself. I am using B200s in this case, BTW. I suspect that what I really must do is now tweak the usrp buffer params from here: https://files.ettus.com/manual/page_transport.html But, I have no idea what they are set to by default (any way to tell)? And some naive manipulation of them hasn't improved anything. I also tried tweaking the mx output buffer size on the last block before the USRP sink without any improvement. Any advice from Ettus folks would be appreciated :) I am giving a talk at GRCon that addresses the latency reduction work so far, so if we can get any more, I'll throw that in as well. - Dan -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Reducing USB Latency
Thanks for the advice, Michael! I'll do some profiling for sure. It's been a while, but my first diagnoses (which was very useful) was to use the gr performance monitoring tool to visually see the buffer fullness for each block in the fg. In a naive implementation, where I added "fill frames" early in the fg, you could "see" the scheduler fill the buffers of the blocks from the bottom (usrp sink) up, which is bad. The better implementation, which I have had for a while, adds the fill frames in the last block before the USRP sink, so the only remaining buffer ought to be between that block and the USRP sink plus any USB transport latency. The flow upstream of that is unfettered by buffer issues, but I can re-confirm this. I had made an attempt to reduce the last block buffer size, but saw no effect. I have not tried adjusting the USB transport parameters with the additional knowledge Ron and yourself have provided yet. To the general group: I'd be curious to hear what the lowest latency anyone has seen using GR and a USRP together has been, implementing some sort of packetized modem. On Mon, Aug 14, 2017 at 2:28 PM Michael West via USRP-users < usrp-users@lists.ettus.com> wrote: > Ron is correct about the defaults. > > USB 3.0 has a MTU of 1024 B on the bus and USB 2.0 has a MTU of 512 B, so > you might get something by reducing the send_frame_size to those values. I > recommend also increasing the num_send_frames to something like 256 if you > do. One thing to keep in mind is that smaller packets have lower latency > on the wire, but the overhead per transfer may negate that. > > My guess is that the latency on the transport is probably <1ms even with > the default settings so I'm sure other things will result in more of an > improvement. I recommend profiling your application to see where the > bottlenecks may be. > > My understanding is that each block in GnuRadio runs in a separate thread > and has buffering on the input and output. Minimizing the number of blocks > and the buffering in the blocks is where I would focus, but definitely > profile first to see where you should be looking. > > Regards, > Michael > > > On Sat, Aug 5, 2017 at 3:34 AM, Ron Economos via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I'm pretty sure the B200 defaults are: >> >> send_frame_size = 8192 >> >> num_send_frames = 16 >> >> >> https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L532 >> >> Ron >> On 08/05/2017 12:00 AM, Dan CaJacob via USRP-users wrote: >> >> Hi, >> >> I have a GnuRadio modem I've developed and I'd like to reduce latency. It >> does IP encapsulation and for testing, I use two USRPs to implement an OTA >> connection between the modems. >> >> I've reduced latency so far by 1) adding fill frames/bytes only at the >> very last block before the USRP sink and 2) increasing the sample rate to >> the device. This has gotten my slightly under 100 ms latency, which is good >> compared to what I started with, but I think we can do better. >> >> My assumption is that there is still some latency in the last buffer >> between the last block and the USRP sink and perhaps some in the USRP USB >> transport itself. I am using B200s in this case, BTW. >> >> I suspect that what I really must do is now tweak the usrp buffer params >> from here: https://files.ettus.com/manual/page_transport.html But, I >> have no idea what they are set to by default (any way to tell)? And some >> naive manipulation of them hasn't improved anything. >> >> I also tried tweaking the mx output buffer size on the last block before >> the USRP sink without any improvement. >> >> Any advice from Ettus folks would be appreciated :) I am giving a talk at >> GRCon that addresses the latency reduction work so far, so if we can get >> any more, I'll throw that in as well. >> >> - Dan >> -- >> Very Respectfully, >> >> Dan CaJacob >> >> >> ___ >> USRP-users mailing >> listUSRP-users@lists.ettus.comhttp://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 >> >> > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UHD dropping samples running on Debian 9
We use several NUC6i7KYK units without any issues. They run Ubuntu 17.04 On Fri, Sep 8, 2017 at 10:29 AM Meelis Nõmm via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), > installed Debian 9 on it and tested Gnuradio on it. At first we installed > via apt-get. We saw some drops in the gnuradio-companion and had issue with > setting the real-time priority, so we removed it from the system and > installed it again with pybombs. > However, no difference. Today tested it again with UHD provided benchmark > example (for easy reference). Saw occasional drops with Sps from 1e6 to > 10e6. Thought it might be a network driver issue, updated the Intel network > driver with the latest(?) e1000e driver. Still no difference. > > Any ideas, can we fix this somehow? > Thank you > Meelis > > Additional information is in the file attached, but most important system > parameters: > #system > Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) > #Network driver > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) > I219-LM (rev 31) > filename: > /lib/modules/4.9.0-3-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko > version:3.3.5.10-NAPI > > > $ ./benchmark_rate --rx_rate 10e6 --duration 300 > > [INFO] [UHDlinux; GNU C++ version 6.3.0 20170516; Boost_106200; > UHD_3.11.0.git-181-g8f9f4184] > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] 2011 Matt's Talk Materials
I am pretty sure those blocks all made it into GR core. Check the examples sections. On Mon, Oct 16, 2017 at 5:25 PM Sumit Kumar via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks Robin, I found the slides. However the talk which he gave in GRCon > 2011 was approx 3:30 hr long. > > Anyways do you also have the grc files used in the slides ! > > Thanks much > Sumit > > On Mon, Oct 16, 2017 at 11:21 PM, Robin Coxe wrote: > >> Matt gave this talk again at GR Con 2015 in Boulder. Slides here: >> https://drive.google.com/file/d/0B6ccrJyAZaq3UHpEQld1YmZjbWs/view >> >> On Mon, Oct 16, 2017 at 1:56 PM, Sumit Kumar via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hi, >>> >>> I was wondering if anyone has the materials for the famous talk by Matt >>> Ettus in 2011 GRCon. >>> >>> *"Why Doesn't My Signal Look Like the Textbook?"* >>> >>> I remember it was hosted on Tom's webpage. The link is still there, >>> however the files are missing. >>> >>> http://www.trondeau.com/grc2011-abstracts/ >>> >>> Go to the schedule of 15th September 9-9:30 >>> >>> Regards >>> >>> Sumit >>> >>> ___ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> > > > -- > -- > Sumit kumar > Doctoral Student, UPMC > Eurecom, BIOT > France > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] TX power levels. Long term exposure.
But if you want to have some fun with your co-workers. Put on a metal hat whenever you TX. If they ask what's going on, say "Don't worry about it" :) On Mon, Nov 6, 2017 at 4:49 PM Bakshi, Arjun via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks for clearing that up. > > > AB > -- > *From:* Nick Foster > *Sent:* Monday, November 6, 2017 3:58:05 PM > *To:* Bakshi, Arjun > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] TX power levels. Long term exposure. > > Don't worry about it. You are several orders of magnitude below any sort > of permissible exposure limit. > > Nick > > On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users < > usrp-users@lists.ettus.com> wrote: > > I'm looking to do long duration experiments in a lab which will have > people in it while I TX and Rx, and I'd like to know what health and safety > concerns I should keep in mind. > > > I tried looking at FCC and EU for limits on radiation levels, but those > specs aren't straightforward to understand. It's also difficult to get an > estimate of absolute power rxed/txed from the USRPs. So I'd like to hear > from anyone who knows about this stuff. > > > I'm using SBX (max power 100mW), and I'm thinking of using either the > 500-700MHz or the 1.2-1.3 GHz band. I'll be transmitting for *5ms every > second for a few hours*. The room is about 6m x 15m. Then antennas will > be 1-2 meters away from a few people. TX and RX are about 4m apart. With > gain set to 25dB, my signal has ~30dB SNR. > > > Sorry if this seems a bit odd/specific. > > > Thank you, > > > AB > > > ___ > 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] TX power levels. Long term exposure.
It's a joke :) On Tue, Nov 7, 2017 at 2:21 PM Kyeong Su Shin via USRP-users < usrp-users@lists.ettus.com> wrote: > It will act as a RF shield. (see: > https://en.wikipedia.org/wiki/Electromagnetic_shielding ) > > Not a recommended way to protect yourself from strong EM waves, but it > does make a good joke. > > Regards, > Kyeong Su Shin > > On Tue, Nov 7, 2017 at 11:01 AM, Kevin Hung via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hmm, I am just curious. What does the metal hat do? >> >> On Mon, Nov 6, 2017 at 11:38 PM, Dan CaJacob via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> But if you want to have some fun with your co-workers. Put on a metal >>> hat whenever you TX. If they ask what's going on, say "Don't worry about >>> it" :) >>> >>> On Mon, Nov 6, 2017 at 4:49 PM Bakshi, Arjun via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Thanks for clearing that up. >>>> >>>> >>>> AB >>>> -- >>>> *From:* Nick Foster >>>> *Sent:* Monday, November 6, 2017 3:58:05 PM >>>> *To:* Bakshi, Arjun >>>> *Cc:* usrp-users@lists.ettus.com >>>> *Subject:* Re: [USRP-users] TX power levels. Long term exposure. >>>> >>>> Don't worry about it. You are several orders of magnitude below any >>>> sort of permissible exposure limit. >>>> >>>> Nick >>>> >>>> On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>> I'm looking to do long duration experiments in a lab which will have >>>> people in it while I TX and Rx, and I'd like to know what health and safety >>>> concerns I should keep in mind. >>>> >>>> >>>> I tried looking at FCC and EU for limits on radiation levels, but those >>>> specs aren't straightforward to understand. It's also difficult to get an >>>> estimate of absolute power rxed/txed from the USRPs. So I'd like to hear >>>> from anyone who knows about this stuff. >>>> >>>> >>>> I'm using SBX (max power 100mW), and I'm thinking of using either the >>>> 500-700MHz or the 1.2-1.3 GHz band. I'll be transmitting for *5ms >>>> every second for a few hours*. The room is about 6m x 15m. Then >>>> antennas will be 1-2 meters away from a few people. TX and RX are about 4m >>>> apart. With gain set to 25dB, my signal has ~30dB SNR. >>>> >>>> >>>> Sorry if this seems a bit odd/specific. >>>> >>>> >>>> Thank you, >>>> >>>> >>>> AB >>>> >>>> >>>> ___ >>>> 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 >>>> >>> -- >>> Very Respectfully, >>> >>> Dan CaJacob >>> >>> ___ >>> 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 >> >> > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Unicast messaging via GNURadio
Jeff is right, but since I happen to have tackled this problem several times myself, I'll leave some hopefully helpful advice. My use of unicast protocols has mostly been for spacecraft downlinks - what's your use case? In any event, most uni/mult-cast protocols I have come across have been developed for imaging computers on a network or dumping data from satellites. Here's some examples: - NORM: https://www.nrl.navy.mil/itd/ncs/products/norm - https://www.udpcast.linux.lu/ - http://feclib.sourceforge.net/ - http://saratoga.sourceforge.net/ Most if not all of these are UDP-based, so your modem (which is where GNURadio comes in) will need to be IP-encapsulating. I built an IP-encapsulating QPSK modem for GRCon 2017 based on a fork of Andre Lofaldli's gr-ccsds OOT project. See my fork here: https://github.com/dcajacob/gr-ccsds and video from the conference here: https://www.youtube.com/watch?v=gVCCQ6rX3nk In the video, I use the modem to demonstrate bi-directional remote shell access and file transfer is also possible via rsync, scp or whatever protocol you like. You can use one of the unicast protocols / apps above to demonstrate unicast or multicast as well. Note that some of the protocols can include some return traffic if you have a return channel, but in general they provide built in forward error correction via erasure codes. Hope this helps you or anyone else with this particular use case. - Dan On Fri, Dec 29, 2017 at 4:43 PM Jeff Long via USRP-users < usrp-users@lists.ettus.com> wrote: > Unicast/multicast/broadcast are networking terms for different types of > addresses in a packet, and are relevant at Layer 2 and above. > > GNU Radio is (mostly) concerned with Layer 1 (the radio), where > "broadcast" is an RF term. There is no "multicast" or "unicast" at this > level. > > You can carry any traffic you like over a channel implemented with GNU > Radio. You're probably looking to learn about PDUs and the tuntap > interface if you're dealing with GNU Radio and IP networking. > > On 12/28/2017 06:17 AM, Mahesh Jena via USRP-users wrote: > > Hi Everyone, > > I am new to the GNURadio world. > > > > I have tested few GNURadio features and test scenarios with USRP E312 > > and B210, but all the example that I found has communication over > broadcast. > > > > I wanted to know if its possible to send _unicast_ or > > _multicast_ messages via GNURadio? > > If yes, then can you please give me some example! > > > > Thanks in advance! > > > > Kind Regards, > > > > *Mahesh Jena > > * > > > > > > *DISCLAIMER* > > > > > > THIS MESSAGE, TOGETHER WITH ANY ATTACHMENTS, IS CONFIDENTIAL, IS > > INTENDED ONLY FOR THE USE OF THE ADDRESSEE(S), AND MAY HAVE INFORMATION > > THAT IS COVERED BY LEGAL, PROFESSIONAL OR OTHER PRIVILEGE. ANY OPINIONS > > EXPRESSED, IMPLIED, OR PRESENTED ARE SOLELY THOSE OF THE AUTHOR AND ARE > > NOT THOSE OF PRETLIST. IF YOU ARE NOT THE INTENDED RECIPIENT, THEN > > PLEASE DESTROY THIS EMAIL AND ITS ATTACHMENTS, AND LET US KNOW AT ONCE. > > ANY COPYING, DISTRIBUTION OR USE OF THIS EMAIL, ITS ATTACHMENTS, OR ANY > > INFORMATION CONTAINED HERE IS PROHIBITED. > > > > > > > > ___ > > 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] B200 Noise Figure Meter
Hey guys, I have put together a noise figure meter application that uses a USRP as the sensing device. It started off as a way to measure the NF of the USRP itself. I have a calibrated noise source from an HP 8970B Noise Figure Meter. To test the NF of the USRP, I connect the head to the USRP input. My GNURadio flowgraph maximizes the USRP gain and measures a moving average of the received power while I switch the noise source on and off. The difference in the received power level, in addition to the ENR table from the noise source, can then be used to calculate the NF of the USRP itself using the y-factor method. Once you have the NF for the USRP at many frequencies (I test every 50 MHz from 50 MHz - 6000 MHz), you can modify the same procedure to test the NF of a Device Under Test (DUT) which is connected between the noise source and the (now calibrated) USRP. You can use the USRP cal table we generated in the previous step to derive the NF of the DUT corrected for the NF of the USRP. In short, this all works incredibly well and garners very repeatable results. One complication is that you will see wild NF at certain frequencies due to local interference like LTE and WIFI. I've also compared the results to that which the HP device measures and they're very comparable. ... Except below ~ 1GHz. And here's the issue - I am seeing higher NF for DUTs below about 1GHz and particularly worse below 500 MHz. I was hoping someone at Ettus might be able to shed some light on why this might be. Curiously, the USRPs NF doesn't seem to be too bad, just the DUT. I'll note that I am nominally using a B200 for these tests, but I also tried an E312 just in case the filter banks might help out somehow. I didn't see a difference - they both had the same problem. I have used several DUTs for this test, including LNA boards we have designed ourselves and a Mini-Circuits ZX60-P103LN+ ( https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to exhibit higher NF when measured with a USRP below 1 GHz. When testing them on the HP NF meter, the NF is as expected all the way down to 50 MHz. I have attached the B200 cal data for your enjoyment as well as the B200-measured ZX60 NF and the HP-measured ZX60. The HP NF meter only goes up to 1600 MHz, which is why that data file stops there. I was surprised to see the B200 seemed to have a better NF than the E312, which averaged 8 dB NF, by the way. -- Very Respectfully, Dan CaJacob Frequency,Noise ON,Noise OFF,NF 50.000, -136.472, -143.862, 6.570 100.000, -134.111, -142.368, 5.486 150.000, -133.334, -141.574, 5.508 200.000, -133.053, -142.054, 4.626 250.000, -133.068, -140.887, 6.011 300.000, -133.071, -142.151, 4.540 350.000, -132.990, -142.326, 4.250 400.000, -133.367, -142.289, 4.724 450.000, -133.049, -142.387, 4.252 500.000, -133.099, -142.421, 4.272 550.000, -133.312, -142.324, 4.625 600.000, -132.888, -141.866, 4.666 650.000, -133.159, -142.217, 4.577 700.000, -133.280, -142.570, 4.314 750.000, -132.448, -134.620, 14.941 800.000, -133.432, -142.585, 4.474 850.000, -133.411, -142.818, 4.186 900.000, -133.437, -142.720, 4.330 950.000, -133.865, -142.982, 4.519 1000.000, -133.771, -143.113, 4.265 1050.000, -134.097, -143.049, 4.709 1100.000, -134.481, -143.463, 4.674 1150.000, -134.487, -143.448, 4.699 1200.000, -134.837, -143.470, 5.076 1250.000, -135.162, -143.911, 4.942 1300.000, -135.202, -143.826, 5.087 1350.000, -135.499, -144.026, 5.200 1400.000, -135.723, -144.292, 5.151 1450.000, -135.752, -144.191, 5.303 1500.000, -135.799, -143.933, 5.660 1550.000, -135.983, -144.386, 5.345 1600.000, -135.936, -144.217, 5.487 1650.000, -136.055, -144.351, 5.470 1700.000, -136.269, -144.440, 5.616 1750.000, -136.258, -144.428, 5.618 1800.000, -136.686, -144.804, 5.680 1850.000, -136.977, -144.825, 6.001 1900.000, -136.969, -145.039, 5.736 1950.000, -137.084, -142.683, 8.870 2000.000, -137.789, -145.349, 6.347 2050.000, -137.800, -145.279, 6.450 2100.000, -138.521, -145.820, 6.672 2150.000, -138.037, -143.822, 8.624 2200.000, -138.324, -146.292, 5.869 2250.000, -138.322, -146.289, 5.873 2300.000, -138.999, -146.444, 6.505 2350.000, -138.739, -146.595, 6.012 2400.000, -138.524, -146.335, 6.069 2450.000, -138.959, -146.570, 6.312 2500.000, -138.681, -146.484, 6.084 2550.000, -138.529, -146.399, 6.007 2600.000, -138.784, -146.533, 6.155 2650.000, -138.807, -146.355, 6.402 2700.000, -139.190, -146.716, 6.431 2750.000, -139.572, -146.993, 6.561 2800.000, -140.187, -147.132, 7.153 2850.000, -140.921, -147.560, 7.543 2900.000, -141.454, -147.877, 7.824 2950.000, -142.067, -147.822, 8.714 3000.000, -142.869, -148.560, 8.805 3050.000, -143.345, -148.564, 9.468 3100.000, -143.877, -148.922, 9.722 3150.000, -144.308, -149.143, 10.035 3200.000, -144.770, -149.219, 10.627 3250.000, -145.015, -149.377, 10.766 3300.000, -145.155, -149.496, 10.804 3350.000, -145.516, -149.574, 11.263 3400.000, -145.565, -149.566, 11.362 3450.000, -145.478, -149.699, 11.005 3500.000, -145.751, -149.696, 11.4
Re: [USRP-users] B200 Noise Figure Meter
That's an interesting thought. The 9361 does have a pretty bad match. I'll try adding a 50 Ohm attenuator and see if that helps. On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe wrote: > Hi Dan. Both the B200 and the E312 use the Analog Devices AD9361 RF > integrated transceiver. This chip does have an integrated LNA. Perhaps > there's some sort of mismatch between your DUTs and this integrated LNA at > <1 GHz? > > ADI publishes the RX S-parameters: > https://ez.analog.com/thread/41208#137929 > > -Robin > > On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hey guys, >> >> I have put together a noise figure meter application that uses a USRP as >> the sensing device. It started off as a way to measure the NF of the USRP >> itself. I have a calibrated noise source from an HP 8970B Noise Figure >> Meter. To test the NF of the USRP, I connect the head to the USRP input. My >> GNURadio flowgraph maximizes the USRP gain and measures a moving average of >> the received power while I switch the noise source on and off. The >> difference in the received power level, in addition to the ENR table from >> the noise source, can then be used to calculate the NF of the USRP itself >> using the y-factor method. >> >> Once you have the NF for the USRP at many frequencies (I test every 50 >> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to test the >> NF of a Device Under Test (DUT) which is connected between the noise source >> and the (now calibrated) USRP. You can use the USRP cal table we generated >> in the previous step to derive the NF of the DUT corrected for the NF of >> the USRP. >> >> In short, this all works incredibly well and garners very repeatable >> results. One complication is that you will see wild NF at certain >> frequencies due to local interference like LTE and WIFI. I've also compared >> the results to that which the HP device measures and they're very >> comparable. ... Except below ~ 1GHz. >> >> And here's the issue - I am seeing higher NF for DUTs below about 1GHz >> and particularly worse below 500 MHz. I was hoping someone at Ettus might >> be able to shed some light on why this might be. Curiously, the USRPs NF >> doesn't seem to be too bad, just the DUT. >> >> I'll note that I am nominally using a B200 for these tests, but I also >> tried an E312 just in case the filter banks might help out somehow. I >> didn't see a difference - they both had the same problem. >> >> I have used several DUTs for this test, including LNA boards we have >> designed ourselves and a Mini-Circuits ZX60-P103LN+ ( >> https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to >> exhibit higher NF when measured with a USRP below 1 GHz. When testing them >> on the HP NF meter, the NF is as expected all the way down to 50 MHz. >> >> I have attached the B200 cal data for your enjoyment as well as the >> B200-measured ZX60 NF and the HP-measured ZX60. The HP NF meter only goes >> up to 1600 MHz, which is why that data file stops there. I was surprised to >> see the B200 seemed to have a better NF than the E312, which averaged 8 dB >> NF, by the way. >> -- >> Very Respectfully, >> >> Dan CaJacob >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B200 Noise Figure Meter
I was gonna say, there's actually three of them ;) On Thu, Feb 1, 2018, 9:06 PM Robin Coxe via USRP-users < usrp-users@lists.ettus.com> wrote: > On p.8 of B200 schematic: > T801 is Macom ETC1-1-13TR (RF2) > T800 is Minicircuits TC1-1-43A+ (RF3) > U802 is Anaren BD3150L50100AHF (RF1) > > On Thu, Feb 1, 2018 at 5:45 PM, Ron Economos via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> There's also a balun on the AD9361 input. Unfortunately, the balun part >> number for the low frequency path is not on the schematic. >> >> Ron >> On 02/01/2018 05:39 PM, Dan CaJacob via USRP-users wrote: >> >> That's an interesting thought. The 9361 does have a pretty bad match. >> I'll try adding a 50 Ohm attenuator and see if that helps. >> >> On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe wrote: >> >>> Hi Dan. Both the B200 and the E312 use the Analog Devices AD9361 RF >>> integrated transceiver. This chip does have an integrated LNA. Perhaps >>> there's some sort of mismatch between your DUTs and this integrated LNA at >>> <1 GHz? >>> >>> ADI publishes the RX S-parameters: >>> https://ez.analog.com/thread/41208#137929 >>> >>> -Robin >>> >>> On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Hey guys, >>>> >>>> I have put together a noise figure meter application that uses a USRP >>>> as the sensing device. It started off as a way to measure the NF of the >>>> USRP itself. I have a calibrated noise source from an HP 8970B Noise Figure >>>> Meter. To test the NF of the USRP, I connect the head to the USRP input. My >>>> GNURadio flowgraph maximizes the USRP gain and measures a moving average of >>>> the received power while I switch the noise source on and off. The >>>> difference in the received power level, in addition to the ENR table from >>>> the noise source, can then be used to calculate the NF of the USRP itself >>>> using the y-factor method. >>>> >>>> Once you have the NF for the USRP at many frequencies (I test every 50 >>>> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to test the >>>> NF of a Device Under Test (DUT) which is connected between the noise source >>>> and the (now calibrated) USRP. You can use the USRP cal table we generated >>>> in the previous step to derive the NF of the DUT corrected for the NF of >>>> the USRP. >>>> >>>> In short, this all works incredibly well and garners very repeatable >>>> results. One complication is that you will see wild NF at certain >>>> frequencies due to local interference like LTE and WIFI. I've also compared >>>> the results to that which the HP device measures and they're very >>>> comparable. ... Except below ~ 1GHz. >>>> >>>> And here's the issue - I am seeing higher NF for DUTs below about 1GHz >>>> and particularly worse below 500 MHz. I was hoping someone at Ettus might >>>> be able to shed some light on why this might be. Curiously, the USRPs NF >>>> doesn't seem to be too bad, just the DUT. >>>> >>>> I'll note that I am nominally using a B200 for these tests, but I also >>>> tried an E312 just in case the filter banks might help out somehow. I >>>> didn't see a difference - they both had the same problem. >>>> >>>> I have used several DUTs for this test, including LNA boards we have >>>> designed ourselves and a Mini-Circuits ZX60-P103LN+ ( >>>> https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to >>>> exhibit higher NF when measured with a USRP below 1 GHz. When testing them >>>> on the HP NF meter, the NF is as expected all the way down to 50 MHz. >>>> >>>> I have attached the B200 cal data for your enjoyment as well as the >>>> B200-measured ZX60 NF and the HP-measured ZX60. The HP NF meter only goes >>>> up to 1600 MHz, which is why that data file stops there. I was surprised to >>>> see the B200 seemed to have a better NF than the E312, which averaged 8 dB >>>> NF, by the way. >>>> -- >>>> Very Respectfully, >>>> >>>> Dan CaJacob >>>> >>>> ___ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>>> >>> -- >> Very Respectfully, >> >> Dan CaJacob >> >> >> ___ >> USRP-users mailing >> listUSRP-users@lists.ettus.comhttp://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 >> >> > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B200 Noise Figure Meter
I saw no improvement when including a 3dB 50 Ohm attenuator as part of the B200 NF meter. I guess I could try higher attenuator values. On Thu, Feb 1, 2018 at 9:16 PM Dan CaJacob wrote: > I was gonna say, there's actually three of them ;) > > On Thu, Feb 1, 2018, 9:06 PM Robin Coxe via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On p.8 of B200 schematic: >> T801 is Macom ETC1-1-13TR (RF2) >> T800 is Minicircuits TC1-1-43A+ (RF3) >> U802 is Anaren BD3150L50100AHF (RF1) >> >> On Thu, Feb 1, 2018 at 5:45 PM, Ron Economos via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> There's also a balun on the AD9361 input. Unfortunately, the balun part >>> number for the low frequency path is not on the schematic. >>> >>> Ron >>> On 02/01/2018 05:39 PM, Dan CaJacob via USRP-users wrote: >>> >>> That's an interesting thought. The 9361 does have a pretty bad match. >>> I'll try adding a 50 Ohm attenuator and see if that helps. >>> >>> On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe wrote: >>> >>>> Hi Dan. Both the B200 and the E312 use the Analog Devices AD9361 RF >>>> integrated transceiver. This chip does have an integrated LNA. Perhaps >>>> there's some sort of mismatch between your DUTs and this integrated LNA at >>>> <1 GHz? >>>> >>>> ADI publishes the RX S-parameters: >>>> https://ez.analog.com/thread/41208#137929 >>>> >>>> -Robin >>>> >>>> On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> Hey guys, >>>>> >>>>> I have put together a noise figure meter application that uses a USRP >>>>> as the sensing device. It started off as a way to measure the NF of the >>>>> USRP itself. I have a calibrated noise source from an HP 8970B Noise >>>>> Figure >>>>> Meter. To test the NF of the USRP, I connect the head to the USRP input. >>>>> My >>>>> GNURadio flowgraph maximizes the USRP gain and measures a moving average >>>>> of >>>>> the received power while I switch the noise source on and off. The >>>>> difference in the received power level, in addition to the ENR table from >>>>> the noise source, can then be used to calculate the NF of the USRP itself >>>>> using the y-factor method. >>>>> >>>>> Once you have the NF for the USRP at many frequencies (I test every 50 >>>>> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to test the >>>>> NF of a Device Under Test (DUT) which is connected between the noise >>>>> source >>>>> and the (now calibrated) USRP. You can use the USRP cal table we generated >>>>> in the previous step to derive the NF of the DUT corrected for the NF of >>>>> the USRP. >>>>> >>>>> In short, this all works incredibly well and garners very repeatable >>>>> results. One complication is that you will see wild NF at certain >>>>> frequencies due to local interference like LTE and WIFI. I've also >>>>> compared >>>>> the results to that which the HP device measures and they're very >>>>> comparable. ... Except below ~ 1GHz. >>>>> >>>>> And here's the issue - I am seeing higher NF for DUTs below about 1GHz >>>>> and particularly worse below 500 MHz. I was hoping someone at Ettus might >>>>> be able to shed some light on why this might be. Curiously, the USRPs NF >>>>> doesn't seem to be too bad, just the DUT. >>>>> >>>>> I'll note that I am nominally using a B200 for these tests, but I also >>>>> tried an E312 just in case the filter banks might help out somehow. I >>>>> didn't see a difference - they both had the same problem. >>>>> >>>>> I have used several DUTs for this test, including LNA boards we have >>>>> designed ourselves and a Mini-Circuits ZX60-P103LN+ ( >>>>> https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to >>>>> exhibit higher NF when measured with a USRP below 1 GHz. When testing them >>>>> on the HP NF meter, the NF is as expected all the way down to 50 MHz. >>>>> >>>>> I have attached the B200 cal data for
Re: [USRP-users] B200 Noise Figure Meter
Yep, I am aware of that document and I am using the Y-factor method. The 3 dB attenuator was calibrated with the B200 - i.e. I measured the NF of the USRP + 3dB attenuator as a system. That data then serves as the calibration data to correct for it's contribution to the subsequent NF measurement of the B200 + 3dB pad + DUT. I saw the same poor performance below 1 GHz when using the 3dB pad. On Sun, Feb 4, 2018 at 11:44 AM David Bengtson wrote: > A 3dB attenuation will really improve the reflection coefficient. > Using this calculator > > http://www.rfcafe.com/references/calculators/vswr-return-loss-conversion-calculator.htm > you can see that a 3 dB attenuation will improve a 3:1 VSWR to 1.7:2, > or a 6 dB return loss to 12 dB, so you've really improved the match. > The gory details of noise figure and match are in here > http://literature.cdn.keysight.com/litweb/pdf/5952-3706E.pdf and > Keysight has a spreadsheet to do the calculations here > > https://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=96887&nid=-34815.0.00&id=96887 > (Probably more detail than needed) > > Did you add the 3dB attenuator to the noise figure? > > Dave > > > > On Sat, Feb 3, 2018 at 10:41 AM, Dan CaJacob via USRP-users > wrote: > > I saw no improvement when including a 3dB 50 Ohm attenuator as part of > the > > B200 NF meter. I guess I could try higher attenuator values. > > > > On Thu, Feb 1, 2018 at 9:16 PM Dan CaJacob > wrote: > >> > >> I was gonna say, there's actually three of them ;) > >> > >> > >> On Thu, Feb 1, 2018, 9:06 PM Robin Coxe via USRP-users > >> wrote: > >>> > >>> On p.8 of B200 schematic: > >>> T801 is Macom ETC1-1-13TR (RF2) > >>> T800 is Minicircuits TC1-1-43A+ (RF3) > >>> U802 is Anaren BD3150L50100AHF (RF1) > >>> > >>> On Thu, Feb 1, 2018 at 5:45 PM, Ron Economos via USRP-users > >>> wrote: > >>>> > >>>> There's also a balun on the AD9361 input. Unfortunately, the balun > part > >>>> number for the low frequency path is not on the schematic. > >>>> > >>>> Ron > >>>> > >>>> On 02/01/2018 05:39 PM, Dan CaJacob via USRP-users wrote: > >>>> > >>>> That's an interesting thought. The 9361 does have a pretty bad match. > >>>> I'll try adding a 50 Ohm attenuator and see if that helps. > >>>> > >>>> On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe > wrote: > >>>>> > >>>>> Hi Dan. Both the B200 and the E312 use the Analog Devices AD9361 RF > >>>>> integrated transceiver. This chip does have an integrated LNA. > Perhaps > >>>>> there's some sort of mismatch between your DUTs and this integrated > LNA at > >>>>> <1 GHz? > >>>>> > >>>>> ADI publishes the RX S-parameters: > >>>>> https://ez.analog.com/thread/41208#137929 > >>>>> > >>>>> -Robin > >>>>> > >>>>> On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users > >>>>> wrote: > >>>>>> > >>>>>> Hey guys, > >>>>>> > >>>>>> I have put together a noise figure meter application that uses a > USRP > >>>>>> as the sensing device. It started off as a way to measure the NF of > the USRP > >>>>>> itself. I have a calibrated noise source from an HP 8970B Noise > Figure > >>>>>> Meter. To test the NF of the USRP, I connect the head to the USRP > input. My > >>>>>> GNURadio flowgraph maximizes the USRP gain and measures a moving > average of > >>>>>> the received power while I switch the noise source on and off. The > >>>>>> difference in the received power level, in addition to the ENR > table from > >>>>>> the noise source, can then be used to calculate the NF of the USRP > itself > >>>>>> using the y-factor method. > >>>>>> > >>>>>> Once you have the NF for the USRP at many frequencies (I test every > 50 > >>>>>> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to > test the > >>>>>> NF of a Device Under Test (DUT) which is connected between the > noise source > >>>>>> and the (now calibrated) USRP. You can use the USRP cal table we > genera
Re: [USRP-users] Streaming 8-bit (sc8) samples from RFNoC
I seem to recall that the 8-bit OTW format isn't implemented for RFNoC yet... I could use that too. On Mon, Mar 19, 2018 at 9:07 PM Adam Parower via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello everyone, > > > I am trying to figure out how to receive complex 8-bit integer samples > from a USRP containing a custom RFNoC flowgraph. If I didn't require RFNoC > and could use the legacy UHD C++ API instead, this would be trivial; I > would simply set both the host format and on-the-wire format in my stream > arguments to "sc8". However, when I do the same thing in my RFNoC-based > application, I get the following error message: > > Error: RuntimeError: [RX Streamer] Conflicting OTW types defined: > args.otw_format = 'sc8' <=> stream_sig.item_type = 'sc16' > > > I understand that the value of stream_sig.item_type comes from the > port in the XML block declaration of the block to which my > rx_streamer points, but editing the field there does not produce > the desired result. To correctly stream 8-bit samples, would I have to, > say, implement a custom RFNoC block to repackage 16-bit samples into 8-bit > samples at half the sample rate, discarding the 8 LSBs? Or is there a > simpler way to do this? > > > Thank you in advance for your assistance. > > > Adam Parower > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Synchronizing multiple B205 mini radios
Without looking at the schematic, I'd guess that the difference is in the implementation of the PLLs for tracking. On Mon, Jun 25, 2018 at 11:21 AM Chintan Patel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Marcus, > > Two follow-up questions related to B205/B210 synchronization. > > 1. What is the fundamental reason why B210 supports phase coherent sync > across multiple devices and B205 does not. The reference manuals on the > AD9364/AD9361 does not point to any clues, and neither does the schematic. > > 2. If we feed identical 40 MHz to multiple B205 from the reference input > to the output of the DPLL (remove X1 and run a wire from R35-1 to X1-3) and > identical 1PPS to a GPIO pin, is there a way to phase and frequency align > the rx sample (CAT-DCLK) signals. > > Thanks > > Chintan > > On Sat, Jun 23, 2018 at 11:26 AM, Marcus D. Leech > wrote: > >> On 06/23/2018 09:06 AM, Chintan Patel wrote: >> >> Hi Marcus, >> >> Thanks for the response. I came to a similar conclusion reading the Ettus >> app note on MIMO synchronization. >> >> Do you know if the DPLL code (or any other way) can be modified to >> achieve phase coherence across multiple B205 minis. >> >> My understanding is that it is likely a very challenging exercise with >> the existing hardware, otherwise, it would already be in place. >> But the code, like all the other Ettus FPGA and host-side UHD code is >> freely available. >> >> >> >> >> >> Thanks >> Chintan >> >> On Sat, Jun 23, 2018 at 1:07 AM, Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 06/23/2018 12:25 AM, Chintan Patel via USRP-users wrote: >>> Hello, I am an Ettus newbie. We have an application that requires us to synchronize multiple B205 mini radios (RX side) using the PPS in signal. In the FPGA, the pps_in is reclocked into the radio clock domain. What we notice is that when we monitor this PPS signal (reclocked in radio clock domain) from two different radios on a scope, there is a time variation between the alignment of these two PPS signals across different trials. In other words, after each reset the time skew between the two signals varies. Since the PPS_in for both radios is the same, I think this variation across different reboot iterations means that the radio clock is not guaranteed to be phase aligned/locked to the PPS for the B205 radio. Curiously, when we repeat the same experiment using the B210, we do not see this time alignment variation across reboots. Which only makes sense if somehow for the B210 the radio clock is phase locked to the PPS in. Any thoughts from folks who might have tried similar applications and/or who understand the B205 mini/B210 radios. Thanks Chintan The 1PPS/10MHz DPLL on the B205mini series is not designed to provide >>> close phase coherence across multiple devices. It is designed to >>> synchronize the clock on the board to an external reference. >>> >>> The DPLL servo code in the B205mini drives the control voltage on the >>> VCTCXO that provides all clocking signals on the board. >>> >>> >>> >>> ___ >>> 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] SC8 Wireformat
Just speculating, but I wonder if what you're seeing is a result of quantization error... On Mon, Jun 25, 2018 at 11:55 PM Farhad via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks Ian for your answer; but my main question still remains unanswered > which is why with different wire format sc8 and sc16 the spectrum is > different? How may I interpret this? > > Thanks, > > On Jun 25, 2018, at 9:44 PM, Ian Buckley wrote: > > On a USRP2 thats a harmonic of the on-board 100MHz clock. One excellent > way to deduce when you are dealing with a spur thats LO related is to use > offset tuning to move the LO relative to the center of your band of > interest. > See: https://files.ettus.com/manual/structuhd_1_1tune__request__t.html > > > On Jun 25, 2018, at 3:15 PM, Farhad Mirkazemi via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Hi all, > > I attached the two spectrum snapshots with no antenna connected (which > means what I'm seeing is just pure noise?)to usrp2 setting the center > frequency at 1590 MHz, one using sc16, fs 25 MHz and the other sc8 > wireformat fs 50 MHz; regardless of the spike at 1600 MHz (10 MHz off the > fc) which I don't know why it shows up on both spectrum (I can interpret > the spike at the center frequency as dc component but don't know about this > one); so it looks like for the sc8 the spectrum has been folded around > center frequency where for sc16 wireformat it looks normal. can you please > explain why is that and how to fix this? > > Thanks, > > > > > On Friday, June 22, 2018, 5:52:23 PM EDT, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > > > On 06/22/2018 05:43 PM, Farhad Mirkazemi via USRP-users wrote: > > > Hello all, > > I'm recording RF signal at 1.5 GHz using usrp2 with wbx daughterboard of > fixed BW of 40 MHz; since I'm interested to capture the whole BW, I set the > over-the-wire format to sc8 to be able to have 50 MSps rate; as example > rx_samples_to_file suggests, there is no "byte" or "char" format to store 8 > bit IQ samples; now, if I use "short" type and try to read my binary file > using matlab, for example, and use the same "int16" format as I was doing > for SC16 wireformat, i.e interpreting it as I1, Q1, I2, Q2 . using > "int16" reading format, the spectrum looks not the way it should. I know > it also has to do with the host cpu format which in my case it is 64 bit > processor but I don't know how to manage the transformation between the > host and the packet router. Can some please explain how it works and if > possible how to interpret the data on platform other than uhd? it is also > appreciated if explain how I could store using 8 bit format so that the > file size be reduced to half. > > Thanks, > > > You may need to tweak the dynamic range in the device arguments, using > "peak=0.01" or even "peak=0.001", depending on hows strong your > signal is. > > Also, could you describe what you mean by "not what it should be" ?? > That's a little vague. > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > 18-00-34.png>___ > 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC On B210
I think what would be more useful is a low-end USRP (low price like B200) that is RFNOC-capable. I guess that might be something like an E310 in a white case? On Fri, Jun 29, 2018 at 9:12 AM GhostOp14 via USRP-users < usrp-users@lists.ettus.com> wrote: > I second RFNoC for the B series would be great. They're an incredibly > popular and affordable series and I feel a little left out of the > capabilities of RFNoC due to the Spartan6. Bringing the Artix to the > B-series or supporting the Spartan6 could both be options I'd love to see. > (Just a community vote :) ) > > On Thu, Jun 28, 2018 at 6:56 PM, Peter Sanchez via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Thank you >> >> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley >> wrote: >> >>> There is no conceptual reason why you can’t build an RFNoC design on >>> B210, it uses the same USRP3 base architecture and FPGA source >>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all the >>> implementation work for RFNoC is done using Xilinx’s Vivado design tools >>> which support only the newer FPGA architectures like Zynq (Artix) and >>> Kintex…Spartan6 users are stuck with ISE14 forever, so in practical terms, >>> no, it’s not possible without you completely recreating all that >>> infrastructure. >>> >>> -Ian >>> >>> > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> > >>> > Hi All, >>> > Is it possible to generate RFNoC blocks for the B210? I can't find a >>> lot of information about it. Can some one show me the URL if there is a >>> website talking about it? >>> > >>> > Cheers >>> > ___ >>> > 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 >> >> > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC On B210
What I meant and didn't explain well enough is a potential new Ettus product would be a Zynq-based B2X0 clone. That would be RFNOC-capable. On Fri, Jun 29, 2018 at 2:32 PM Ian Buckley via USRP-users < usrp-users@lists.ettus.com> wrote: > Er no. > > B200 has approximately the same number of FPGA logic gates as E310, B210 > twice that amount. > The current design is simply larger than it needs to be because it shares > all it’s code with X300, I could have made it much smaller had there been a > good reason to. > > The FPGA was simply chosen because it was the biggest and newest available > when that project was begun. > The Vivado/ISE split wasn’t customer visible at that point in time, > remember X300 was also ISE based at initial release. > > It remains a potent platform for capable FPGA designers to do custom stuff > on, just not RFNoC. > -Ian > > > > On Jun 29, 2018, at 1:35 AM, Marcus Müller > wrote: > > > > To give an uplifting spin to all this: > > > > Now, also, although larger than the one on the B200, the B210's FPGA > > isn't really large unoccupied, so the amount of logic that you could > > even hypothetically put in there is limited. Why's that uplifiting? > > > > That FPGA was chosen for the board because there's usually little need > > to do anything but the hardware interfacing and the DDC/DUC in the > > FPGA. The B210 can, with good USB3 controllers, pretty much directly > > hand through its analog bandwidth to a computer. So, unless you have a > > workload that your PC including GPU and whatnot can't achieve, you > > don't even have to think about implementing things on the B210's FPGA – > > and frankly, I've got no idea what'd be easy to do on the free space of > > a B210 but impossible on a high-end PC. And a high-end PC is still > > cheaper than a ISE14 license. > > > > Only thing that comes into mind is the latency restrictions you incur > > with USB; that's really something that no amount of computing power on > > the host computer side could solve. > > > > So, maybe, if I can encourage you to discuss your specific application, > > we can find a sensible solution on what to put on the SDR peripheral > > device itself, and what to do on your PC? > > > > Best regards, > > Marcus > > > > On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote: > >> Thank you > >> > >> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley > >> wrote: > >>> There is no conceptual reason why you can’t build an RFNoC design > >>> on B210, it uses the same USRP3 base architecture and FPGA source > >>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all > >>> the implementation work for RFNoC is done using Xilinx’s Vivado > >>> design tools which support only the newer FPGA architectures like > >>> Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14 > >>> forever, so in practical terms, no, it’s not possible without you > >>> completely recreating all that infrastructure. > >>> > >>> -Ian > >>> > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users >>> s...@lists.ettus.com> wrote: > > Hi All, > Is it possible to generate RFNoC blocks for the B210? I can't > >>> find a lot of information about it. Can some one show me the URL if > >>> there is a website talking about it? > > Cheers > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co > >>> m > >>> > >> > >> ___ > >> 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 > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Any tips to speed up X310 Vivado build time?
I am not an FPGA or Vivado expert, but I tried to do the same thing. I believe Vivado is limited to 4 cores, so sadly, it seems like your best bet is to get a quad-core with the fastest clock you can find. I think AWS just released a "frequency-optimized" instance family. Maybe take a look at that. Ultimately, Vivado sucks for not supporting arbitrary numbers of cores. There's not a small but of irony in a embarrassingly parallel device being developed on a few cores... - Dan On Tue, Jul 24, 2018 at 1:11 PM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > I know Vivado build times are dependent on how optimized you want things > and how utilized the FPGA is, but is there a way to speed up the build > times? > > I started doing my builds on a server thinking it would be a huge boost > from my PC, but I am not really seeing a difference. It has 64 cores and > 300Gb of RAM, but if I look at my usage while building an image, I see a > single core pegged at 100%, and I am only using about 6Gb of RAM. > > My image is taking about 2 hours these days, but I was hoping to speed > things up a bit if it is possible (I know Vivado has some hooks to do > things, but I don't know if it will mess up the X310 build process). > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Very Respectfully, Dan CaJacob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 not locking on GPS
GPS doesn't like to go back in time. You probably need to reset the almanac and a reboot is doing that. On Tue, Apr 30, 2019, 9:53 AM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > I've seen this a few times, but I cannot seem to lock it down to any > particular reason. While sitting at my desk with a GPS simulator (so I > have a known good signal), I will be doing testing and everything is fine > (it seems to be walking around the place where the unit was built). I will > turn off the GPS unit for the night and then the next day when I turn it > on, I never get a fix. I've seen this numerous times and the only way I > can fix it is to reboot the E310. It is like the GPS is getting into a > mucked up stated. Data comes streaming through, but it is just the last > good signal. > > I can't figure out a way to reset the GPS without rebooting it, does > anyone know of a way? I tried killing and restarting the daemon, but that > doesn't seem to do anything. I really think it is the GPS module, but > rebooting it everytime I want to run things "just in case." > > One other weird thing, when I run gpsmon in this screwed up state, it > mostly looks OK, but it has weird characters displayed throughout the ASCII > heading (for lack of a better term). > > This is a good setup on a different unit (so I don't expect to see a fix): > tcp://localhost:2947 u-blox> > ┌──┐┌─┐ > or":11} > │Ch PRN Az El S/N Flag U ││ECEF Pos: +6378137.00m +0.00m +0.00m > │ > er":"u-blox","subtype":"Unknown","activated":"2018-10-10T06:21:07.701Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]} > │ 0 1 0 165 0 0110 ││ECEF Vel: +0.00m/s +0.00m/s > +0.00m/s │ false,"timing":false,"split24":false,"pps":true} > │ 1 2 0 165 0 0110 ││ > │ > │ 2 4 0 165 0 0110 ││LTP Pos: 0.0° 0.0° > -18.00m │ > │ 3 6 0 165 23 0310 ││LTP Vel:0.00m/s 0.0° 0.00m/s > │ > │ 4 7 0 165 0 0110 ││ > │ > │ 5 9 0 165 23 0310 ││Time: 0 00:00:00.00 >│ > │ 6 14 0 165 22 0310 ││Time GPS: Day: > │ > │ 7 19 0 165 22 0310 ││ > │ > │ 8 20 0 165 21 0310 ││Est Pos Err998.72st Vel Err 0.00m/s >│ > │ 9 21 0 165 0 0110 ││PRNs: 0 PDOP:100.0 Fix 0x00 Flags 0x40 >│ > │10 22 0 165 0 0110 │└─── NAV_SOL > ─┘ > │11 23 0 165 0 0110 > │┌─┐ > │12 24 0 165 0 0110 ││DOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] > 100.0│ > │13 28 0 165 23 0310 │└─── NAV_DOP > ─┘ > │14 30 0 165 0 0110 > │┌─┐ > │15 136 0 165 0 0110 ││TOFF: > 1 dayPPS: >│ > > There are lines around the different sections (they look like lines, not > dashes and bars). > > > and then on the unit that is hosed: > tcp://localhost:2947 u-blox> > lqqklqk > or":11} > xCh PRN Az El S/N Flag U xxECEF Pos: -2414806.17m +5389584.51m > +2400650.28m x > er":"u-blox","subtype":"Unknown","activated":"2019-01-08T14:52:40.454Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]} > x 0 2 0 165 50 0700 xxECEF Vel: +0.00m/s +0.00m/s > +0.00m/s x false,"timing":false,"split24":false,"pps":true} > x 1 4 0 165 50 0700 xx > x > x 2 5 0 165 50 0700 xxLTP Pos: 22.2557151134f 114.134790532f > 20.19m x > x 3 8 0 165 0 0100 xxLTP Vel:0.00m/s 0.0f 0.00m/s > x > x 4 9 0 165 50 0700 xx > x > x 5 10 0 165 50 0700 xxTime: 61 06:13:40.00 > x > x 6 12 0 165 50 0700 xxTime GPS: 1877+529282.000 Day: 6 > x > x 7 13 0 165 50 0600 xx > x > x 8 17 0 165 50 0700 xxEst Pos Err2238690.24st Vel Err 0.00m/s >x > x 9 20 0 165 50 0700 xxPRNs: 0 PDOP:100.0 Fix 0x00 Flags 0xdc >x > x10 23 0 165 50 0700 xmqqq NAV_SOL > qj > x11 24 0 165 0 0110 > xlqk > x12 27 0 165 50 0700 xxDOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] > 100.0x > x13 28 0 165 50 0700 xmqqq NAV_DOP > qj > x14 129 127 51 0 0110 > xlqk > x15xxTOFF: > 1 dayPPS: >x > mqq NAV_SVINFO > jmqj > > Not that instead of lines, I see characters. What is up with that > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _
