time_spec_t() is a helper function in class "uhd", it is not a method in
a uhd.usrp_source/sink.
self.cmd_time = uhd.time_spec_t(0.1)
Would be the correct idiom.
On 2015-08-31 15:31, Tibisay Sanchez wrote:
> my line is
>
> self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1)
>
>
Since most SDRs out there have fully reconfigurable-by-the-end-user FPGA
and firmware images, I don't think the notion of "compromise"
has much meaning in this context, further because access to the devices
is freely available to ordinary user-level processes, they can ask the
radio to do whate
Sure, but if the flow-graph basically is decimated 10:1 by the time it
reaches the log10, improvements in log10 are going to have very little
impact. It is, I would assert, boldly and perhaps brashly,
that log10 operations almost never need to be done at "line rate",
since they are an artifice
The PLL not locked error is just because you've (or someone) has asked
for a frequency tuning on the device that isn't possible, so the
hardware is saying "can't do that".
The GCD messsage is a warning. Given the message you should just have
used an interpolation of 1 and a decimation of 2.
One of my "customers" (for multimode and simple_ra) has reported that at
least on his system, the StaticText fields that are updated (at a coupla
Hz, max) expand every time they're updated, eventually leading to an OOM
issue with OpenGL.
The Wx versions are here:
python-matplotlib-wx-1.4.3-3
The "No E4000 tuner found" comes from rtl_test -t which is useful ONLY
for E4000 tuners, and you have a R820T tuner.
On 2015-09-18 08:38, Pedro Gabriel Adami wrote:
> Hello,
>
> I'm tuning a frequency inside of the range of the device, that is, 107.9MHz
> and 95.3MHz. When I blacklist the
Try:
uhd_fft
On 2015-09-18 09:03, Chiara wrote:
> Hi all,
>
> I've installed GNURadio 3.7.8 on Ubuntu 14.04 LTS and I've got two URSP B210.
>
> I think I've got some problems in transmission because when I run the uhd
> example and try to capture the signal sent, I don't see anything.
>
I would load it at the time the block is instantiated, in its "make"
method, and load it into instance-specific data.
On 2015-09-22 06:27, Chad R wrote:
> Good day Marcus
>
> I am using the most recent version of UHD. The problem I was encountering was
> due to the USB buffer not clearing
The failure in libzmq1 is expected--Ubuntu changed package names
mid-stream, so there's no way to tell which of two possible
package-names to use, so it tries for both.
The UHD failure is unexpected, so running:
build-gnuradio -v
Will give more details about errors as it builds.
On 2015-
Yes, although, that will get you a not-terribly-recent GR and UHD...
On 2015-09-22 10:45, West, Nathan wrote:
> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer wrote:
>
>> All,
>> I recently asked the list some questions about getting GNU Radio up
>> and running on a Windows machine (using c
Hrrrm, I was pretty-sure that I'd made that update some time ago.
I'll have to check my master copy when I get home.
On 2015-09-22 11:08, Peter Mathys wrote:
> As noted elsewhere the failure to find libzmq1-dev is expected (what is
> needed is libzmq-dev) and does not affect the outcome o
There will be an RTL2832U, made by RealTek. Its job is to digitize the
output from the tuner, and down-sample, and put it on the USB bus.
There's also an R820T2, which is the downconverter/tuner that converts
to a real IF around (AFIR) 3.57MHz.
There'll also be a voltage regulator or two, an
Since you'd be decimating on the FPGA, your latency would be dominated
by the rate at which you send FFTs to the host. In the scenario
descibed, that would be about 0.01second, plus the inherent group delay
of the filters in the radio, which if you're running at full ADC
bandwidth won't be much.
If the sending machine sets DF in the IP header, then any interstitial
machine that must fragment will drop the packet as well.
Best to stick to MTU-sized payloads with UDP, since IP fragmentation is
handled poorly in many cases--either due to policy, or bad
implementations.
On 2015-09-25 15
Yeah, theyre 32-bit float I and Q, and for CPUs whose native FP format
is IEEE 754, that's what they'll be on disk
On 2015-10-02 12:55, Jason Matusiak wrote:
> I just wanted to make sure I have this right (because I always seem to
> confuse myself); the complex data type is 64bits, 4 bytes o
How much attenuation do you have in the path between the TX and RX? What
daughtercards? Two separate USRPs, or a single, looped back?
If you turn the RX gain up, does the RX FFT change? Are you on the RX2
port on the RX side?
On 2015-10-26 15:33, Washbourne, Logan wrote:
> I looked at the
With antennae, or with a cable, and if with a cable, how much
attenuation in the cable system?
On 2015-10-26 15:54, Washbourne, Logan wrote:
> Tx and Rx are on their own USRP1s, the daughter board is the RFX2400. They
> are roughl 3ft apart from each other on a desk. The Rx side is using th
Consulting now, the book of armaments, errr, UHD manual:
http://files.ettus.com/manual/page_dboards.html#dboards_rfx
The RFX series has no TX RF gain control, output magnitude is entirely
dependent on baseband magnitude.
There's 70dB of gain range on RX, however. So, crank up the RX gain.
You're transmitting at 1MS, and receiving at 250ksps. Your receiver is
only seeing part of your signal.
On 2015-10-27 11:27, Washbourne, Logan wrote:
> The RX side looks drowned out, almost like its all noise.
>
> I'm attaching the pictures, hopefully they make it trough the email filter.
What does the spectral plot look like? It should look very similar to
the TX side of the house.
On 2015-10-27 11:10, Washbourne, Logan wrote:
> Thanks for the info guys! They are both using antennas btw. I came in this
> morning and turned the RX gain up pretty high, roughly 45dB, and the
Try cranking your RX gain up/down 5dB and see how that affects your
constellation.
On 2015-10-27 11:55, Washbourne, Logan wrote:
> Ok, that sampling rate mismatch was my fault. The RX spectrum looks better
> after that fix. The unpacked to packed bits didn't seem to remove the zero
> group
Your center frequency is in the 2.4GHz WiFi band. So, yeah, you could be
seeing lots of interference.
On 2015-10-29 11:41, Washbourne, Logan wrote:
> So I decimated both sides, right in front of the constellation plots. The TX
> side looks a lot better, no zero groupings. The RX side still
You're probably just seeing the group delay of the interpolation filters
on the N210, which for a given configuration,
should be of a fixed and predictable duration.
On 2015-11-13 11:18, Will Thompson wrote:
> Hi
>
> I have question about the latency of transmissions in the N210 USPR.
>
Rebuild Gnu Radio against the new UHD.
On 2015-12-04 10:57, like wrote:
> Hi,all:
>
> unfortunately it becomes incompatible after the uhd update:
>
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.9.0-0,
> but UHD library rep
Quick look.
libairpsy provides an API to open based on serial number. Near as I can
tell, gr-osmosdr hasn't caught up with the newer airspy API.
On 2015-12-18 14:07, Tom Rondeau wrote:
> On Mon, Dec 7, 2015 at 2:23 PM, Mamoru Yamamoto
> wrote:
>
>> Mr. Tom Rondeau,
>>
>> Thank you for
Also, the question is somewhat bifurcated. There are two aspects:
(a) Which parameters in the hardware end of things have advanced, and
at what rate, and what is considered "state of the art". This gets
broken down into a few sub-categories:
o ADC/DAC speeds
o FPGA gate-counts and speed
All of them use reasonably good crystals or crystal XOs. Certainly a lot
better than the RTLSDRs most of these were intended for.
I assume that you're talking about frequency stability, rather than gain
stability?
On 2016-03-30 03:18, Daniel Pocock wrote:
> Hi all,
>
> Has anybody been us
I know that some of them, like the HAMITUP, use a socket for the XO,
which one could easily replace with a TCXO. Check with the
manufacturers about the XO spec they use.
On 2016-03-30 11:43, Daniel Pocock wrote:
> On 30/03/16 16:49, mle...@ripnet.com wrote:
>
>> All of them use reasonably
Tsys is essentially irrelevant for HF receivers, since Tambient is much,
much higher (thousands of K) than even some really-poor RF engineering
scenarios.
At HF, galactic background can be very high--1e4K or more.
On 2016-03-30 10:30, Marcus Müller wrote:
> Hi Daniel,
>
> haven't made exp
How about a thingy that makes a note of the local high-precision time
when the first samples arrive in the work() function, and then somehow
make that available to higher layers, so that you can get a first-order
approximation of the time skew between the streams?
VLBI guys usually have a local H1 maser clock, they go through a complex
synchronization ritual prior to the start of observations. H1 masers
have short-term stability on the order of 1e-16.
GPS synchronization would be a *starting point* for such things.
On 2016-04-01 08:42, madengr wrote:
The main thing is that these bursts are *weak* (< 1Jy typically), and
*short duration*. Detecting a CW weak source with smaller antennae is
feasible, because you can use long integration times. You have no such
option here, unless you're talking about hundreds or thousands of
dipoles, all phase
Yes, entirely feasible if you kind of "fudge and pray" on the practical
realities. Even 10,000Jy is a tiny signal when cast in the context of a
small antenna (2-3dBi).
But can the technical infrastructure be built with relatively-cheap
SDR-based kit, and Gnu Radio? Absolutely.
On 2016-04-01
What if you make the file "/dev/null" -- does this still happen?
On 2016-04-05 14:12, monika bansal wrote:
> Hii,
>
> I am running benchmark code and on the receiver side after receiving some
> number of packets(8000 so), it starts showing overflow errors ("") on
> terminal.
> Follow
Actually, I may have mis-spoke on this one.
I had the gr-osmosdr source block set to "Manual" for DC-offset, and
that, as it turned out, led to a very different DC-offset spike, leading
to misleadingly-different power values.
Turning them both to "Automatic" restored both app sanity, and min
Kyle Keen does GR+friends packaging for Arch/ALARM, and may have some
insights.
I've never tried to run build-gnuradio on ARM platforms, because the
flags required vary from platform to platform, and not that many
beginners are doing this for ARM platforms. YMMV, etc, etc.
On 2016-04-28 12:19,
I use all of my Odroids that run GR in a "headless" mode--I find no
reason to do flow-graph development on the device itself, and processing
flowgraphs in radio astronomy just don't really need a graphical
component to be running on the Odroid.
On 2016-04-28 13:28, Marcus Müller wrote:
> Do you
The PPS input is conditioned with a:
http://www.ti.com/product/SN74AUP1T57/description
Looks to me like it should work just fine.
On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
> Hi,
>
> I'll appreciate any help on the following. According to the link below [1],
> the PPS vol
It's possible that we're dealing with a memory leak somewhere. Could
you watch the memory consumption of simple_ra over time?
Also, could you just run something like uhd_fft with the same sample
rate for long periods to see if it gets the same 'D' treatment?
On 2016-05-03 04:32, John Shields w
The only way the USRP knows that there's a GPSDO present is if the
serial data from the GSPDO is validated. If it doesn't see that data,
it concludes that there's no (internal) GPSDO present.
There is no concept of "external GPSDO" -- only that *something* is
providing 10MHz and 1PPS externally.
This has me thinking that this is a PHY-layer issue.
How long are your Ethernet runs, and are you using Cat5e cabling?
On 2016-05-03 12:59, John Shields wrote:
> On 03/05/16 15:01, mle...@ripnet.com wrote:
>
> It's possible that we're dealing with a memory leak somewhere. Could you
> watch
The native BER of 1000BASE-T is better than 1.0e-11 or so.
Which means you'd expect a bad bit roughly every half-hour at 2msps
(64Mbit/sec), the bad-bit probabilities get worse as you make the cable
longer.
On 2016-05-03 12:59, John Shields wrote:
> On 03/05/16 15:01, mle...@ripnet.com wrote:
What you're going to need to do is provide the *simplest* flow-graph
that demonstrates the issue, rather than requiring the community to
debug your entire end-to-end setup.
Also a diagram of your setup showing the RF and 1PPS and 10MHz paths.
On 2016-05-03 15:39, khalid.el-darymli wrote:
> Tha
I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
THINGS" knob in Gnu Radio. The answer to that would be a resounding NO.
If the question is, instead:
(1) Is the Gnu Radio development environment suitable for
*developing* signal-processing chains to decode INMARSAT
(2
I'll comment that the Windows socket implementation isn't in compliance
with the spirit of the robustness principle. But, whatevs. Easy enough
to just remove that option for the UDP case.
On 2016-05-19 08:59, Andy Walls wrote:
>> OK, I was able to reproduce the issue, and it appears to me to a
Not sure how this would get leveraged by itself.
But there are likely lots of kernel calls that have parameters that are
ignored in certain contexts. I would be astonished if a
general-purpose, long-lived, operating existed without that being the
case from time to time.
On 2016-05-19 11:58, An
There are a couple of issues with the rtlsdr driver used by gr-osmocom
in this regard:
(A) The charge-pump loop current is too constrained for the higher
frequencies
(B) The "dither" option appears to have a bias that causes a (small)
frequency offset.
The driver that AirSpy uses fixes bo
The AirSpy uses the R820T2 chip for the tuner, but a different
sampling/DSP "engine".
Yes, making the charge-pump and "dither" mods will help with
phase-coherence.
Somebody needs to "own" the rtlsdr driver, and merge in the last couple
of years of field experience and branching that has gone on
A bias in the dither algorithm could explain that, which is why turning
off dither clears up the problem. The drifting-out-of-lock problem is
due to charge-pump current settings being too low in some cases.
On 2016-05-26 11:47, Juha Vierinen wrote:
> Would either of these issues in the rtlsdr d
Use a subdev spec of:
A:0 B:0
And specify the RX2 antenna for each channel.
On 2016-06-16 08:08, olvhammar wrote:
> Hi,
>
> I have a Ettus X310 and two UBX-160 daughterboards. I'm looking to receive on
> RX2 on each card simultaneously.
> How should I specify the subdev spec in my python/g
Among SDRs, there is no universal "model" for things like total gain,
acceptable baseband magnitudes, etc. Even if there were, expected
variations in analog behavior mean that you usually have to tweak things
to make it work across multiple hardware. That's just an attribute of
the analog world th
I just forked Keenerd's repo, which actually has support for turning
dither on/off in the API, but of course, gr-osmosdr has no support for
it.
My fork is:
https://github.com/patchvonbraun/rtl-sdr
Also the difference in frequency resolution with dither on/off is very
small--less than the erro
The "PLL lock messages" are normal during start-up for the gr-osmosdr
rtl-sdr driver.
SO, on your liveDVD image, you could do something like:
osmocom_fft -a rtl=0 -f 101.1e6 -g 30 -s 1.0e6 --fft-rate 10
Does you radio station show up on the FFT display?
On 2016-07-04 11:49, Darin Decker wro
The windows installer from that site seems to have been linked against
UHD 3.9.3, which is why the mismatch. There was no reason to have
separately installed UHD, since UHD is listed as a package that is
bundled into the installer.
I would remove the 3.9.4 UHD you have if you plan to use Gnu Radi
The installer that you used to install GNU RADIO *includes* UHD. You
now have newer UHD interspersed with the version that came bundled with
your GnuRadio install.
On 2016-07-05 11:33, Sanat Kumar Mishra wrote:
> UHD 3.9.36 is the latestv version of USRP Hardware Driver available. If I
> unin
WHat specific hardware line-up do you have?
You have to use set_time_unknown_pps(), but also, if you want phase
alignment (as opposed to mere coherence-with-an-offset), you need to use
timed tuning commands across your systems. This will result in zero
relative phase offset between boards, if you
That is precisely what I'm saying, and precisely what timed-commands for
tuning were invented. On certain hardware, after the tune is complete,
a phase-reset pulse is sent by the FPGA. The only way for THAT to have
the desired effect is to make sure that the phase-reset pulse happens at
the same i
X3xx images include both firmware and FPGA cod.e
On 2016-07-06 12:10, Sanat Kumar Mishra wrote:
> We have unistalled the UHD 3.9.4 and flashed the image of UHD available with
> the GNUradio which is:
>
> C:\Program Files\GNURadio-3.7\share\uhd\images\usrp_x310_fpga_HGS.lvbitx
>
> my question
You wanted to use the packaged Gnu Radio, which packages UHD 3.9.3, so,
that header show the correct version coming out of the UHD version that
is packaged with the GNu Radio package for windows.
I asked you to remove the UHD 3.9.4 package that you'd installed
separately, because it was in confli
Is this an Octoclock, or Octoclock-G?
If it's just an Octoclock, then it has no internal clocks, and acts as a
high-quality clock/pps distributor.
I notice you don't have the external clock inputs connected to anything,
and there's no GPS LOCK indicator.
On 2016-07-07 17:08, Pavan Yedavalli w
Pavan:
Do you have any way of verifying that you have 1PPS and 10MHz coming out
of those ports on the Octoclock-G, as seen at the ends of the cables?
[Looking for both the broken-Octoclock and broken-cables case].
On 2016-07-08 00:12, Pavan Yedavalli wrote:
> It's an Octoclock-G (https://www.
Any type of active GPS antennna will work.
If you're using a passive antenna make sure you have a DC block in
place--some antennae are DC shorts.
On 2016-07-11 16:16, Pavan Yedavalli wrote:
> Hi Marcus,
>
> Is this the only type of GPS antenna that I can use on the Octoclock-G?
> https://www
Note that the FX series (at least, some of them) use a shared FPU
arrangement.
Having said that, I have an FX-8350 system that does fairly well with 6
receivers operating at 2.56Msps, doing correlation interferometry
(computing 15 visibility functions in parallel for the 6 receivers).
On 2016-0
Yeah, the entire FX series (I think) has a single FP-unit per *pair* of
cores.
This is in contrast to that which went before, the Phenom II X6, for
example, had 6 FP units.
On 2016-09-22 12:53, Anon Lister wrote:
> The AMD only has 2 floating point units too, they just define "core"
> differe
They load their operating code (FPGA + CYPRESS FX2) over USB
dynamically.
If you have a recent version of UHD, you should also have the images for
these devices.
What does "lsusb" show for the USRP1 and B100 when you plug them into
the USB bus (with external power--these devices won't take powe
This is 6MHz, centered at 611MHz (a notionally-TV channel that is
allocated in North America and Caribbean to Radio Astronomy).
I used a PFB channelizer with individual detectors, and then delay
adjustment after the detectors and then simply added, low-pass filtered,
then resampled to a precise m
Yes, they are Digiwave ANT2084--available on-line through WalMart as it
happens. But any similar 4-bay antenna will work.
We use 6 of them in a 2 x 3 array. I was using a commercial combiner,
but it was lossy and had poor phase balance (actually any hybrid-tree
style combiner will have issues i
Keep in mind also that B0329+54 is really the only one within reasonable
"reach" for an amateur in the northern hemisphere--the others are much
fainter, although if one simply added another "gulp" of antenna every
paycheque or two...
Also, you need a stable clock--I'm using an OCXO, but a TCXO wi
Effective integration time was about 40 minutes.
The beamshape is roughly 42 x 18 degrees from our array antenna.
On 2016-12-01 15:54, Daniel R. Marlow wrote:
> Hello,
>
> First, congrats to Marcus and CCERA.
>
> We are working at 21 cm (1420 MHz) and find that there are at least a few
No data are dropped, but there will *always* be a disturbance in the
analog domain when you're changing the synthesizer frequency. PLLs
require a non-zero time to "lock", which means they converge to the
correct frequency over some small time interval (a few msec, typically).
Along with this, the
If your flow-graph is GRC based, then any block parameters that can be
changed at runtime can be tied to a variable.
Once you have that, then you can use, for example, XMLRPC to set any
variable in the flow-graph from the "outside world" (which includes
"reflexive" setting from non-flowgraph pyth
Meh, I use function probes to capture 'stuff' that changes
slowly--timescales of seconds or tens-of-seconds.
I wouldn't do this for faster stuff, but doing that allows you to use
"ordinary" python in a python module, with the probe value as calling
parameter.
On 2016-12-21 11:47, Marcus Müller
http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
Should help
On 2017-01-04 12:37, Sean Horton wrote:
> I have my flowgraph set up so that parameters such as rx and tx frequencies
> can be changed while running, and it's being sent two frequencies to listen
> to, freq1 and fre
There are a whack of approaches to doing this.
The filename parameter of the filesink block is runtime changeable.
You could have an external process using controlport or xmlrpc to change
this setting (from a variable) at regular intervals. The existing file
will be closed, and a new one start
If you want strict control over the file-size, then you'll likely need
to write your own block.
It should perhaps NOT come as a surprise that there aren't examples that
cover every possible use case, since the field-of-endeavor is
essentially-infinite, and there's only a finite number of entities
We're going to need more of a description about how things are
connected--do your USRPs have dedicated ethernet connections per
computer, or are they connected to the same ports that your computers
use to talk to the rest of your network?
On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote:
> Hi Marcu
OK, so, dedicated ethernet cards on each computer for the N210s?
If so, those are, unless you turn each machine into a router that "plays
nice" with the local network infrastructure, *private*
connections--dont' think of them as network connections but a bus
connection between your computer and t
Phase is a relative measurement. Against what are you measuring the
incoming phase?
You can measure a PSK signal instantaneous phase-shift by computing the
arctran2 between adjacent critically-sampled samples. But there's no way
to look at a signal and say "what is its absolute phase" without ha
The baseband signal is simply mixed with the LO in the hardware.
On 2017-03-28 13:46, John B. Wood wrote:
> Hello, all. When I connect a GRC "Fast Noise Source" block output to the
> input of a "UHD: USRP Sink" (an Ettus E310) and connect a spectrum analyzer
> to the Tx port on the E310 I can
Why not do the spectral and power analysis steps within GR, having it
log summary data every few seconds, instead of raw data at high rate. I
mean, that's what GR is good at.
On 2017-04-07 14:53, Ellie White wrote:
> Hello,
>
> As I've mentioned in an earlier email to this list, I'm working o
My guess is that you're operating over USB-2.0, which can only sustain
an *aggregate* (TX and RX) of ca 8Msps, as far as I know.
On 2017-04-17 12:17, Santos Campos wrote:
> Hello!
>
> I'm trying to use a b200mini to implement a relay with 6MHz of bandwidth.
> Would it be feasible to do this a
Just use:
complex(math.cos(angle-in-radians),math.sin(angle-in-radians))
As the constant in a multiply-const block
On 2017-04-18 10:23, Trejo Treviño wrote:
> I am trying add a phase-shift to my signal via the use of a multiply block,
> but I have not been able to find the correct inputs fo
You might also try specifying num_recv_frames=128 or 256 in the device
args, to see if that helps the USB subsystem
On 2017-06-05 15:15, Marcus Müller wrote:
> Hi Pierre,
>
> that looks more like a USB communication breakdown than an issue with
> your software.
>
> just as a quick test: if you
Thanks, George.
Two things:
Could you try updating to the most recent UHD version?
It would be helpful if you provided your .dat files in the form of plots
or graphs, highlighting the areas you consider "distortion". This will
help us help you.
On 2017-06-13 07:23, George Vardakis wrote:
I'm having a hard time seeing a significant functional difference
between the two. Could you perhaps explain?
Also, maybe a diagram showing the two configurations?
Do you get any error messages during a run?
Are you doing reception on the two USRPs within a single flow-graph, or
two separate
In the two-USRPs scenario, one of the USRPs is transmitting, and one is
receiving?
Are they "through the air" or over a cable. If over a cable, how much
attenuation has been added to the cable.
On 2017-06-13 11:16, Manolis Surligas wrote:
> Ok lets explain a little bit more what actually you
Is it not the case that a given instance of a block is only ever
executed by a single thread, so instance variables
are completely safe to modify in-flight?
There are exceptions, of course, like in FFTW, only a single thread can
be "planning" at a time, due to the
way FFTW does its thing
Yeah, so, a little cerebral flatulence on my part.
I think the problems come in with variables that can "change shape"
during a setting operation, which could lead
to horrific badness if the "shape change" happens while the work
function is using the variable. Imagine a
private buffer wh
The vector sink is for debugging only. Don't use it in production code,
because there's no convenient way to
vacuum it out, so it grows without bound.
When I've had this problem, I use a vector-probe block, and have a
function probe running at a couple of Hz,
and then leverage the depend
Again, if one uses the vector-probe block, one can call the appropriate
function from a function-probe, at that point, you have a variable with
the contents of the FFT output vector in it, which can be used in a call
to your
own Python code.
On 2014-10-17 12:01, Brad Hein wrote:
> This sou
Have you tried the OpenBTS mailing lists?
OpenBTS is *NOT* a Gnu Radio application, although it uses the same
hardware as some Gnu Radio
apps, it's not a Gnu Radio app itself.
On 2014-10-20 15:15, Mostafa Alizadeh wrote:
> Hi all,
>
> Is there anyone who used OpenBTS-UMTS [2] with USR
Dan:
That's generally good advice, with the single exception of the BASIC/LF
card family--they don't have any gain--they're just ADC/DAC buffers, so
it's generally safe to loop them directly.
On 2014-11-11 11:27, Dan CaJacob wrote:
> Hi Lucas,
>
> You say you connected TXA to RXA directl
Further, I'm not sure that benchmark_tx/rx can actually do bit rates as
low as 240 bits/second, because the have a fairly-simple symbol-rate
model, and the USRP1 can only support sample rates down to 192k.
You said that uhd_fft also produced 'O' indications--what parameters
were you using with
What is the magnitude of the frequency drift?
What is the magnitude of the gain drift?
What are you measuring backscatter *from*?
On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote:
> Hi,
>
> Given a set of synced _(i.e., using external GPS REF/PPS)_, time-commanded
> and cali
You haven't stated which USRP motherboard platform, but I assume you're
talking about the USRP1, given the 4RX image. Yes, the samples
will be aligned in time, but the relative phase will be random every
time you re-tune or start a new session.
On 2014-12-08 06:03, Nemanja Savic wrote:
> Hi
The N2xx series use a fixed sample rate, so there's no "deciding what
sample rate to use based on Fc".
There's also the analog bandwidth of the ADC to consider. If you aren't
going to use a downconverter card, then the analog bandwidth of the ADC
will start to roll-off at some point, so even i
See "to enable OpenGL sinks" here:
http://sdrblog.wordpress.com/gnuradio-installation/
You'll use "style=nongl", instead of "style=auto" or "style=gl"
On 2014-12-18 14:25, Richard Bell wrote:
> Yes I'm using Unity. I forgot to mention my hardware, which is an N210 with
> WBX daughterboa
milar. You'll have to research how to adjust that on Ubuntu under
Unity, since I don't know myself.
On 2014-12-18 15:24, Richard Bell wrote:
> The key setting that mleech pointed out was setting the fft-rate lower,
> uhd-fft --fft-rate 5.
>
> I suppose the N210 can't
That would require wholesale reworking of GRC.
You *really, really, really* shouldn't think of a lowly banana-pi as
your *development* environment. The .py files that are generated by GRC
can be generated on a "real" machine, and executed on the banana-pi,
provided that you have identical GR i
There's a uhd.tune_request() function mapped into Python land, so you
can use the result of that as the "freq" parameter in a UHD sink block.
On 2015-02-10 13:55, Jon West wrote:
> When I transmit a signal at a certain frequency there is a large spike at
> what I have set the center frequen
1 - 100 of 347 matches
Mail list logo
