_
> From: discuss-gnuradio-bounces
> +sean.nowlan=gtri.gatech@gnu.org +sean.nowlan=gtri.gatech@gnu.org> on behalf of Andy Walls
>
> Sent: Tuesday, October 20, 2015 12:38 PM
> To: discuss-gnuradio@gnu.org
>
ents on this, I'd love to hear them.
Sean
From: Richard Bell
Sent: Tuesday, October 20, 2015 3:48 PM
To: Nowlan, Sean
Cc: Andy Walls; discuss-gnuradio@gnu.org; lwas...@ostatemail.okstate.edu
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
cuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> on behalf
> of Andy Walls
> Sent: Tuesday, October 20, 2015 12:38 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
>
> On Tue, 2015-10-20 at 11:46 -0400, disc
Walls
Sent: Tuesday, October 20, 2015 12:38 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
On Tue, 2015-10-20 at 11:46 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 10
> Date: Tue, 20 Oct 2015 10:46:11 -0500
> From:
dio-bounces+sean.nowlan=gtri.gatech@gnu.org
> on behalf
> of Washbourne, Logan
> *Sent:* Tuesday, October 13, 2015 12:03 PM
> *To:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Correlation Estimator Over the Air
>
> Rich,
>
> Ah, that makes so much
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
on behalf of
Washbourne, Logan
Sent: Tuesday, October 13, 2015 12:03 PM
To: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
Rich,
Ah, that makes so much sense now. I was modulating all that
OK great, glad to hear that. Don't ever expect to see your data a specific
number of bits in when going over the USRP. There are always going to be
registers that get flushed out ahead of your data. There may be other
factors that contribute to the 98, but that's the simple way I think of it.
In ge
Rich,
Ah, that makes so much sense now. I was modulating all that came out of the
costas loop and packing the bits into bytes which essentially means I was
undoing the syncing the blocks before it were doing. This morning I tried
searching for the preamble in the binary stream that was output from
Logan,
How are you doing this test to see if the bit stream comes out?
The corr_est block correlates against a known sequence and when the
correlation output is above a threshold, tags the local maximum item around
that beak. Now it's up to you to do something with that tag. It places the
tag at
Rich and others,
I added the AGC block to RX side and after playing with the parameters for
awhile I got a correlation spike! My next step was to confirm that my
output equalled my input (byte-wise). In order to accomplish this, I added
a Constellation Decoder block after the costas loop and used
Ah, yes. I suspect you don't have an AGC in your flowgraph? Whenever you're
thresholding against some static number, you need to be sure your input
signal is set to a known amplitude, which is what the AGC does for you. If
you put an AGC in the chain you should see peak values that get close to
you
Last time I replied to the mailing list, did it go directly to your email?
If so, I will double check next time to make sure it goes to the list.
Your explanation makes sense, with the limited knowledge of filtering that
I have.
I changed the filter length on my RX side for the rrc_taps and nothi
Previous email sent without me telling it to. Picking up from "Fuction
coped below:"
firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), eb, 5*sps*nfilts)
The first nfilts is just gain of your filter. The next two paraters should
work out to be the number of samples per symbol of the upsamp
Logan,
I recommend you keep this conversation on the mailing list. You are more
likely to get answers that way.
The Constellation Modulator has an RRC filter built into it. That is what
the Samples/Symbol and Excess BW paramters of that block are for. Your job
now is to make the upsampled by nfil
Rich,
If you could send me that paper, I would really appreciate it. So I'm
looking at the test_corr_est.grc file and the only place I see the rrc_taps
being used is within the polyphase clock sync, which is on the RX side.
Should there be a rrc filter on the TX side as well?
Logan Washbourne
Ele
The taps you use should be the upsampled by nfilt version of your shaping
filter at the tx, scaled appropriately to produce the desired output amplitude.
If you're new to this, then you might need to find a good resource for
polyphase filters and how they are used for timing recovery. I can refe
Sent from my Cyanogen phone
On Oct 2, 2015 3:12 AM, Richard Bell wrote:
>
> I can't open and look at your flow now, but it seems you have the necessary
> blocks in there. Here are some things that come to mind:
>
> 1) put a multiply const block in front of the usrp source at the tx. You
> don't
I can't open and look at your flow now, but it seems you have the necessary
blocks in there. Here are some things that come to mind:
1) put a multiply const block in front of the usrp source at the tx. You don't
want to feed values ranging from 1 to -1 but rather ~0.7 to -0.7.
2) keep usrp tx/
Rich,
The test_corr_est block has the flow graph as follows: vector source->
constellation modulator -> stream mux(with null source) -> throttle ->
channel model -> correlation estimator -> polyphase clock sync -> costas
loop -> constellation and time gui sinks.
For my modified TX grc file I used
Hi Logan,
Can you give more detail on your synchronization choices for BPSK so we can
tell you what more you may need to do?
Rich
Sent from my iPhone
> On Sep 30, 2015, at 7:14 PM, Washbourne, Logan
> wrote:
>
> Hello,
>
> This is somewhat of an update to a previous post I made from last w
Hello,
This is somewhat of an update to a previous post I made from last week.
After talking to Julian and Martin, it was made clear to me that I needed
to use a correlation system to insure my receiver would be synced up to my
transmitter when trying to communicate over the air.
I am trying to u
21 matches
Mail list logo
