Hi LRK,
Thanks for the reply! I thought so too, that this capture effect or
phase locking or limiting should come from the demodulator or clock
recovery block, but looking at the c++ files, I couldn't find anything
related to this. Did I miss something?
The receiver is connected as follow
On Thu, 23 Feb 2012 10:29:02 -0500
Tom Rondeau wrote:
On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring
wrote:
Hello,
in the context of spectrum sensing in the 2.4 GHz band
using a modified
version of the usrp_spectrum_sense.py script, I am
having problems with
high latency times.
Since t
Proposals for this student contest are due March 2, 2012. For more
information, please see http://groups.winnforum.org/p/wi/et/wid=24
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi! Thank you for your suggestions!
I realized it is a problem related with computer speed. Today I used a
laptop to run the same code, and 'O' is printed much more frequently.
However, the computer I'm using is a quite good one. It has intel i7
3.4GHz 8-core, and when the code is running, CPU is
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!
>
>
I tried the code without write(), and it still has the problem. But it
seems to be less frequent. I will try your method. Thank you!
> 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 yo
Modern disk subsystems can easily sustain 80MB or more per second
even on relativley wimpy hardware
What is the sample rate involved
here? Seriously, I've been able to stream multi-MHz of bandwidth to disk
for long periods without any 'O' happening.
-Marcus
On Fri, 24 Feb
2012 11:23:05 -0
Actually, I'm using the blks2 WBFM block, which I believe is a PLL
demodulator.
Both of my "test" stations are actually roughly 100km
away from me, broadcasting from a high point in the Ottawa Valley.
One
station comes in about 10dB stronger than the other, although both have
an ERP of abou
It would be great to have the rds code inside the gnuradio tree instead of
in a separate cgran project!
; )
I don't know why, but when I tried the cgran rds code, the grc example
worked much better then the python one.
Best regards,
Rafael Diniz
>
>
> Actually, I'm using the blks2 WBFM block, wh
I don't know about having it inside the main codebase, but
converting it to use the CMake build system would be good, since it
didn't really understand how to place its python files into a filesystem
that uses /usr/local/lib64--so I had to move them manually.
-Marcus
On Fri, 24 Feb 2012 10:
The CGRAN RDS code seems abandoned, I'm thinking about cloning it to
github so it can be converted to UHD and Cmake and fixed up.
On Fri, Feb 24, 2012 at 1:31 PM, wrote:
> I don't know about having it inside the main codebase, but converting it to
> use the CMake build system would be good, sinc
It would be nice, but it could be fixed up and converted to cmake in the
current svn repo also...
> The CGRAN RDS code seems abandoned, I'm thinking about cloning it to
> github so it can be converted to UHD and Cmake and fixed up.
>
> On Fri, Feb 24, 2012 at 1:31 PM, wrote:
>> I don't know ab
On 02/24/2012 02:45 PM, Rafael Diniz wrote:
> It would be nice, but it could be fixed up and converted to cmake in the
> current svn repo also...
But most of us have forgotten how to use subversion :)
Philip
>
>
>
>> The CGRAN RDS code seems abandoned, I'm thinking about cloning it to
>> gith
On Fri, Feb 24, 2012 at 2:58 PM, Philip Balister wrote:
> On 02/24/2012 02:45 PM, Rafael Diniz wrote:
>> It would be nice, but it could be fixed up and converted to cmake in the
>> current svn repo also...
>
> But most of us have forgotten how to use subversion :)
For those who want to have their
Hello,
I have used the benchmark_tx and benchmark_rx codes for one of my projects
and I am submitting a conference paper based on that work. I want to cite
these codes or at least the GNU radio website for this purpose. Is there a
specific format that I should follow? Or can I just use IEEE's stan
Hi! Marcus,
The sample rate is 4MHz. I also tried 1MHz and 10MHz. On my laptop, the
frequency of 'O' is related with sampling rate and is quite common. On the
desktop, I always have to wait quite a while before an 'O' is printed. But
it is printed even when the sampling rate is 200kHz.
Following
Ok, I've got a branch on github:
https://github.com/glneo/gnuradio-davisaf/tree/optfir with optfir
ported and working in C++, it's part of gr ( gr.optfir ) like firdes.
This keeps the filter design tools together and allows the old optfir
to still be imported and used until I can get all the exampl
18 matches
Mail list logo
