discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Washbourne, Logan
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air
Date: Wed, 7 Oct 2015 10:34:44 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]