Hello,
>Has anyone actually managed to successfully install and run the latest
gnuradio in Windows 7
Yes, but not using those instruction, building from source is much more fun
:), but they look like they worked for you outside of that error.
Also If you Google your error other people are having
Hello,
If the buttons aren't working then the thing is probably locked up, try
lowering the fft_rate parameter and see if that fixes things.
Andrew
On Mon, Dec 23, 2013 at 3:10 PM, Paul B. Huter wrote:
> I have a data file that was recorded to a RAMDisk and transferred to the
> hard drive on m
Right, I've played with MAVlink before and as said it is not a wireless
standard, you can send it over hard link serial if you want. I'm assuming
your are sending the MAVlink over a pair of serial-RF adapters as is usual.
http://copter.ardupilot.com/wiki/common-using-the-3dr-radio-for-telemetry-wi
> May be there are ways to generate a standalone executable.
I do this on windows, if you are looking to distribute binaries then
re-write the python flow-graph in C++, then compile and you will get a
portable binary exe, if the other system does not have Gnuradio then just
include the gnuradio*.d
Hello all,
I just freshly installed Xubuntu 11.10 and installed Gnuradio with the
build_gnuradio script with out any problems. When I use uhd_fft.py or any
program that uses the FFT sink ( all other sinks work ) I get a very
strange problem, as long as some part of the FFT plots line is hidden it
of GNU Radio do you have? What about the
> relevant Python packages?
>
> Cheers,
> Ben
>
>
> On Sun, Dec 18, 2011 at 12:53 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I just freshly installed Xubuntu 11.10 and installed Gnuradio with the
>> build_gnur
Hello all,
Some programs don't let you specify a subdevice, they let UHD decide, in my
case it picks wrong. Is there a uhd config file to chose the default
subdevice if one is not specified ( I also wouldn't have to type "--spec
"A:0" so much ).
Thank you!
Could you give me a hint? How do you interface with UHD before a C++/python
program requests the device?
On Fri, Dec 23, 2011 at 3:21 PM, Marcus D. Leech wrote:
> > Hello all,
> >
> > Some programs don't let you specify a subdevice, they let UHD decide,
> > in my case it picks wrong. Is there a
I see what your saying but typing "--address 'type=usrp1' --spec 'A:0'
--antenna 'TX/RX'" every time wasn't my problem.
The problem is programs that let UHD pick the default device, I don't know
how UHD chooses but it could check ~/.uhd/uhd.conf
or something instead of guessing. As you said I could
011 at 8:23 PM, Andrew Davis wrote:
>
>> I see what your saying but typing "--address 'type=usrp1' --spec 'A:0'
>> --antenna 'TX/RX'" every time wasn't my problem.
>> The problem is programs that let UHD pick the default device, I d
l offer no
easy way to change what UHD picks.
On Fri, Dec 23, 2011 at 10:18 PM, Tom Rondeau wrote:
> On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis wrote:
>
>> That might work, but why worry about people who reconfigure just yet, us
>> who use the device consistently still have to
look to UHD_CONFIG_DIR or GNURADIO_CONFIG_DIR first
then check other spots. Also I don't think anything will have to be done in
python as UHD already returns its selection to python when you ask for a
device.
On Wed, Dec 28, 2011 at 9:39 PM, Tom Rondeau wrote:
> On Sat, Dec 24, 2011 at 6:52 AM,
2011 at 9:27 AM, Andrew Davis wrote:
>
>> It's going to have to be part of UHD because a lot of programs I'm having
>> problems with are not using GNUradio, they just read from UHD.
>>
>
> It seems like there is a lot of effort going into fixing problems wi
Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
Languages, and Ideas.
And that's not always a bad thing, it can allow great flexibility, but
sadly it is currently doing the opposite. With required versions of SWIG,
Python 2.x/3.x and other helper programs it ONLY compiles
Well it's not the language choice, it's all the helper programs that are
version locked that annoy me most. Python is in a weird state of limbo
right now with the version 3 switchover. Many systems are defaulting to
python 3 and we should probably do the same. Python would work great if I
was just
s, my goal
at some point is to put 3.3.0 or newer in the FreeBSD ports tree.
On Fri, Dec 30, 2011 at 3:35 PM, Marcus D. Leech wrote:
> Andrew Davis writes:
>>
>>> FreeBSD user forced into Ubuntu as no other operating system can compile
>>> GNUradio since 3.2. OK sorry fo
For us following along at home, do you think you could give us a running
command list? I just finished getting UHD installed with just "cmake
-DLIBUSB_INCLUDE_DIR=/usr/include -DLIBUSB_LIBRARIES=/usr/lib/
libusb.so ../" , someone should put UHD in the ports collection, it
compiles very easily. But
s other
libs in there but not qwt ( and libqwt.so is present )? I tried --prefix
/usr/local but that does nothing. Any Ideas on why qwt is so special?
On Sat, Jan 7, 2012 at 5:04 PM, Tom Rondeau wrote:
> On Sat, Jan 7, 2012 at 1:53 PM, Andrew Davis wrote:
>
>> For us following along
so I cant pin down exactly where there at, does anyone have a mirror with
"uhd-3.3.1.tar.gz" or similar file on it?
On Sat, Jan 7, 2012 at 6:10 PM, Andrew Davis wrote:
> I dont think this is BSD related but ./configure cant find the qwt headers
> "checking qwt/qwt_math.h pr
Great, I cant wait for the script, but also maybe we could work on a
Makefile so we could update the ports, i'm working on one but cant find
tarballs for UHD, the links are all redirects and the tarball name changes,
there really should be a "uhd-3.3.1.tar.gz" somewhere. After that just "cd
/usr/po
2012 at 12:45 AM, LRK wrote:
> On Tue, Jan 10, 2012 at 08:46:55PM -0500, Andrew Davis wrote:
> >
> > Great, I cant wait for the script, but also maybe we could work on a
> > Makefile so we could update the ports, i'm working on one but cant find
> > tarballs for
Yeah, I asked about that earlier, for some reason qwt is hard coded to
/usr/include in the configure script. It really should just use the system
path and not check just one predefined path, this also is a problem on
Gentoo and any other OS that uses "/usr/local/" instead of "/usr/".
What the conf
It worked for me other than the qwt so I think so.
On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum wrote:
>
>
> On 01/11/2012 06:55 AM, LRK wrote:
> >
> > I do not find anything in the README about qt4 or qwt but they seem
> > to be required for gr-qtgui.
> >
> > I used portinstall to install py
I did that and is works, I was just saying that's the only thing that is
keeping it from being a simple "./configure && make install".
On Thu, Jan 12, 2012 at 8:56 PM, Tom Rondeau wrote:
> On Wed, Jan 11, 2012 at 9:27 PM, Andrew Davis wrote:
>
>> It worked f
Hello all,
I have added some simple build instructions for FreeBSD to the wiki :
http://gnuradio.org/redmine/projects/gnuradio/wiki/FreeBSDInstall
These are off the top of my head as I do not have access right now to a
clean FreeBSD install to test, If someone could walk though them on a clean
sys
Type " uhd_find_devices " into console, then " uhd_usrp_probe " then give
us the results, and the code for the program you're trying to run.
On Fri, Jan 27, 2012 at 9:39 AM, shashank gaur wrote:
> Hello
>
> I am simply trying to build a transmitter and receiver for bpsk modulation
> and demodulat
>One thing that I noticed was that the --tx-amp=0.8. That's very high for
OFDM with it's large PAPR.
I'm thinking that too, there really should be some kind of warning when you
drive the DAC to saturation.
If you need more range use an external amp.
On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau
**
> On 31/01/12 08:37 AM, Andrew Davis wrote:
>
> >One thing that I noticed was that the --tx-amp=0.8. That's very high for
> OFDM with it's large PAPR.
>
> I'm thinking that too, there really should be some kind of warning when
> you drive the DAC to satura
Well the core ( nec2 ) is open source and so runs on linux, but your GUI (
EZNEC+ ) is not. You could try Wine, I believe 4nec2 works well with it,
4nec2 is a much more advanced program too.
On Tue, Jan 31, 2012 at 7:48 PM, Patrik Tast wrote:
> **
> Hi All,
>
> Do you know of an/any antenna softw
; Wine seems to be needed if...
> It would be a perfect "task"/thesis for a student group to make a *pure*
> crossplatform one.
>
> Patrik
>
> ----- Original Message -
> *From:* Andrew Davis
> *To:* Patrik Tast ; discuss-gnuradio@gnu.org
> *Sent:* Wednesd
This just means your PC is not fast enough to sample at that speed and
update the window. Try keeping the sample rate low.
On Sat, Feb 4, 2012 at 2:50 AM, davood ahmady wrote:
> hello all
> when I run uhd_fft.py and change sample rate from 1 to 2 the graph is
> being locked and i couldnot change
Well that should be fast enough, could you give us the exact command you
used to start uhd_fft.py
Also what do you mean by "installing ubuntu 10.04 using windows installer",
are you running linux in a VM?
On Sun, Feb 5, 2012 at 3:11 AM, davood ahmady wrote:
> Hello Andrew
> thanks for your repl
Hello all,
I would like to help expand the C++ API, so I'm attempting to work on
Feature #394 or "Re-implement hierarchical blocks currently living in blks2
in C++ and put into gnuradio-core/src/lib/hier." I've started on
am_demod.py but this requires optfir, which is also in python, I think this
Thanks, I think i'll work on QA too while i'm at it then.
On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau wrote:
> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I would like to help expand the C++ API, so I'm attempting to w
self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) will take forever, the
whole front end has to re-settle. How far are you moving the center
frequency? If it's less than 50MHz you could change the sin signal
frequency. You could even hook up a Frequency modulator and change the
frequency continual
> So if someone knows how I can implement a callback or a polling function
> to make the device tune for real, but as fast as possible, that'd be
> very helpful.
>
> Best,
> Marius
>
>
>
>
>
>
>
> On 02/09/2012 10:41 PM, Andrew Davis wrote:
> >
http://gnuradio.org/doc/doxygen/modules.html is a good place to browse what
available.
2012/2/15 Wu Ting
> Hi Tom,
>
> ** **
>
> Thank you very much for your detailed explanation. That really works!
>
> ** **
>
> I really want to learn more about GNURadio by myself. But I don’t know how
They are gonna think they can fire up GNURadio and start decrypting likes
it a program. Followed by a influx of "GNURadio is crap" comments...
On Wed, Feb 15, 2012 at 2:33 AM, David I. Emery wrote:
>
> GoMo News
>
> February 13, 2012 Monday 12:43 PM EST
>
> Warning of increased GSM + TETRA attack
Well some major GNUradio program would drive up sales of USRP's :)
Back on topic, IMHO Gnuradio's problem with large apps stems from it
trying to be the source to sink and everything in between of a radio.
Lets take DREAM for example, they do transfer functions and digital
AGC and the likes that G
GNURadio framework.
On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner wrote:
> Andrew,
>
> Am 15.02.2012 19:41, schrieb Andrew Davis:
>
>> Well some major GNUradio program would drive up sales of USRP's :)
>>
>> Back on topic, IMHO Gnuradio's problem with large
s where gnuradio
> needs to work in cohesion with other apps then gnuradio can run as part of a
> larger system versus being the only system running. While this might be
> outside the scope of a GSoC project but it's a necessity for gnuradio to
> progress beyond its current sta
The is a lot of really cool reasons for the stereo to be the way it
is, check out http://transmitters.tripod.com/stereo.htm it's an
amazing read.
Also the problem of no stereo signal is probably with modern music,
there is not much difference between L and R anymore, just a single
channel of mass
I was playing with the gr-rds module just last week and if I'm not
mistaken it uses USRP not UHD, so it work until someone gets around to
updating it.
On Sun, Feb 19, 2012 at 12:34 PM, Marcus D. Leech wrote:
> On 02/19/2012 12:29 PM, Justin Kelly wrote:
>
> Hi Marcus,
>
> after your current disco
e signal better, not wasting information and bandwidth
like FM.
On Sun, Feb 19, 2012 at 12:57 PM, Marcus D. Leech wrote:
> On 02/19/2012 12:46 PM, Andrew Davis wrote:
>>
>> The is a lot of really cool reasons for the stereo to be the way it
>> is, check out http://transmitters.
A lot of components you are building don't seem to be necessary on
ARM, try configuring with " ./configure --disable-all-components
--enable-gnuradio-core " to just build the core and then enable only
the parts you need.
On Mon, Feb 20, 2012 at 10:53 AM, Stefan Ott wrote:
> Hello
>
> I am current
:03 PM, Tim Pozar wrote:
> Keep in mind that early stereo recordings were Left/Center/Right as pan-pots
> were not available on some consoles. The stereo release of Sgt. Peppers is a
> good example of this.
>
> Tim
>
> On Feb 19, 2012, at 10:08 AM, Andrew Davis wrote:
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
e, 21 Feb 2012 12:27:54 -0500, Andrew Davis wrote:
>
> 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?
>
&g
"O" means there has been an overflow, some part of your system is not
fast enough to keep up with the incoming data, probably your hard
drive, or you may not have a fast enough CPU to process as the sample
rate you have chosen.
2012/2/22 Wu Ting :
> The output is “O” (Oh) not “0” (zero).
>
>
>
> I
Father of the radio, 155 years old, how far we've come and still using
the same antenna dipole design he made +100 years ago!
On Wed, Feb 22, 2012 at 7:33 AM, Marcus D. Leech wrote:
> ...and hooray for Hertzian waves!
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> htt
Even though it is cyclic the edge of the logo where it fades out makes
natural window function :)
On Wed, Feb 22, 2012 at 10:42 AM, wrote:
> So, anyone done an FFT on the Google Doodle today to see if there's an
> easter-egg inside it? :-)
>
>
>
> On Wed, 22 Feb 2012
message_sink(gr.sizeof_short*2, self.queue, False)
> self.connect(self.source, self.sink)
>
> This is really a serious problem for our application because we want to
> continuously record some data. Does anyone has any idea how to deal with
> this problem, or at least catch this error when
I think the problems with SNR is with the FM Demod, my car stereo can
get RDS as the station fades 40 miles away, but with my USRP has
trouble picking up the stereo pilot from a 50kw station one mile away
( -10dBm ). FM demod is hard for software ( I think GNUradio just uses
a zero-crossing detecto
You are writing to a file in a blocking thread, its not the CPU it's
the hard drive. You should try the program without the write. Then if
it is the problem you should write out to a file on a ram disk then
save it to a real disk later.
2012/2/24 Wu Ting :
> Hi! Thank you for your suggestions!
>
>
ough both have
> an ERP of about 100kW, and both are located on the same transmit tower.
>
>
> I'll send you my 'stuff' once I'm more comfortable with it. The audio
> quality is actually reasonably good, so I think the FM demodulator
> portion is just fine.
>
the API a bit.
On Wed, Feb 8, 2012 at 11:27 PM, Andrew Davis wrote:
> Thanks, I think i'll work on QA too while i'm at it then.
>
>
> On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau wrote:
>>
>> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis
>> wrote:
>
>I'm not happy with the bit synchronization in the decoder function, so I'm not
>releasing this yet.
I won't laugh I promise! :)
On Sun, Feb 26, 2012 at 7:30 PM, Marcus D. Leech wrote:
> Here's a teaser screen shot of what I've been working on.
>
> I'm not happy with the bit synchronization in
Hello All,
I've been recently playing with the ATSC decoding functions and have a
couple questions. First the last time ATSC was discussed in any real
detail was 4 years ago ( according to Google history of this mailing
list ), and the converting of GR0.9 code to GR2.0 was raised, but in
the repos
>[ 25%] Building CXX object
>gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/general/gr_add_ff.cc.o
>/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc: In member
>function 'virtual int gr_add_ff::work(int, gr_vector_const_void_star&,
>gr_vector_void_star&)':
>/home/glneo/gnuradi
PM, LRK wrote:
> On Sat, Mar 03, 2012 at 03:00:14PM -0500, Andrew Davis wrote:
>> >[ 25%] Building CXX object
>> >gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/general/gr_add_ff.cc.o
>> >/home/glneo/gnuradio/gnuradio-core/src/lib/general/gr_add_ff.cc: In mem
The thing in the center is caused by a lot of things, like IQ
imbalances and the distribution of noise towards zero etc. We all get
it when the gain is high. Do you have something you are trying to
detect? Do you have an antenna connected to the right port? What
front-end board are you using? Try 1
This might be related to the problems Martin Braun is having with sse3
volk in the other thread today. Was anything done to volk git recently
that would effect sse3?
On Thu, Mar 8, 2012 at 11:15 AM, MOHD RAFIQ wrote:
>
> I apologise for not being clear, here is the backtrace
>
> [New Thread 0xb21
is really more than enough
> for anything but the most extreme scientific tasks, and floats work a hell
> of a lot faster on almost any processor.
>
> Thanks again,
> Tom
>
>
> On Mon, Feb 27, 2012 at 1:11 PM, Tom Rondeau wrote:
>>
>> On Mon, Feb 27, 2012 at
code, first, I'd prefer
>to do that.
If I can remember what they are, most problems didn't change the
output though ( like unused, redundant, or improper code ).
~Andrew
On Thu, Mar 8, 2012 at 1:32 PM, Tom Rondeau wrote:
> On Thu, Mar 8, 2012 at 1:07 PM, Andrew Davis
> wrote:
&g
Ok, sounds good, also I've only been updating cmake files, is there a
date when the switch from autotools will become official?
~Andrew
On Thu, Mar 8, 2012 at 5:56 PM, Tom Rondeau wrote:
> On Thu, Mar 8, 2012 at 5:40 PM, Andrew Davis
> wrote:
>>
>> >As for the comp
ee some carriers gone and different ones emerged at various
> frequencies.
>
> This is happening in every band.
>
>
> On Thu, Mar 8, 2012 at 7:24 PM, Andrew Davis
> wrote:
>>
>> The thing in the center is caused by a lot of things, like IQ
>> imbalances and the
Wow, sounds good, I've got a bunch of 50KW stations about 2 miles away
and I cannot get any to sound good at all. What receiver code are you
using?
On Sun, Mar 11, 2012 at 7:46 PM, Marcus D. Leech wrote:
> http://www.sbrac.org/files/fm_stereo_test.ogg
>
> This is tuned to a station that's approxi
Doesn't sound as good to me, maybe it's just a bad sample. I for some
reason ( I know the math tells me otherwise ) I find it sounds better
the faster I sample, like 500M. I feel like it has something to do
with more exact following of the FM signal curve or something.
So how exactly does the soft
Use CMake. I don't think anyone wants to maintain autotools and it
really should be removed.
On Wed, Mar 14, 2012 at 11:36 AM, Arturo Rinaldi wrote:
> i'd like to build the latest tarball of gnuradio without the volk module.
> However i get the following errors (you can see them in the attached l
Saw it on Reddit a couple days ago, already have one on order. Then I
might work on making a GnuRadio driver or something for real-time use.
On Wed, Mar 21, 2012 at 3:17 AM, David Kierzkowski wrote:
> The osmocom guys are using a 20$ USB catv tuner as a RF source in gnuradio.
> 3.2MS/s !
>
> htt
t have seen it on Reddit as well.
>
> I have one on order too, and I was also contemplating a GNUradio driver...
> let me know if you want to coordinate.
>
> Sean
>
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto
Use CMake to build, autotools are deprecated and are only used for
package building. They will be removed shortly to remove the
confusion.
On Thu, Mar 22, 2012 at 9:28 AM, sumitstop
wrote:
>
> Hi ,
> Yesterday I was trying to install gnuradio 3.4.0.actually before that I
> patched the files from
urn sampling rates and such. I'll have to
brainstorm a bit for ideas...
~Andrew
On Thu, Mar 22, 2012 at 6:45 PM, Marcus D. Leech wrote:
> On 03/22/2012 11:17 AM, Andrew Davis wrote:
>>
>> Right, but I think the idea here is for $20 why not?
>
> Right, for $20.00, why no
This kinda thing is gonna be incredibly useful even to us with USRP's.
I've been working on a digital voice mode but without a second
expensive USRP I have no way to know what I'm broadcasting or how
reliable the modulation is. The uses for cheap, semi-disposable SDR's
are limitless!
~Andrew
On T
> free weekend
I had one once!
So any plans for the application specific top-level blocks ( noaa,
pager, atsc )? I feel these could be moved to the CGRAN, or better yet
there could be a separate top-level folder for projects like this and
some of the GCRAN projects could be merged back into the ma
I have a C++ port of optfir waiting to be merged you could look at:
https://github.com/glneo/gnuradio-davisaf/tree/master/gnuradio-core/src/lib/general,
it's in there, its the gr_optfir*. It has a few bug-fixes from the
python code.
On Sun, May 13, 2012 at 4:15 PM, Alexandru Csete wrote:
> On Sun
Although they are not technically required, python-support,
gnuradio-companion, gr-utils, and gr-wxgui are almost necessary to get
anything interesting done. Also i'm not sure UHD is required for the
RTLSDR, I think it uses it's own module ( or just write samples to
disk and process later with Gnur
well lets start with the cmake output, post everything it says here
and lets see what up.
On Sun, May 13, 2012 at 11:43 PM, Phil wrote:
> On 14/05/12 13:16, Andrew Davis wrote:
>>
>> Although they are not technically required, python-support,
>> gnuradio-companion, gr-ut
Hello all,
I was thinking Gnuradio might benefit from an online message board
style forum. It would be easier for beginners not familiar with the
workings of mailing-lists and would IMHO allow for easier message
traversal for people to find previously solved problem. Has there been
any considerati
>Are some for sale?
Just the broken ones :)
On Tue, May 15, 2012 at 6:35 PM, Patrik Tast wrote:
> Are some for sale?
>
> P
>
> - Original Message -
> From: Songsong Gee
> To: gnuradio mailing list
> Sent: Tuesday, May 15, 2012 20:57
> Subject: [Discuss-gnuradio] Too weak Tx power daughte
It's not OpenGL, it's badly designed OpenGL drivers, saying OpenGL
sucks is like saying C is slow, it can with a bad implementation, but
by its self no. Back on topic, I too have had all sorts of problems
like this with WX FFT, but it's a different error on each OS on each
system 0_o. I have to jus
It's up to the driver writer to handle missing components properly,
Mesa has a full software OpenGL stack, I never thought about it but
i'll try using that and see what errors I get.
On Tue, May 15, 2012 at 10:30 PM, Marcus D. Leech wrote:
>> It's not OpenGL, it's badly designed OpenGL drivers, s
Success, with a pure software renderer WX FFT works. Not sure why the
Intel graphics drivers doesn't play nice, but I don't think the WXGUI
code is to blame ( not that I doubted you :). OP try switching drivers
and see what happens.
On Wed, May 16, 2012 at 11:30 AM, Nowlan, Sean
wrote:
> Someone
3D performance on everything else sucked, but the FFT was exactly the
same, I think it always uses software for line drawing, just the
software in the GPU drivers isn't as good as the full software driver.
To switch, just change the driver line in your xorg.conf, I changed
mine to " Driver "vesa"
https://wiki.archlinux.org/index.php/Xorg#Monitor_settings
This section should work for any modern X environment.
What we really need to do is find a way to just tell OpenGL to use
software only, I remember something about this from my video game days
( the GL in my email :) ) but cant seem to re
There has been a lot of discussion about getting useful output, most
of the threads never go anywhere ( or at least not enough ). What I
believe really must be done is remove the python <-> C++ callbacks and
re-write it in one language ( Something that wasn't possible when it
was written ), and it
I would assume GNUradio's OFDM is mathematically identical to Hydra,
have you tired finding what settings ( Channel spacing, FFT size,
Number of sub-carriers, Sub-carrier modulation scheme, symbol length,
guard interval, Sub-carrier spacing, and FEC ) hydra uses and setting
GnuRadio to that. It sho
xample, on what kind of host-pc, what kind data rate have you reached,
> with how much packet loss rate?
>
>
> On Wed, May 23, 2012 at 5:29 PM, Andrew Davis
> wrote:
>>
>> I would assume GNUradio's OFDM is mathematically identical to Hydra,
>> have you tired fi
Other then the Mesa software only stack it does not work on any Intel
or ATI driver provided stack, but nVidia blob driver DOES support it.
WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often
get locked up i7's so this is a problem ), wxfft realy needs a c++
re-write if anything.
O
I didn't see that may 9th post. I could get some samples ( USRP with
rubber duck with clear sky, would that work? ).
Does anyone know how to feed RTKNAVI? What format does the file need to be?
On Fri, May 25, 2012 at 12:06 AM, Chris Beaumont wrote:
> Hello,
>
> A while ago (May 9) there was a po
I would recommend file sources, you can filter, graph and demod them
w/o hardware.
On Mon, Jun 4, 2012 at 10:32 AM, David Powell wrote:
> Is there a list of tcp sources which are being openly shared? I just
> installed gnuradio and I don't have any hardware yet. I would like to be
> able to see l
> intel_do_flush_locked failed: Invalid argument
This is a problem with Intel graphics drivers.
Switching to a software graphics stack ( Mesa ) worked for me.
On Tue, Jun 5, 2012 at 10:48 AM, Alexandru Csete wrote:
> On Tue, Jun 5, 2012 at 4:39 PM, Michael Hartje
> wrote:
>> Hello list readers
If it's with his own phones it's a grey area, for others obviously
it's not legal. USRP's can get into a grey area when not used as
"Testing Equipment" pursuant to
http://www.law.cornell.edu/cfr/text/47/15.121 .
To answer your question, both USRP1 & 2 can handle the signal, so it's
up to your pref
You are almost certainly sampling faster than your computer can
handle, the queue gets backed up and WXFFT stops responding to GUI
messages, sample at a slower rate. My old PC can not do more than 1
Msps w/o locking up.
On Wed, Jun 6, 2012 at 4:11 AM, Luong Tan Phong wrote:
> Hi lists,
>
> I've i
gr_freq_xlating_fir_filter_xxx_0 is not connected, connect it to something.
On Sat, Jun 9, 2012 at 1:35 AM, Phil wrote:
> Thank you for reading this.
>
> I have one last error to overcome:
>
> Error 0:
> Block - gr_freq_xlating_fir_filter_xxx_0 - Frequency Xlating FIR
> Filter(gr_freq_xlating_fir
The rational resampler is part of BLKS2 which is python only. I'm
currently working on porting blks2 over to C++ so the API will not be
python only, but there is a lot of python code it is built on that
needs to be converted first so it could be a bit. You could just do it
yourself, all the rationa
>So I suppose if I do the same thing it would work right?
Only one way to find out, try it.
On Wed, Jun 20, 2012 at 11:02 PM, Stephen wrote:
>
>
> On 6/19/2012 11:50 PM, Andrew Davis wrote:
>> The rational resampler is part of BLKS2 which is python only. I'm
>
> th
Hello all,
Not sure if this belongs here, but I found an old wireless gameboy
messager (
http://www.amazon.com/Game-Boy-Advance-Wireless-Messenger/dp/B0002IQOR8
) and would like to intercept the messages. It uses a CC1020 RF modem
in the 915MHz band. The problem is it uses FHSS in a 26Mhz bandwid
Thank you all
~Andrew
On Sun, Jul 1, 2012 at 4:10 PM, Michael Ossmann wrote:
> On Sun, Jul 01, 2012 at 04:01:48PM -0400, Andrew Davis wrote:
>>
>> So my plan is to somehow remove at least one stage of filtering from
>> the FPGA so I can sample at ~4MSPS and have all out
9:36 PM, Michael Ossmann wrote:
> On Mon, Jul 02, 2012 at 08:27:01PM -0400, Andrew Davis wrote:
>>
>> Really cool presentation! Thanks for the info. Now i'm running into
>> another problem, I sample at about 4MSPS for a bit and try to capture
>> the signal as it passe
1 - 100 of 131 matches
Mail list logo
