Hi everybody,
just in case somebody has already been doing it.
What is the best way (if any) to phase&frequency-synchronize two USRP1?
No need to lock them to an external reference. Just need to have the same
instantaneous reference clock on both.
thanks and regards to all the list
vince
--
Hello,
I tried to report a build issue via redmine issues feature.
Unfortunately I am unable to do so. I registered the account "mrothe"
and tried to find the link to report issues with. After I wasn't able to
find it, I asked on IRC and was told that it should be in the navigation
bar. My navigat
Hello,
I'm trying to build gnuradio (v3.5.1-103-ge4693dfb) by doing:
$ ./bootstrap
$ ./configure
$ make
This results in (from configure):
The following architectures will be built:
generic 32 64 3dnow abm popcount mmx sse sse2 orc sse3 ssse3 sse4_a
sse4_1 sse4_2 avx
N
Hi Florian - Interesting observation about better reception when using larger
bandwidths. I tried it out, and yes indeed they do seem better at 1 MS/s
compared with 250 or 500 kS/s -- meaning that more packets are received
correctly at the higher rate than the lower rates. I didn't try > 1 MS/
On Tue, Feb 21, 2012 at 9:14 AM, Michael Dickens wrote:
> Hi Florian - Interesting observation about better reception when using
> larger bandwidths. I tried it out, and yes indeed they do seem better at 1
> MS/s compared with 250 or 500 kS/s -- meaning that more packets are
> received correctly
On Tue, Feb 21, 2012 at 8:07 AM, Markus Rothe wrote:
> Hello,
>
> I tried to report a build issue via redmine issues feature.
> Unfortunately I am unable to do so. I registered the account "mrothe"
> and tried to find the link to report issues with. After I wasn't able to
> find it, I asked on IR
On Feb 21, 2012, at 9:44 AM, Tom Rondeau wrote:
> It's because with the larger bandwidth, the subcarriers, too, have a larger
> bandwidth. The coarse frequency correction is only set to look at so large an
> offset based on a number of subcarriers (+/-5 or 10), so now with the same
> frequency o
On Tue, Feb 21, 2012 at 10:00 AM, Michael Dickens wrote:
> On Feb 21, 2012, at 9:44 AM, Tom Rondeau wrote:
> > It's because with the larger bandwidth, the subcarriers, too, have a
> larger bandwidth. The coarse frequency correction is only set to look at so
> large an offset based on a number of
On Feb 21, 2012, at 10:05 AM, Tom Rondeau wrote:
> Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just
> with the OFDM transmitter?
I do see it with uhd_siggen.py. Didn't know about that utility; cool! - MLD
___
Discuss-gnur
I'm having trouble demodulating the RDS signal that comes along
with a lot of broadcast FM signals these days. I know that there's
"gr-rds" that has already done this, but I wanted to do my own just for
personal education.
I spent a lot of time yesterday playing with it,
and I can't get anyth
On Mon, Feb 20, 2012 at 10:28 AM, Tom Rondeau wrote:
> On Sun, Feb 19, 2012 at 6:29 PM, Ryan Pape wrote:
>
>> I have an application with some nasty race conditions I am trying to
>> pin-point.
>>
>> The application starts with a 256 channel filterbank. Approx 45 outputs
>> are connected to files
Hi Nick -
Sorry, just did 'opkg list-installed | grep orc' and got:
liborc-0.4-0 - 0.4.11-r0.9
liborc-test-0.4-0 - 0.4.11-r0.9
Is this the version you expect for e1xx-002?
Thanks,
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.no
Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it
just with the OFDM transmitter?
What is this tool doing? Transmitting a sine and checking the offset.
Sorry, for the moment I have no possibilitie to check that.
> It's because with the larger bandwidth, the subcarriers,
>
> How to solve this issue?
>
Build with cmake instead :-)
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
exactly 19.0kHz/8?
Are you feeding it the stereo pilot or generating your own?
Have you tried looking at the signal with an FFT scope to see if there
is anything there or if it looks distorted or something?
On Tue, Feb 21, 2012 at 10:35 AM, wrote:
> I'm having trouble demodulating the RDS signa
I'm not feeding it the stereo pilot. I just use a fractional
resampler to resample the few kHz at 19.0kHz/8 --this gives 4
samples/symbol into the DBPSK block.
The spectrum looks roughly
correct--a double-humped structure either side of zero.
On Tue, 21 Feb
2012 12:27:54 -0500, Andrew Davis
So I just did:
(1) UHD: git pull, redo-cmake, build, install, uninstall, install
(2) GNU Radio: git pull, redo-cmake, build install, uninstall
(3) UHD: uninstall
(4) "cd /usr/local" and remove all cruft
(5) UHD: delete cmake directory, redo-cmake, build, install
(6) GNU Radio: delete cmake directo
If I remember correctly, the original RDS feed the stereo pilot to the
DBPSK block as it had the correct symbol phase. From this
https://www.cgran.org/raw-attachment/wiki/RDS/rds.png it looks just
like band passing the pilot and dividing to the correct rate.
On Tue, Feb 21, 2012 at 12:33 PM, wro
On Tue, Feb 21, 2012 at 11:35 AM, Florian Schlembach <
florian.schlemb...@tu-ilmenau.de> wrote:
> Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it
>> just with the OFDM transmitter?
>>
>
> What is this tool doing? Transmitting a sine and checking the offset.
> Sorry, for t
There is a coarse and a fine frequency offset correction. The fine
correct makes sure that the subcarrier is centered in the bin; the
coarse adjusts for an integer number of subcarriers off from the center
frequency. By default, the OFDM receiver will correct for some number of
subcarrier bins (it
Although using the same device to check on said carrier as is
transmitting it leads to compounding error in one direction or t'other.
Best to use another device (preferrably a lab spectrum analyser) to
check the offset.
-Marcus
On Tue, 21 Feb 2012 12:56:30 -0500, Tom
Rondeau wrote:
> On
On Mon, Feb 20, 2012 at 6:32 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:
> On Mon, Feb 20, 2012 at 07:32, Johnathan Corgan
> wrote:
>
> >> If you ever do this again, I would love to see some of the channels over
> >> time. I ordered some basic PLC equipment, but all I really hav
Hi everyone,
First of all thanks a lot for any support!
I am using the XCVR2450 Daughterboard together with the USRP1. My
setup consists of two transmitting nodes and one receiving node, in
which both transmitters send messages in overlapping time slots.
I was wondering how I can access an
On Tue, Feb 21, 2012 at 1:06 PM, Florian Schlembach <
florian.schlemb...@tu-ilmenau.de> wrote:
> There is a coarse and a fine frequency offset correction. The fine
>> correct makes sure that the subcarrier is centered in the bin; the
>> coarse adjusts for an integer number of subcarriers off from
Last time I looked at the XCVR2450 schematic, there was no AGC. Any
AGC would be implemented in software in the end application, and the
PLLs on the XCVR2450 are used to set the center frequency of the
quadrature downconverter. The hardware doesn't "know" anything about
whatever modulations you
On Mon, 20 Feb 2012 07:52:33 -0800
Johnathan Corgan wrote:
> Scratch that, just reread your post. Is your gri_matfile.cc getting
> added to the swig library?
I suspect so, but I'm not sure how to test it (is there a way to check?)
Anyway, I changed the code a little. After checking quite a few
On Tue, Feb 21, 2012 at 10:18, George Nychis wrote:
> Wow... so let me make sure I get this straight. That's just a passive
> reading of the RF spectrum on your wall socket... you are not introducing
> any form of transmission on the line? The USRP N210 was simply just plugged
> in to the power
On Tue, Feb 21, 2012 at 10:45, John Coppens wrote:
> After successful compilation, on running, I find that xxx/top_block.py
> contains the following:
>
> self.gr_matfile_source_1 = >
> cannot find 'repeat': gr.matfile_source($file, $repeat)
> <
On Tue, Feb 21, 2012 at 1:55 PM, Johnathan Corgan
wrote:
> I was, however, able to load up my house wiring through the coupler
> with a few watts at 146MHz and successfully contact a local ham radio
> repeater :-)
>
> Johnathan
Ah - that sounds like one of them fancy 'house-tennas' used to get
a
Yup. When you think about it, I`m surprised the signals levels
weren`t *higher*.
Doug: one of the benefits about living on my own
37-acre spread that I miss is the ability to erect arbitrarily large and
ugly antennas subject only to:
o budget
o wifely approval
On
Tue, 21 Feb 2012 14:0
Hi Folks,
I'm having some fun and games with gnuradio, a USRP1, and trying to
transmit and receive at the same time, using gnuradio-companion.
A Simple [UHD SOURCE] > [UHD SINK] works perfectly, but when I
start to try to do other things, I get a Segmentation Fault from
somewhere.
Even some
On Tue, Feb 21, 2012 at 11:55 AM, Iain Young, G7III wrote:
> Hi Folks,
>
> I'm having some fun and games with gnuradio, a USRP1, and trying to
> transmit and receive at the same time, using gnuradio-companion.
>
> A Simple [UHD SOURCE] > [UHD SINK] works perfectly, but when I
> start to try t
Okay! So apparently there is some interest in power line communication for
GSoC. But, what we would want to do is already have a safe way of
connecting the USRP in to the wall socket for the student(s), and for the
future of GNU Radio and USRP power line communications development.
So, as a goal
I'm willing to bet that your segfault comes from our friend OpenGL:
Try this before you start your application:
export
"LIBGL_ALWAYS_INDIRECT=1"
Also try updating to latest master for Gnu
Radio and UHD. If you're on Ubuntu or Fedora, you can use:
http://www.sbrac.org/files/build-gnuradi
On Tue, Feb 21, 2012 at 3:00 PM, George Nychis wrote:
> Okay! So apparently there is some interest in power line communication for
> GSoC. But, what we would want to do is already have a safe way of
> connecting the USRP in to the wall socket for the student(s), and for the
> future of GNU Radio
On 02/20/2012 06:31 PM, Ben Hilburn wrote:
> Just to add to what Marcus said:
>
> Make sure to put "/usr/local/lib" in /etc/ld.so.conf, and then run $ sudo
> ldconfig:
>
> $ sudo echo "/usr/local/lib" >> /etc/ld.so.conf
> $ sudo ldconfig
>
> http://files.ettus.com/uhd_docs/manual/html/build.html
On Tue, Feb 21, 2012 at 12:18, Brian Padalino wrote:
> Not sure how much they are or where you can even buy them, but they're
> pretty much perfect for this:
>
> http://www.onfilter.com/products.html?s=MSN01
They list two North American distributors, but I couldn't find the
product on either
On 2/21/2012 3:00 PM, George Nychis wrote:
Okay! So apparently there is some interest in power line communication
for GSoC. But, what we would want to do is already have a safe way of
connecting the USRP in to the wall socket for the student(s), and for
the future of GNU Radio and USRP power li
On Tue, Feb 21, 2012 at 12:30, Johnathan Corgan
wrote:
> They list two North American distributors, but I couldn't find the
> product on either distributor's website. I'll give them a call and
> see what I can come up with.
These guys sell it:
http://www.hiscoinc.com/
it is out of stock with
Two issues:
1) Large resistors results in large attenuation. This circuit attenuates
120VAC to ~5V for the microcontroller.
2) You would need to un-ground all of the components (USRP + PC + you) and
float everything to somewhere around 60V
-Original Message-
From: discuss-gnuradio-bounces
I think this is an active module with only receive capability. You may want
to look into Homeplug.org or a phone or Ethernet adapter for bidirectional
interface to the power line.
-Original Message-
From: discuss-gnuradio-bounces+evan=syndetix@gnu.org
[mailto:discuss-gnuradio-bounces+
Well, I'd put it that large resistors result in high impedance. You
still have the full line voltage across the output of the two resistors,
but any load resistance will form a voltage divider and drop the voltage
very quickly.
A simple next step would be adding an appropriate load resistor a
Before anyone goes out there and barbecues themselves with a USRP, two
things:
1) Use Ettus Research products for power-line or hazardous voltage
applications at your own risk and after careful evaluation by competent
engineer.
2) VAC, Gredmann, Hitachi, Magnetica, and other companies make
power-l
-Original Message-
From: Evan Merewether [mailto:e...@syndetix.com]
Sent: Tuesday, February 21, 2012 2:29 PM
To: 'John Ackermann N8UR'
Subject: RE: [Discuss-gnuradio] discussion on USRP-->Wall Socket for Power
Line Comms
May I suggest looking at the schematic at the bottom of page 4 of
Hi all,
I'm working an a little project using gnuradio for receiving ham radio
psk31 signals. I can decode a signal given a rough estimate of the
carrier frequency but I'd really like to take a big swath of bandwidth
as the input, detect the psk31 signals, and decode them all in
parallel.
Howeve
On Tue, Feb 21, 2012 at 13:20, Nick Foster wrote:
> Before anyone goes out there and barbecues themselves with a USRP, two
> things:
>
> 1) Use Ettus Research products for power-line or hazardous voltage
> applications at your own risk and after careful evaluation by competent
> engineer.
Yep.
Hi Marcus,
Thanks for the pointers, You Wrote:
I'm willing to bet that your segfault comes from our friend OpenGL:
Try this before you start your application:
export "LIBGL_ALWAYS_INDIRECT=1"
Tried it, no improvement.
Also try updating to latest master for Gnu Radio and UHD. If you're on
On 02/21/2012 05:05 PM, Iain Young, G7III wrote:
Hi Marcus,
Thanks for the pointers, You Wrote:
I'm willing to bet that your segfault comes from our friend OpenGL:
Try this before you start your application:
export "LIBGL_ALWAYS_INDIRECT=1"
Tried it, no improvement.
Also try updating to
Ben -
Searching for "Automatic Modulation Classification (AMC)", on Google or
IEEExplore, will give you fairly good start =)
Related terms may be: "Peak Detection", "Robust Statistics", and even
"Primary User Detection" (from the cognitive radio side of things).
Cheers,
Ben
On Tue, Feb 21, 201
I'll note that none of my suggestions are actual techniques, but just
keywords that such techniques fall under.
If anyone is aware of actual techniques for Ben to use, that would probably
be more directly helpful.
Cheers,
Ben
On Tue, Feb 21, 2012 at 2:30 PM, Ben Hilburn wrote:
> Ben -
>
> Sear
Hi Johnathan,
The 125MHz interferece (AC) sounded familiar to me so I dug in the archives.
The image below is received at 137MHz @ Los Angeles and they have the
AC lines dangling in the air like a spiderweb. When it gets rainy we see
those 125MHz in our images.
The antenna was ~20m avay from th
On 21/02/12 22:20, Marcus D. Leech wrote:
Hmmm, I had a simultaneous send/receive app on USRP1 a few weeks ago
that SEGVed. I didn't have time to investigate.
But perhaps this is the same issue?
Could you reduce it to UHD+"stuff"+innocuous sink -- does that work?
Sure can. Graph is as follows
On 21/02/12 23:04, Marcus D. Leech wrote:
Sure can. Graph is as follows:
[Null Source] ---> [UHD SINK]
[UHD Source] ---> [Null Sink]
Results are as follows:
Options Block/Generate Options set to QT-GUI : Runs Fine
Options Block/Generate Options set to WX-GUI : SEGV
Options Block/Generate Opt
On 02/21/2012 06:18 PM, Iain Young, G7III wrote:
They was within the same GRC File, although not linked (IE separate
RX and TX chains)
Yup, the precipitating characteristic appears to be that both TX and RX
facilities are in use on the same USRP1.
I was able to reproduce here with a trivial
Tom, Sean,
There's a couple of things here. First, the
Orc volk_32fc_s32f_magnitude_16i_a function is rounding differently than
the generic versions on E100 for some reason. Not fatal, totally usable,
but it makes the QA code fail. Second, the volk_32fc_x2_multiply_32fc_a
looks like it's working f
On Tue, Feb 21, 2012 at 6:43 PM, Nick Foster wrote:
> Tom, Sean,
>
> There's a couple of things here. First, the
> Orc volk_32fc_s32f_magnitude_16i_a function is rounding differently than
> the generic versions on E100 for some reason. Not fatal, totally usable,
> but it makes the QA code fail. S
FYI,
By Marin Blaho and Rob Alblas
http://www.poes-weather.com/~patrik/1.7GHz/lrit-martin.png
http://www.poes-weather.com/~patrik/1.7GHz/xrit2pic_preview.jpg
Patrik___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman
On Tue, Feb 21, 2012 at 16:43, Patrik Tast wrote:
> By Marin Blaho and Rob Alblas
>
> http://www.poes-weather.com/~patrik/1.7GHz/lrit-martin.png
> http://www.poes-weather.com/~patrik/1.7GHz/xrit2pic_preview.jpg
What a thing of beauty.
Excellent job to them!
If they'd consider donating the code
On 02/21/2012 03:30 PM, Marcus D. Leech wrote:
> On 02/21/2012 06:18 PM, Iain Young, G7III wrote:
>>
>> They was within the same GRC File, although not linked (IE separate
>> RX and TX chains)
>>
> Yup, the precipitating characteristic appears to be that both TX and RX
> facilities are in use on
On Tue, Feb 21, 2012 at 5:03 PM, Johnathan Corgan
wrote:
> On Tue, Feb 21, 2012 at 13:20, Nick Foster wrote:
>
>> Before anyone goes out there and barbecues themselves with a USRP, two
>> things:
>>
>> 1) Use Ettus Research products for power-line or hazardous voltage
>> applications at your own
Wicked, thank you. That'll go a long way towards getting me started.
It's frustrating when you're so ignorant you don't even know which
search terms to type in.
On Tue, Feb 21, 2012 at 3:31 PM, Ben Hilburn wrote:
> I'll note that none of my suggestions are actual techniques, but just
> keywords
Hi all,
I'm now using message_sink and msg_queue to receive data from USRP. I do
some calculation for all the data in the msg_queue one by one and write some
of them into a file. Everything seems to be working smoothly. But once in a
while, a "0" is printed in the terminal. (There is no code to
62 matches
Mail list logo
