@Ben, first of all thanks for replying.
I tried both of the solutions, the output I get is a vector containing only
zeros,
data: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
When I use probe_signal
data: 0.0
But I was sending a vector composed of eleven elements of a combination of ones
and
I am trying to emulate an 8th-order Butterworth low-pass filter using
gr.iir_filter_ffd in GNU Radio. I cannot seem to implement an IIR filter
with such a steep roll-off in gr_filter_design. The filter characteristic
I want are as follows:
Sample Rate: 128,000 sps
Cut-off (3 dB) frequency:
Hi all,
I have recently installed GNU Radio on Windows according to the
instructions at
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows,
and have played around with some simple examples in GNU radio
companion. No problems there. But I am not sure which steps you should
take
Hey List,
Is it possible to easily change the QPSK mapping for the PSK
modulator/demodulators, or does it require a re-compile?
David
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 08/10/2012 07:48 AM, Tomas Johansson wrote:
Hi all,
I have recently installed GNU Radio on Windows according to the
instructions at
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows,
and have played around with some simple examples in GNU radio
companion. No
I can't tell what your problem might be without seeing your entire script.
A minimal script doing something like this is:
from gnuradio import gr
tb = gr.top_block()
src = gr.vector_source_f([1,2,3,4,5,6])
snk = gr.vector_sink_f()
tb.connect(src, snk)
tb.run()
print(snk.data())
On Fri, Aug 10,
There no way to do this simply by passing an appropriate argument but
you could do it without recompiling by adding in appropriate
digital.map_bb blocks into the modulation and demodulation blocks.
On Fri, Aug 10, 2012 at 9:18 AM, David Miller
davidernestmil...@gmail.com wrote:
Hey List,
Is it
Hi all, Nick,
In gr-ais. the bit un-stuffing is done before the de-framing, shouldn't
it be done after instead?
Chris
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
You can do it either way since unstuffing will never generate a valid HDLC
framing code (0110). Unstuffing before the deframing correlators
means my tags' sample numbers don't have to be modified for the bits
inserted by the unstuffing operation.
--n
On Fri, Aug 10, 2012 at 11:47 AM,
Thanks, I realized what I need to do. Next monday I can try it, probably it
will solve the problem.
From: Ben Reynwar b...@reynwar.net
To: abdullah unutmaz abdullahunut...@yahoo.com; discuss-gnuradio Discussion
Group discuss-gnuradio@gnu.org
Sent: Friday,
On 10/08/12 19:55, Nick Foster wrote:
You can do it either way since unstuffing will never generate a valid
HDLC framing code (0110). Unstuffing before the deframing
For what i understand, bit stuffing never generates framing code (that's
the whole point), but the bit *un*stuffing can and
Hmm, you might be right about that. I'll take another look.
--n
On Fri, Aug 10, 2012 at 12:30 PM, Christian Gagneraud ch...@techworks.iewrote:
On 10/08/12 19:55, Nick Foster wrote:
You can do it either way since unstuffing will never generate a valid
HDLC framing code (0110). Unstuffing
Sreeraj,
Thanks for the explanation and the GRC files. Your explanation was right
in line with how I expected gr.iir_filter_ffd to work and what it needed
for parameters. It turns out that I was using gr.iir_filter_ffd correctly,
but the filter coefficients I was using were causing the
13 matches
Mail list logo
