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
