We saw a lot of improvement in the performance of the Correlation Estimator
block once we calculated a level for the AGC. In our case, we're looking for a
BPSK preamble that is a pseudorandom sequence. The corr_est block is provided
with the match-filtered version of the preamble sequence. So we calculated the
average energy per sample of that sequence as K = \frac{
\sum_{i}^{N}(\abs{seq}^2) }{ N }. (Sorry if the LaTeX notation is a bit off).
So K is the target level we use in the AGC2 block. This seems to work pretty
well for us.
Sean
________________________________
From: [email protected]
<[email protected]> on behalf of
Washbourne, Logan <[email protected]>
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 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 the
constellation decoder and I found it. It was 98 samples in, which confused me,
but now that I know I am looking for a tag then that makes perfect sense.
I just tried that same process, looking for the preamble in the binary
stream(using matlab) for the over the air program and I still can't find it,
but I am going to play around with the AGC block and see if I can't tweak it
enough to work.
I really appreciate your help, I finally feel like I'm getting close to my goal.
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell
<[email protected]<mailto:[email protected]>> wrote:
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 the very
front of the correlation sequence, so one of the first things you need to do is
handle the tag placement. You have some control over that with the builtin
delay paramter, but sometimes that's not enough.
I would recommend taking a step back and proving you know how to do the
transformations that don't involve synchronization and channel correction. Take
your input data, map it to symbols, modulate it and then immediately reverse
the process. No channel, no noise, no synchronization. If you can't make this
simulation work, you are misunderstanding something.
Rich
On Mon, Oct 12, 2015 at 1:28 PM, Washbourne, Logan
<[email protected]<mailto:[email protected]>> wrote:
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 the constellation
object as the input parameter. Then I repacked the bits into 8 bit bytes and
saved it to a file. I also saved the input byte stream to a file. I looked at
those files in Matlab and so far I have not been able to find the preamble in
the output byte stream.
After not being able to determine if this communication system was working( the
TX and RX programs utilizing the USRPs), I took a step back and tried to figure
out how to confirm if the test_corr_est.grc had the same output as its input
and I'm running into the same problem, I haven't been able to find the preamble
in the output.
Both programs show a clear correlation spike, I just want to put my mind at
ease and verify if it's working through the actual bytes. One last note, the
packed output byte stream is roughly 5.5 times smaller than the input byte
stream, which I was expecting a really close 1:1 size, this makes me think I am
overlooking a consequence of one of the blocks, namely the Correlation
Estimator, Polyphase Clock Sync, or the Costas Loop.
Does anyone have any suggestions?
I know this thread is getting a little long, but I appreciate everyone's
patience with my questions.
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell
<[email protected]<mailto:[email protected]>> wrote:
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 your simulation
values. The AGC produces a stable platform for the rest of your blocks to sit
on.
The AGC parameters can really play havoc with your system. The AGC can be the
cause of a lot of headache. If you find yourself debugging something that makes
no sense, often it's the AGC's fault, in my experience. I recommend you create
a simulation that stresses the AGC and prove it will work as best you can
before going to over the air.
Rich
On Wed, Oct 7, 2015 at 9:09 AM, Washbourne, Logan
<[email protected]<mailto:[email protected]>> wrote:
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 nothing seemed
to change. But I think what the overarching problem is, is my metric for
success. The way I am determining if the communication has been successful is
the amplitude of the correlation value coming out of the Correlation Estimator
block. Through all of my testing over the air, the correlation value hasn't
seemed to have changed. I can register an extremely small value, of .5-1.5 if I
set the QT GUI TIME SINK to autoscale, but the non-over the air version outputs
a value of roughly 75, which has been causing me to call the communication a
failure.
Do you have any advice?
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Wed, Oct 7, 2015 at 10:47 AM, Richard Bell
<[email protected]<mailto:[email protected]>> wrote:
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 upsampled RRC. 1/float(sps)
gives you 1/4 if sps = 4. Then to get samp/symb you have nfilts/(1/4) =
4*nfilts samp_symb, which is in fact the upsampled version you want. The point
I'm trying to make, is you could have filled out the function this way and got
the same result:
firdes.root_raised_cosine(nfilts, nfilts*sps, 1, eb, 5*sps*nfilts)
which feels more natural to me.
The last paramter is the length of the filter in samples. The default does not
match the built in length of the Constellation Modulator filter, which is
hardcoded to 11 if I remember right. So I use, 11*sps*nfilts+1 for this
parameter. The plus 1 is actually handled for you in the constructor of the RRC
(I think it's the constructor, but if not somewhere). If you feed an even
number in, it will get 1 added to it. I like to be explicit with the +1, but
you don't need it.
Rich
On Wed, Oct 7, 2015 at 8:41 AM, Richard Bell
<[email protected]<mailto:[email protected]>> wrote:
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 nfilt version of that blocks RRC filter and feed it
into the pfb clock sync block. That's what the example shows you how to do.
The way the default values of the pfb clock sync block are entered can be a
little confusing. Function copied below:
On Wed, Oct 7, 2015 at 8:34 AM, Washbourne, Logan
<[email protected]<mailto:[email protected]>> wrote:
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
Electrical Engineering Graduate Student
(Electromagnetics)
On Sat, Oct 3, 2015 at 5:28 AM, Richard Bell
<[email protected]<mailto:[email protected]>> wrote:
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 reference a
paper for you later on if needed. But, from grc if you used an rrc filter on
the tx, it's a matter of making a call to the rrc filter in the taps parameter
of the block. I think there is an example of this in the gr-digital/examples
folder. I'm not in front of a computer so I can't check for you now.
Rich
Sent from my iPad
On Oct 2, 2015, at 3:06 PM,
[email protected]<mailto:[email protected]> wrote:
Sent from my Cyanogen phone
On Oct 2, 2015 3:12 AM, Richard Bell
<[email protected]<mailto:[email protected]>> 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 want to feed values ranging from 1 to -1 but rather ~0.7 to -0.7.
>
I will try that today.
> 2) keep usrp tx/rx analog gains below 20dB to avoid odd behavior. Keep the
> usrps close to each other for this debug. I use 15dB for initial testing.
>
I've kept it around 10dB normally, but I will double check.
> 3) Costas loop will only fix small frequency offsets. Try adding an FLL block
> before timing sync.
>
Will do. I don't think it's even getting to the costas loop to be honest, it
seems to not be tripping the correlation estimator block.
> 4) are you sure you used the right taps for the pfb clock sync block? How did
> you confirm this?
>
I'm not sure if I used the right taps. I'm just using the ones that were
included in the test_corr_est GRC file. Do you have a method of confirmation
that you would recommend?
> 5) BPSK requires an equalizer if you have a bad channel. Are you using
> antennas or a coax cable?
>
I am using antennas. I'll look into the equalizer.
Thank you for taking the time to help so far.
> Rich
>
> Sent from my iPhone
>
> On Oct 1, 2015, at 6:20 PM, Washbourne, Logan
> <[email protected]<mailto:[email protected]>> wrote:
>
>> 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 the following flowgraph: vector source ->
>> constellation modulator -> stream mux(with null source) -> constellation and
>> time gui sinks as well as the UHD: USRP sink
>>
>> For the RX grc: UHD: USRP Source -> correlation estimator -> polyphase clock
>> sync -> costas loop-> constellation and time gui sinks.
>>
>> The grc files can be found at: https://github.com/loganwashbourne/Logan.git
>>
>> The files are called test_corr_est_TX and test_corr_est_RX.
>>
>> Thanks for your time,
>>
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Thu, Oct 1, 2015 at 3:44 AM, Richard Bell
>> <[email protected]<mailto:[email protected]>> wrote:
>>>
>>> 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
>>> > <[email protected]<mailto:[email protected]>>
>>> > wrote:
>>> >
>>> > 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 utilize the Correlation Estimator block to help me achieve
>>> > those means. In order to ease myself into it, I am trying to turn the
>>> > test_corr_est.grc example into an over the air program. I am getting
>>> > communication between the transmitter and receiver(essentially I just
>>> > split the grc program in two and took out the throttle block and the
>>> > channel model and replaced them with UHD blocks). Now, I don't get any
>>> > O's or L's or an abundance of U's, and I can clearly see data coming in
>>> > on the RX side, but it seems to be a lot of noise, but noise generated by
>>> > the TX side, because it goes away when I stop transmitting. The center
>>> > frequency is 2.48GHz and the sample rate is 250k samples/sec.
>>> >
>>> > My testing method is plotting the constellation symbols right before they
>>> > get sent out on the TX side and then plotting them right after the UHD
>>> > block on the RX side. It is only bpsk and the symbols are covering all
>>> > four quadrants.
>>> >
>>> > I haven't changed any settings on the polyphase clock sync or the
>>> > modulation scheme.
>>> >
>>> > This is a little rambly but I appreciate your time,
>>> >
>>> > Logan Washbourne
>>> > Electrical Engineering Graduate Student
>>> > (Electromagnetics)
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > [email protected]<mailto:[email protected]>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]<mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]<mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]<mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]<mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
