Ok, so as a summary.
In 3.7 version xlating changes its sign.
When i test it with myself for the first time i mistakenly also changed
sample rate for the xlate filter and did not get result.
On Fri, Aug 9, 2013 at 4:47 AM, Andrew Davis wrote:
> > "center_frequency" /always/ refers to the freque
> "center_frequency" /always/ refers to the frequency of the incoming
signal.
So what if i'm transmitting, or just "shifting" a signal "frequency" for
another reason?
I understand that "center freq" maybe should mean what you think it does,
but wouldn't it make more sense to change the internal p
On 09/08/13 00:22, Vanush Vaswani wrote:
Hi,
If i add a rational resampler to match the audio rate before the UDP
sink, I can get a continuous output, but it's of terrible quality due to
the loss of information.
You are always going to have to throw information away. You have 192k
that you are
Hi,
If i add a rational resampler to match the audio rate before the UDP sink, I
can get a continuous output, but it's of terrible quality due to the loss of
information.
How does the flowgraph work having a sample rate 'mismatch' when the FCDPP
block is in the same graph?!
Could you give m
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 change breaks a very important and very used part of hundreds of
> projects over the last ten years to make a variable name make slightly more
> since, when you could just change the
I would vote for making copious use of the section in every block's XML
file.
For example, as a beginner, I spent a lot of time fiddling with "Stream to
Vector" to figure out the parameters were opposite from what I thought they
were. It is frustrating to open up a block's sheet and find it
On 08/08/2013 05:25 PM, Alex Zhang wrote:
Hi,
I am transmitting a series of BPSK burst signal and try to observe the
phase distortion for the BPSK signal on air. But it is found that the
Phases of different BPSK bursts are different.
I think this change is caused by the fact that the ADC clock
On 08/08/2013 05:01 PM, Andrew Davis wrote:
Also, this change breaks a very important and very used part of
hundreds of projects over the last ten years to make a variable name
make slightly more since, when you could just change the variable name
to 'frequency_shift' and leave the functionalit
Hi,
I am transmitting a series of BPSK burst signal and try to observe the
phase distortion for the BPSK signal on air. But it is found that the
Phases of different BPSK bursts are different.
I think this change is caused by the fact that the ADC clock phases are
different for the starts of every
Also, this change breaks a very important and very used part of hundreds of
projects over the last ten years to make a variable name make slightly more
since, when you could just change the variable name to 'frequency_shift'
and leave the functionality the way it was.
Andrew
On Thu, Aug 8, 2013
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
On Thu, Aug 8, 2013 at 1:37 PM, Stephen Harrison
wrote:
> I agree.. the new way is more intuitive
>
I have to admit that when the OP filed the bug I went and tested the block
with a quick GRC flowgraph, and intuitively put in the "center freq" value
without thinking about it, and saw that it wor
On Thu, Aug 8, 2013 at 4:37 PM, Stephen Harrison
wrote:
> I agree.. the new way is more intuitive but then again it broke a bunch of
> my GRC patches.. :)
>
>
> On Thu, Aug 8, 2013 at 1:36 PM, Sylvain Munaut <246...@gmail.com> wrote:
>>
>> Hi,
>>
>> > The "old style" version of the block in gnurad
I agree.. the new way is more intuitive but then again it broke a bunch of
my GRC patches.. :)
On Thu, Aug 8, 2013 at 1:36 PM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
> > The "old style" version of the block in gnuradio-core in 3.6.5.1 works
> > correctly. The "new style" version of th
On 08/08/13 21:14, Johnathan Corgan wrote:
On 08/08/2013 01:01 PM, Andrew Davis wrote:
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 no
Hi,
> The "old style" version of the block in gnuradio-core in 3.6.5.1 works
> correctly. The "new style" version of the block in gr-filter in 3.6.5.1
> has the sign change. When all the old-style blocks were removed for
> 3.7, this of course left only the changed one.
Personally I always thoug
On 08/08/2013 01:01 PM, Andrew Davis wrote:
> 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.
Good catch, t
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:
>
Hi Vanush,
as Iain pointed out, the sound card _enforces_ a low sample rate by
being an actual piece of hardware;
therefore, 44.1ksamples/s "leave" your flowgraph at the audio sink,
while you feed it 192ksamples/s from the
funcube.
A faster computer _might_ help, but first adjust the sampling
Ok,
would a faster computer help? I am running the receiver on a 2008 Macbook
air, might be a bit slow for modern standards.
On Fri, Aug 9, 2013 at 4:13 AM, Marcus Müller wrote:
> Hi,
> your warning points to the UDP source: Since your receiver can't process
> all the samples that it gets
> via
Hi,
your warning points to the UDP source: Since your receiver can't process
all the samples that it gets
via UDP, and the UDP source runs out of buffering capacity, it starts to
drop UDP packets.
There are two things that you must do:
1) The Samples for the audio sink _must_ be resampled to t
Is it just me or did the polarity of the frequency offset in
freq_xlating_fir_filter get reversed between 3.6 and 3.7?
On Thu, Aug 8, 2013 at 6:04 AM, Anton Komarov wrote:
> Who can help me to open a ticket?
>
>
> On Wed, Aug 7, 2013 at 4:53 PM, Anton Komarov wrote:
>
>> Ok, but it is not clea
On 08/08/2013 12:03 PM, Vanush Vaswani wrote:
Has there been any effort in using PTP to solve the two-clock problem
(like Audinate's Dante)?
The two-clock problem exists due to the fact that the two *hardware*
clocks involved here -- the audio subsystem, and the USRP aren't
locked to each ot
So the receiver begins with a sample rate of 48 KHz? So how is it possible
to FM demodulation this case?
On Fri, Aug 9, 2013 at 2:09 AM, Iain Young, G7III wrote:
> Different parts of the flow graph can have different sample rates.
>
> You need to use the rational resampler so it's output matches
Gnuradio version 3.7.0
On 08.08.2013 19:15, UA6CEY wrote:
Hi guys!
I couldn't run a QT GUI RANGE block in grc. Any of its widget
(Counter, Slider, etc.) causes an error:
/Traceback (most recent call last):/
/ File "/home/goodman/top_block.py", line 16, in /
/import PyQt4.Qwt5 as Qwt/
Different parts of the flow graph can have different sample rates.
You need to use the rational resampler so it's output matches what
your soundcard expects.
You may also need a complex to real somewhere. There are plenty of
examples for a FM receiver on the web.
Best Regards
Iain
On 08/08/1
Has there been any effort in using PTP to solve the two-clock problem (like
Audinate's Dante)?
On Wed, Aug 7, 2013 at 11:15 AM, Marcus D. Leech wrote:
> On 08/06/2013 09:07 PM, Stephen wrote:
>
>> I tend to use the fractional interpolator--you can get exact rate
>>> matching that way. It doesn'
How can I set the sampling rate on both ends to be the same? FCDPP sampling
rate is 192 KHz.
If I include an audio sink, is the rate of the flowgraph controlled by the
sound card sampling rate?
Attached are my .grc files.
On Thu, Aug 8, 2013 at 11:34 PM, Alexey Bazhin wrote:
> Do you set samp
Hi guys!
I couldn't run a QT GUI RANGE block in grc. Any of its widget (Counter, Slider,
etc.) causes an error:
Traceback (most recent call last):
File "/home/goodman/top_block.py", line 16, in
import PyQt4.Qwt5 as Qwt
File "/usr/lib64/python2.7/site-packages/PyQt4/Qwt5/__init__.py", l
Ok, done with bug submit, actually done it for the first time so might look
ugly...
http://gnuradio.org/redmine/issues/580
On Thu, Aug 8, 2013 at 6:04 PM, Johnathan Corgan
wrote:
> On 08/08/2013 06:57 AM, Anton Komarov wrote:
>
> > i registered
> > opened issues page
> > cannot find New Issue li
On 08/08/2013 06:57 AM, Anton Komarov wrote:
> i registered
> opened issues page
> cannot find New Issue link
> i see Filter, Options and list of issues
I upgraded your account to allow reporting issues, so you should see the
New Issue link now.
--
Johnathan Corgan, Corgan Labs
SDR Training and
Some quick notes:
1) the mfloat_abi option controls which ARM abi is used for function
calls. hard lets the compiler return floats in "NEON" registers. soft
just means they are returned as addresses or something. The setting must
match the one used to build the root file system you are running.
2
Martin
i registered
opened issues page
cannot find New Issue link
i see Filter, Options and list of issues
...
On Thu, Aug 8, 2013 at 5:34 PM, Martin Braun (CEL) wrote:
> On Thu, Aug 08, 2013 at 05:04:10PM +0400, Anton Komarov wrote:
> > Who can help me to open a ticket?
>
> 0) (If you don't ha
Yeah, I think your right, mcpp isn't needed in the gnuradio pybombs recipe.
Tim
On Thu, Aug 8, 2013 at 9:05 AM, Alexandru Csete wrote:
> On Thu, Aug 8, 2013 at 2:16 PM, Tom Rondeau wrote:
> > On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete
> wrote:
> >> Greetings,
> >>
> >> I just noticed th
On Thu, Aug 08, 2013 at 05:04:10PM +0400, Anton Komarov wrote:
> Who can help me to open a ticket?
0) (If you don't have one:) Create an account on gnuradio.org (tell us
your user name)
1) Go to http://gnuradio.org/redmine/projects/gnuradio/issues
2) Click 'New Issue' in the nav bar
3) Fill out
Do you set sampling rate 192000 on both ends? Post your grc files.
On Thu, 8 Aug 2013 14:09:42 +1000
Vanush Vaswani wrote:
> Hi there,
>
> I'm trying to stream the FCDPP over UDP to a another computer
> The setup is as follows
>
> FCDPP Source -> UDP Sink
>
> For the receiver,
>
> UDP Source
Who can help me to open a ticket?
On Wed, Aug 7, 2013 at 4:53 PM, Anton Komarov wrote:
> Ok, but it is not clear for me how to open a ticket in gr bug tracker...
>
>
> On Wed, Aug 7, 2013 at 4:35 PM, Marcus Müller wrote:
>
>> Yes, please attach it to your ticket.
>>
>> Am 07.08.2013 14:28, sch
On Thu, Aug 8, 2013 at 2:16 PM, Tom Rondeau wrote:
> On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete wrote:
>> Greetings,
>>
>> I just noticed that executing "./pybombs install gnuradio" on a system
>> that already has all the necessary dependencies starts by installing a
>> package called mcpp.
>That should definitely be a good start. You're going to probably want
>to have a rolling buffer that you fill up with the latest samples and
>age off the oldest ones once its full. Otherwise, you'll just get one
>or two lines of the spectrogram plotted.
I used the waterfall_sink_c class. Doesn't
On Thu, Aug 8, 2013 at 3:43 AM, Martin Braun (CEL) wrote:
> On Wed, Aug 07, 2013 at 04:28:49PM -0700, tom sutherland wrote:
>> I wanted to use the Constellation Receiver Block for QAM16 but the Class
>> Reference only shows 8PSK, BPSK, DPSK PSK, and QPSK. Can this be used for
>> 16QAM?
>
> There's
On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete wrote:
> Greetings,
>
> I just noticed that executing "./pybombs install gnuradio" on a system
> that already has all the necessary dependencies starts by installing a
> package called mcpp. Searching the web I found out that it is a C/C++
> preproce
Greetings,
I just noticed that executing "./pybombs install gnuradio" on a system
that already has all the necessary dependencies starts by installing a
package called mcpp. Searching the web I found out that it is a C/C++
preprocessor from 2008...
Since gnuradio builds just fine with the standar
On 08/07/2013 04:32 PM, jrobison wrote:
> I am trying to generate java interfaces for SWIG (2.0.10) under fedora 19 ,
> but I'm getting an error. I've been using the command
> swig -java -c++ -I$SWIG_INCLUDE $SWIG_INCLUDE/vocoder_cvsd_decode_bs.i
> This returns the error:
> /usr/include/gnuradio
OK, thanks for the information, so I will just watch it until it originally
does 3.7 without tweaking. At the moment I do not want to create a bigger
mess than I already have on the machine, as I am still learning with all
this Linux stuff :)
Ralph.
> -Original Message-
> From: Josh Blum
On Wed, Aug 07, 2013 at 04:28:49PM -0700, tom sutherland wrote:
> I wanted to use the Constellation Receiver Block for QAM16 but the Class
> Reference only shows 8PSK, BPSK, DPSK PSK, and QPSK. Can this be used for
> 16QAM?
There's no 16QAM object derived from gr::digital::constellation,
unfortuna
On Wed, Aug 07, 2013 at 09:17:02AM -0700, tom sutherland wrote:
> I have gotten the "Constellation Receiver" block so it seems to run without
> errors but I don't see much out. I assume I am suppose to be feeding it a
> complex baseband I/Q signal. What do the output "OUT, SYMBOL, Error, Phase
> Fr
On Wed, Aug 07, 2013 at 10:44:29AM -0700, jpendlum wrote:
> For those interested in FPGA coprocessors with Xilinx's Zynq SoC, I have
> posted a wiki article with comprehensive instructions on how to setup the
> various development boards and run an example C program on the ARM
> processors that com
47 matches
Mail list logo
