Sean,
Thanks for the tip! Is the k value the reference value in the AGC2 block or
the max gain? Would you mind explaining the equation you used a little
more? From what I understand of it, the seq is the 1's and 0's that make up
the pseudorandom preamble, N is the sequence length and i is the specific
value of the sequence when summing. Is that right or am I way off base?
Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
On Wed, Oct 14, 2015 at 9:43 AM, Nowlan, Sean <sean.now...@gtri.gatech.edu>
wrote:
> 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:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org
> <discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org> on behalf
> of Washbourne, Logan <lwas...@ostatemail.okstate.edu>
> *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 <richard.be...@gmail.com>
> 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 <
>> lwas...@ostatemail.okstate.edu> 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 <richard.be...@gmail.com>
>>> 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 <
>>>> lwas...@ostatemail.okstate.edu> 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 <richard.be...@gmail.com
>>>>> > 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 <richard.be...@gmail.com
>>>>>> > 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 <
>>>>>>> lwas...@ostatemail.okstate.edu> 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 <
>>>>>>>> richard.be...@gmail.com> 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, lwas...@ostatemail.okstate.edu wrote:
>>>>>>>>>
>>>>>>>>> Sent from my Cyanogen phone
>>>>>>>>> On Oct 2, 2015 3:12 AM, Richard Bell <richard.be...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>> lwas...@ostatemail.okstate.edu> 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 <
>>>>>>>>> richard.be...@gmail.com> 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 <
>>>>>>>>> lwas...@ostatemail.okstate.edu> 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
>>>>>>>>> >>> > Discuss-gnuradio@gnu.org
>>>>>>>>> >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> Discuss-gnuradio mailing list
>>>>>>>>> >> Discuss-gnuradio@gnu.org
>>>>>>>>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> Discuss-gnuradio@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
