Re: [Discuss-gnuradio] E312 - Broadband Noise in Spectrum During Retuning
Hi Marcus, Just doubled checked - tx_gain is set to zero. Thanks, Michael On Fri, Mar 10, 2017 at 2:22 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Michael, > > I think you're right, looks like spurs of the tuner / synthesizer, due to > the TX amp not getting shut down for tuning. Do these go away if you set > the tx_gain to zero just before and to its original value just after tuning? > > Best regards, > > Marcus > > On 03/09/2017 08:21 PM, Michael Skaggs wrote: > > Hi all, > > We are working with an E312 platform and are seeing large, broadband > frequency spikes when the system must retune over a wide set of frequencies. > > I have attached a photo of the issue. The blue you see near the top of the > spectrum is the noise we are talking about. We are currently tuning the > system between 345MHz, 400MHz, and 455MHz. We suspect this issue is > occurring due to the amplifier not turning off during the retune, however, > we did not find any topics already discussing this problem. > > Could this be an issue with our hardware, or is there a way to work around > this issue? > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Boosting Output RMS Power of BasicTX Daughterboard
Using GRC 3.7.8, UHD 3.8.5. We had a spare BasicTX, but swapping it out
provides the same effect. The o-scope is properly terminated.
It seems like it has to be some way that we've set up the GRC test. I've
attached the top_block.py and the .grc file to this message, perhaps this
will shed some light on the situation.
Thanks,
Michael
On Tue, Dec 27, 2016 at 5:53 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:
> Also: The BasicTX's source impedance is 50Ω; make sure you properly
> terminate either by setting your scope to 50Ω or by measuring with a high
> scope impedance over a 50Ω resistor.
>
> Best regards,
>
> Marcus
>
> On 12/23/2016 10:50 PM, Marcus D. Leech wrote:
>
> On 12/23/2016 01:45 PM, Michael Skaggs wrote:
>
> 1 MHz signal with a 6.25MSps rate. We just attempted a signal at 5MHz and
> measured it at 114mV RMS, a 10MHz signal is 56mV RMS. The voltage seems to
> drop as the signal frequency rises. Does this assure a hardware issue? Or
> is there something else we can check?
>
> Thanks,
> Michael
>
> Thing is, there's not that much that can go wrong with a BASIC_TX. It's
> all passives.
>
> What version of UHD are you using?
>
>
>
> On Fri, Dec 23, 2016 at 10:44 AM, Marcus D. Leech <mle...@ripnet.com>
> wrote:
>
>> On 12/23/2016 10:26 AM, Michael Skaggs wrote:
>>
>> Hi all,
>>
>> We're currently working with a BasicTX daughterboard attached to a N210
>> USRP. We are using both outputs of the BasicTX in quadrature (I on one
>> channel, Q on the other). The problem we are running into is that the
>> output power of the BasicTX board seems very low. Looking at it on an
>> o-scope, we are seeing around 166mV RMS on each channel, which seems lower
>> than we would expect.
>>
>> We are using GNURadio Companion to transmit these waveforms, and it is a
>> very simple setup. A single "Signal Source" block generating a sine wave
>> into a "UHD: USRP Sink" block. The "amplitude" value is at it's near max
>> without clipping in the ADC and since the daughterboard has no gain
>> elements, "gain" does nothing, so we're kind of at a loss here.
>>
>> Any help is appreciated.
>>
>> Thanks,
>> Michael
>>
>>
>> ___
>> Discuss-gnuradio mailing
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> What frequency?
>> ___ Discuss-gnuradio mailing
>> list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/
>> listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
sinewavetest.grc
Description: application/gnuradio-grc
#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Tue Dec 27 09:27:19 2016
##
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
from gnuradio import analog
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio import wxgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import time
import wx
class top_block(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")
_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
##
self.samp_rate = samp_rate = 6.25e6
##
# Blocks
##
self.wxgui_scopesink2_0 = scopesink2.scope_sink_c(
self.GetWin(),
Re: [Discuss-gnuradio] Boosting Output RMS Power of BasicTX Daughterboard
1 MHz signal with a 6.25MSps rate. We just attempted a signal at 5MHz and measured it at 114mV RMS, a 10MHz signal is 56mV RMS. The voltage seems to drop as the signal frequency rises. Does this assure a hardware issue? Or is there something else we can check? Thanks, Michael On Fri, Dec 23, 2016 at 10:44 AM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 12/23/2016 10:26 AM, Michael Skaggs wrote: > > Hi all, > > We're currently working with a BasicTX daughterboard attached to a N210 > USRP. We are using both outputs of the BasicTX in quadrature (I on one > channel, Q on the other). The problem we are running into is that the > output power of the BasicTX board seems very low. Looking at it on an > o-scope, we are seeing around 166mV RMS on each channel, which seems lower > than we would expect. > > We are using GNURadio Companion to transmit these waveforms, and it is a > very simple setup. A single "Signal Source" block generating a sine wave > into a "UHD: USRP Sink" block. The "amplitude" value is at it's near max > without clipping in the ADC and since the daughterboard has no gain > elements, "gain" does nothing, so we're kind of at a loss here. > > Any help is appreciated. > > Thanks, > Michael > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > What frequency? > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Boosting Output RMS Power of BasicTX Daughterboard
Hi all, We're currently working with a BasicTX daughterboard attached to a N210 USRP. We are using both outputs of the BasicTX in quadrature (I on one channel, Q on the other). The problem we are running into is that the output power of the BasicTX board seems very low. Looking at it on an o-scope, we are seeing around 166mV RMS on each channel, which seems lower than we would expect. We are using GNURadio Companion to transmit these waveforms, and it is a very simple setup. A single "Signal Source" block generating a sine wave into a "UHD: USRP Sink" block. The "amplitude" value is at it's near max without clipping in the ADC and since the daughterboard has no gain elements, "gain" does nothing, so we're kind of at a loss here. Any help is appreciated. Thanks, Michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?
Hey Marcus, In GRC, I have a USRP Source block with "Sync" set to "Unknown PPS" and "Timing Source" set to "External". I assumed the device would be setting time based on the external PPS using these parameters. The synchronize(S0) LED goes solid (after about half a second of recording, maybe less) and the other LED (S1) is blinking with the PPS. Thanks, Michael On Fri, Apr 22, 2016 at 11:56 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Are you sure you're setting the device time correctly? 2.5ms offset is > definitely much much worse than what to devices that should have the same > device time should exhibit. So: > How are you setting the device time? > > Best regards, > Marcus > > > On 04/21/2016 08:59 PM, Michael Skaggs wrote: > > Aha! You were correct. I was parsing the header incorrectly. However, even > after parsing, and the more accurate values (now accurate to 10e-6), it > appears the recorded RF data sets are still are offset from each other by > an amount of nearly 2.5e-3 seconds. Any idea why this would be? It's > strange, especially considering that the are synchronized to the same PPS, > and I think the time is with reference to the pulse. > > Michael > > On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech <mle...@ripnet.com> > wrote: > >> On 04/21/2016 11:41 AM, Michael Skaggs wrote: >> >>> I'm trying to time/sample synchronize RF recordings with two B200minis. >>> I am using the detached Metadata File Sink in GRC. Both recordings are at >>> 30MSps and both B200mini boards are synchronized to the same 1PPS signal. >>> >>> My issue is this, when I extract the data from the Metadata header file, >>> the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which, >>> with a recording at 30MSps, this will only give me a sample alignment >>> accuracy to 10e-4(s)*30(MS/s) = 30,000 samples. >>> >>> If I'm attempting to align the two recordings by samples or time, this >>> is not nearly accurate enough. Is there a way that I can get more accuracy >>> out of my metadata header or a way that I can synchronize the recordings of >>> these B200minis? >>> >>> Thanks, >>> Michael >>> >>> The precision of the timestamps from UHD should have a precision of >> whatever the master-clock is on the device--how are you interpreting >> the rx_time tag? It's two parts--a uint64 with the full-seconds >> portion, and a double-precision float for the fractional part. >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?
Aha! You were correct. I was parsing the header incorrectly. However, even after parsing, and the more accurate values (now accurate to 10e-6), it appears the recorded RF data sets are still are offset from each other by an amount of nearly 2.5e-3 seconds. Any idea why this would be? It's strange, especially considering that the are synchronized to the same PPS, and I think the time is with reference to the pulse. Michael Michael Skaggs M.S. - Computer Engineering LinkedIn <https://www.linkedin.com/in/MichaelDSkaggs> | Resume <http://goo.gl/NBEs2y> | Research Cluster <http://eclipse.umbc.edu/> University of Maryland, Baltimore County On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 04/21/2016 11:41 AM, Michael Skaggs wrote: > >> I'm trying to time/sample synchronize RF recordings with two B200minis. I >> am using the detached Metadata File Sink in GRC. Both recordings are at >> 30MSps and both B200mini boards are synchronized to the same 1PPS signal. >> >> My issue is this, when I extract the data from the Metadata header file, >> the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which, >> with a recording at 30MSps, this will only give me a sample alignment >> accuracy to 10e-4(s)*30(MS/s) = 30,000 samples. >> >> If I'm attempting to align the two recordings by samples or time, this is >> not nearly accurate enough. Is there a way that I can get more accuracy out >> of my metadata header or a way that I can synchronize the recordings of >> these B200minis? >> >> Thanks, >> Michael >> >> The precision of the timestamps from UHD should have a precision of > whatever the master-clock is on the device--how are you interpreting > the rx_time tag? It's two parts--a uint64 with the full-seconds > portion, and a double-precision float for the fractional part. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Higher Accuracy Metadata Header?
I'm trying to time/sample synchronize RF recordings with two B200minis. I am using the detached Metadata File Sink in GRC. Both recordings are at 30MSps and both B200mini boards are synchronized to the same 1PPS signal. My issue is this, when I extract the data from the Metadata header file, the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which, with a recording at 30MSps, this will only give me a sample alignment accuracy to 10e-4(s)*30(MS/s) = 30,000 samples. If I'm attempting to align the two recordings by samples or time, this is not nearly accurate enough. Is there a way that I can get more accuracy out of my metadata header or a way that I can synchronize the recordings of these B200minis? Thanks, Michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 1PPS Synchronization - File Meta Sink Data
Hi all, I'm doing a simple RF recording with a B200mini synchronized to an accurate GPS 1PPS. I'm attempting to determine which samples(most importantly the first one) fall on a 1PPS pulse. I'm using the File Meta Sink block in GRC to try and extract information from the recording. When I read the data from the header, here is what is shown: fileName: 'X:\X.dat' ifileName: 'X:\X.idx' ioType: 'r' totalPulseCount: 11 sampleCount: 100 startTime: [0 0.1120] timestamp0: '1970-01-01 00:00:00.112' rx_rate: 100 rx_time: [0 0.1120] timestamp: '1970-01-01 00:00:00.112' rx_freq: 5 sampleType: 'float' typeFlag: 'double' vBit: 1 impediance: 50 samples: [] So, this is a 1 MSps recording with a center frequency at 500MHz and about 11 seconds in length, so the extracted information is definitely correct. But a couple of questions from the metadata: The "startTime" value is 0.1120. I realize that this is the time stamp of the first sample of the segment. However, does that mean that sample 112000 (1MSps*0.1120) is the first sample that falls on a PPS since the B200mini is synced to it? Second, the "samples" field is empty. I was attempting to populate it with sample numbers that fall on a 1PPS or a header. If the header is synchronized to the 1PPS, this will be fairly easy. If not, is there a way to determine which samples fall on the PPS? Thanks, Michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] B200mini and Raspberry Pi 2 Connectivity
Hello all, After sorting out my power issues with the B200mini (it required a dual USB to 3.0 mini cable, due to browning out the single USB 3.0 connection), I'm now trying to connect my B200mini to a Raspberry Pi 2. I was excited when I found that Raspbian has a gnuradio and gnuradio-dev package available, but that excitement quickly faded when I found that it was GNURadio version 3.7.5 and UHD version 3.007.003. I'm not sure if the GNURadio version is an issue, but I know that UHD 3.007.003 is far too old to recognize the B200mini (I tried multiple times before realizing my problem). The GNURadio package on Raspbian works like a charm, but cannot detect the B200mini due to UHD. I have installed UHD from source on the RPi2, and successfully probed the B200mini, but could not get GNURadio to compile from source correctly. If I install a newer version of UHD after installing the gnuradio and gnuradio-dev packages, I get the "uhd_find_devices: undefined symbol" error. I'm trying to find a middle ground. My question is, is there a way that I can update the Raspbian package of UHD that it could both detect the B200mini and I can use GNURadio Companion? Thanks, Michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
