> 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
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
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
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, first I think you meant sample rate, not size. Who said you cant use
30Mhz, what kind of hardware are you using? Lastly the FFT algorithms do
not deal with frequency in that way, you are still seeing 0-50Mhz spectrum,
just the label now says 50Mhz.
Andrew
On Sat, Nov 16, 2013 at 10:11 AM,
GRC file and the DSD block is here:
> https://github.com/robotastic/gr-dsd
> If you change /lib/dsd_block_ff.cc on line 365 & 366 you can change how
> the number of outputted samples is determined.
>
> I have the C++ program the uses this all here:
> https://github.com/robota
run. I am not
> getting 'aUaU' on the screen. Sometimes the sound from audio sink initially
> sound garbled but then becomes normal, so I wonder if it is an issue of
> needing to buffer up. I have tried adding in a Forecast, but it didn't help.
>
> Any other tips would
I'm not sure exactly what you are doing, but some sound cards don't support
very many rates, windows always re-samples to some rate supported by the
card, in linux you get more direct access to sound hardware and so you can
send it rates it may not like, you could add a re-sampler/sound manager
lik
Kinda OT, but sure, what I use for most experiments is a handheld dipole
with telescoping elements, it can tune between about 80 and 400 MHz, for
everything else I use a simple 800MHz rubber duck, these work well enough
for everything i'm doing.
Andrew
On Tue, Aug 27, 2013 at 9:06 PM, Richard Th
-runtime -lgnuradio-pmt
Cflags: -I${includedir}
pkg-config --cflags dri2proto also shows nothing also, that is how I knew
it wasn't just Gnuradio
Andrew
On Sat, Aug 24, 2013 at 1:48 PM, Andrew Davis wrote:
> No only things from my new install, I deleted everything Gnuradio in
&g
allation?
> Does
> find /usr/lib*/pkgconfig /usr/local/lib*/pkgconfig /lib*/pkgconfig -iname
> 'gnuradio*pc'
> yield anything that does not belong to your current installation?
>
>
>
> On 08/24/2013 06:45 PM, Andrew Davis wrote:
>
> I don't think this
at, Aug 24, 2013 at 12:39 PM, Andrew Davis wrote:
> OK, rebuild and reinstalled Gnuradio after revoking that commit, then
> build a new module with modtool and still had the same problem:
>
> checking for module 'gnuradio-runtime'
>
> found gnuradio-runtime, version 3.7.1g
OK, rebuild and reinstalled Gnuradio after revoking that commit, then build
a new module with modtool and still had the same problem:
checking for module 'gnuradio-runtime'
found gnuradio-runtime, version 3.7.1git
Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_INCLUDE_DIRS)
checking
Wow, what a coincidence, I just ran into this problem this morning and was
about to ask about it right before I saw your post, I too am having the
exact same problem on xubuntu amd64. I have not done a git pull for a few
days so this problem was not caused this morning by any commit if that
helps.
Try running it without anything else on the network or on your computer,
not even X11.
Andrew
On Mon, Aug 19, 2013 at 3:44 AM, Sam mite wrote:
> can somebody please comment on it ? Thanks a head of time.
>
>
> --
> Sam
>
>
>
> On Fri, Aug 16, 2013 at 10:11 AM, Sam mite wrote:
>
>> I am facing
if this post sounded like a rant ( API breaks bug me :) )
Thank you for you consideration,
Andrew
On Thu, Aug 8, 2013 at 5:46 PM, Tom Rondeau wrote:
> On Thu, Aug 8, 2013 at 5:51 PM, Marcus D. Leech wrote:
> > On 08/08/2013 05:01 PM, Andrew Davis wrote:
> >
> > Also, this
ug 8, 2013 at 3:56 PM, Andrew Davis wrote:
> Center frequency of the received signal or center where I want to move it
> to? It's not intuitive ether way, the parameter name should be changed to
> what it actually is: 'frequency_shift' and it should behave exactly like
>
Center frequency of the received signal or center where I want to move it
to? It's not intuitive ether way, the parameter name should be changed to
what it actually is: 'frequency_shift' and it should behave exactly like
multiplication does, you multiply a positive frequency you get a positive
shif
It's not just you, I noticed this too. This change broke gr-atsc ( but I
fixed that ).
The problem is on line 80 of
gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t: the 2 was not negative
in 3.6 but is now, i'm not sure why.
Andrew
On Thu, Aug 8, 2013 at 12:16 PM, Stephen Harrison
wrote:
>
playPlot.cc.o]
> Error 1
>
> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
>
> make: *** [all] Error 2
>
> ** **
>
> It doesn’t look related to ATSC, though.
>
> ** **
>
> *From:* discuss-gnuradio-bounces+souryal=nist...
OK, pushed, could you see if that works better?
Thank you
Andrew
On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis wrote:
> It was removed and left in fpll.h, i'll push a fix in just a bit, in
> the meantime you could just remove the include line from fpll.h
>
> Thank you
> Andr
gt;
> Perhaps this file was accidentally left out of the repository (?)
>
> Ranga
>
>
>
>
>
> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>>
>> > Af
d, Jul 31, 2013 at 5:00 PM, Andrew Davis wrote:
> Ok, I tried the off by sqrt(2) and it put me close but now the bit_timing
> _loop is running short on data again, which as a disseminator means it
> probably cant find a good sync for timing and just eats all its input
> samples. So I pus
ee if that compiles for you, then I could walk you though whats all going
on with this and where i'm at.
Thank you
Andrew
On Tue, Jul 30, 2013 at 8:12 PM, Johnathan Corgan
wrote:
> On 07/30/2013 04:28 PM, Andrew Davis wrote:
>
> > Thanks for the idea, I will try it tomorrow when
g
if I get this figured out :)
Andrew
On Tue, Jul 30, 2013 at 6:19 PM, Brian Padalino wrote:
> On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I'm working on fixing up gr-atsc and I have been working on a little
>> problem for a while now
oherent AGC into the sync timing loop but it still fails with
large gain differences.
My question is whether there is anyone around who worked on gr-atsc who
could give me a hint as to how the "Magic coupling constant" was derived in
the first place so I can build a new one
Hello,
For just teaching even a speaker and microphone work well to add real world
effects like AWGN, echos, delays, and Doppler effects on communication
channels. Does everyone need a transmitter? Over here we have just one USRP
and a whole lot of RTLSDR's so everyone can practice receiving and
d
to the old all_atsc.py and rename if
you want.
Thank you
Andrew
On Mon, Jul 15, 2013 at 6:52 PM, Johnathan Corgan
wrote:
> On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote:
>
>
>> I have been working on getting gr-atsc running again, I have found a few
>> speedups an
Hello all,
I have been working on getting gr-atsc running again, I have found a few
speedups and some bugs that prevented ATSC decoding from working with new
versions of GNURadio. I have put these fixes into a branch that can now
decode signals from my local TV station. The changes are in commit i
Hello all,
When using pll_carriertracking_cc, the returned spectrum seems to be
inverted about 0MHz, when looking though the code line 113 of
gr-analog/lib/pll_carriertracking_cc_impl.cc
looked odd:
> optr[i] = iptr[i] * gr_complex(t_real, -t_imag);
could someone explain why the the imaginary co
OK, it appears a previous install hid an extra libvolk in
/usr/lib/x86_64-linux-gnu, removing that everything is working well so far,
thank you for the help everyone.
-Andrew
On Sun, Jul 7, 2013 at 4:12 AM, Tom Rondeau wrote:
> On Fri, Jul 5, 2013 at 6:31 PM, Andrew Davis
> wrote:
>
e why VOLK functions are not getting linked?
Thank you
-Andrew
On Thu, Jul 4, 2013 at 5:17 PM, Stephen Harrison
wrote:
> I had the same problem, but realized I was using the GRC .xml definitions
> from the previous version (in /usr/local/share/gnuradio/blocks).
>
>
> On Thu, Ju
Hello all,
I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run GRC
almost any block that uses constants from the updates name-spaces GRC fails
with:
> Value "firdes.WIN_HAMMING" cannot be evaluated:
> name 'firdes' is not defined
or for signal source and related:
> Value "analog
> my J1 port is lower then that of my J2 port! About 30dB lower!
Are you transmitting out of your J1 port? 30dB sounds like cross talk
on a non-transmitting port.
>One thing i've started to notice is that as I step up the uhd gain the
>readings I get on the spectrum analyser do not appear to lin
Nice pic Tom! FTA:
>It could only capture a narrow slice of spectrum: 100 kHz at most. That was
>enough for Law and Order reruns..
How does that work :)
~Andrew
On Sat, Jul 7, 2012 at 9:22 AM, ikjtel wrote:
>
>
>> It has a photo of *both*
>
> Well, two separate photos, if one wanted to be tec
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
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
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
>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
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
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
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
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
> 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
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
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
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
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
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
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
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
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"
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
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
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
>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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>[ 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
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
>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
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:
>
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.
>
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!
>
>
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
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
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
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
"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
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
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
: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:
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
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.
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
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
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
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
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
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
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
> 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:
> >
1 - 100 of 131 matches
Mail list logo
