For the most part, decimation cannot be changed at runtime, due to the
way the scheduler does static allocation and buffer management.
On 2017-11-02 13:05, John Ackermann N8UR wrote:
> I'm getting ready to do a Gnuradio tutorial for a local group, and want to
> show the impact of decimation and
Use "unknown PPS" on both of them. The MIMO cable shares both REFCLOCK
and 1PPS signals, so they will both be synchronized to the same time.
On 2017-09-12 16:13, John Shields wrote:
> Thanks Derek,
> No, I hadn't been power cycling between the runs - good point, obviously, I
> should have.
>
I have time-synchronized RTLSDRs using a known, pseudo-random, sequence
injected into the RX inputs using directional couplers. These all had
a common clock so they wouldn't drift apart.
On 2017-08-16 11:57, Derek Kozel wrote:
> It should be pointed out that the hardware based timestamping is
The frequency seperation has to be less than the IF channel bandwidth,
using a tune_request, you can make this happen using the DDC to shift
the two frequencies from within the IF bandwidth.Otherwise, no,
there's only a single synthesizer in each direction.
I'll post an example tune_request l
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 "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
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
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
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
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
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
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
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
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
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
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
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:
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 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.
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 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
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
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,
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
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
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
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
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:
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?
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
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
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
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
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
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
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.
>
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
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
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
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.
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.
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
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
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
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
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.
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
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
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
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-
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
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.
>
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
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 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.
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
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
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)
>
>
I have had similar problems with cheap USB cables that work for
low-speed devices, but utterly fail for higher-speed transfers.
You might as well update to at least Ubuntu 14.04 or even 15.04, Gnu
Radio (via build-gnuradio) is known to work in that environment.
On 2015-08-18 10:42, Mark wrot
There's enough leakage between the TX and RX paths (inevitable) that
your RX will see your TX side transmissions.
On 2015-08-18 03:26, Marius Cachelin wrote:
> Hi All,
>
> I have some issues when using UHD sink and source blocks in same flow graph.
>
> When I transmit data with UHD sink, I
Given that you have an instance in /usr/lib/uhd/utils, that means you
have an install from your distros package manager, and that needs to
be removed before you do a source-based installed.
Also, the usual location from a source install is:
/usr/local/lib/uhd/utils/uhd_images_downloader.py
This is a filterbank (analog) of your own design?
You'll want to use the GPIO interface:
http://files.ettus.com/manual/page_gpio_api.html
The B2xx GPIO API is the same as X3xx, and the example code:
gpio.cpp in the source tree
Can be modified to use the B2xx GPIO facilities.
Now, I'm
The B2xx GPIO J504 GPIO has the same API as X3xx.
On 2015-08-05 13:26, Samith Abeywickrama wrote:
> Hi, I want to control an antenna multiplxer via J504 gpio port. Actually I
> want to have logic 1 and logic 0 in order to switch the multiplxer. But it is
> difficult to find gpio example fo
Jeon:
Gnu Radio, per se, knows nothing of voltage. It just sees digital
samples as delivered by the hardware. What those samples mean in terms
of voltage amplitude as delivered to the antenna port is completely
opaque to Gnu Radio.
The LFRX will easily tolerate an input signal with a voltage
The "use the signal itself" method is something that I've used in the
past for Dicke-switched type systems. The idea was originally described
by Ken Tapping of the DRAO observatory.
The gr-ra_blocks OOT module that I designed includes an "Oblivious
Slicer" block that will produce a difference
I just use the built-in firdes stuff, rather than using an external
designer.
On 2015-07-21 14:38, Marcus Müller wrote:
> Hi Rich, hello Markus,
>
> On 21.07.2015 19:51, Richard Bell wrote:
>
>> GNU Radio has channelizers built-in, but I've not used them yet, so I don't
>> know how far th
I use the PFB channelizer for incoherent de-dispersion for pulsar
monitoring in radio astronomy. It's quite efficient for producing N
equally-spaced channels.
For randomly-spaced, individual frequency-xlating FFT filters might be
better.
On 2015-07-21 13:51, Richard Bell wrote:
> I would a
Well, no matter how "bad" a script is, it shouldn't be able to cause a
segfault
On 2015-07-17 11:16, Jason Matusiak wrote:
>> You could try renaming ~/.grc.
>
> Interesting, I didn't realize that that file existed, thanks. Sadly, it
> of course didn't help me (my luck for today). But at
1 - 100 of 347 matches
Mail list logo
