Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Richard Bell]

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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, address@hidden wrote:

Sent from my Cyanogen phone
On Oct 2, 2015 3:12 AM, Richard Bell <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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
>>> > address@hidden
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio