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
