On Tue, Oct 20, 2015 at 8:46 AM, <[email protected]> wrote:
> Send Discuss-gnuradio mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > Today's Topics: > > 1. How to use an external PPS reference in B200? > (Julio Hector Aguilar Renteria) > 2. Re: Discuss-gnuradio Digest, Vol 155, Issue 22 (John D. Hays) > 3. Re: Discuss-gnuradio Digest, Vol 155, Issue 22 > (Przemek Lewandowski) > 4. 3.7.8 Windows Binaries available for testing (Geof Nieboer) > 5. Re: How to use an external PPS reference in B200? > (James Humphries) > 6. Re: 3.7.8 Windows Binaries available for testing (West, Nathan) > 7. Re: 3.7.8 Windows Binaries available for testing (Geof Nieboer) > 8. Re: Suggestions for C++ Coding of a new PRNG (Jason Noble) > 9. Re: 3.7.8 Windows Binaries available for testing (Tom Rondeau) > 10. Re: Correlation Estimator Over the Air (Washbourne, Logan) > > > ---------- Forwarded message ---------- > From: Julio Hector Aguilar Renteria <[email protected]> > To: undisclosed-recipients:; > Cc: > Date: Mon, 19 Oct 2015 12:12:07 -0500 > Subject: [Discuss-gnuradio] How to use an external PPS reference in B200? > Hi, All > > How to use an external GPS reference in the USRP B200 ?, I do some extra > configuration on the USRP B200? > > > ---------- Forwarded message ---------- > From: "John D. Hays" <[email protected]> > To: [email protected] > Cc: > Date: Mon, 19 Oct 2015 10:47:12 -0700 > Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 22 > > > On Mon, Oct 19, 2015 at 9:01 AM, <[email protected]> wrote: > >> Send Discuss-gnuradio mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Discuss-gnuradio digest..." >> >> Today's Topics: >> >> 1. Re: Passing GUI widgets into hier block with parameters >> (Przemek Lewandowski) >> >> >> ---------- Forwarded message ---------- >> From: Przemek Lewandowski <[email protected]> >> To: GNURadio Discussion List <[email protected]> >> Cc: >> Date: Sun, 18 Oct 2015 18:18:27 +0200 >> Subject: Re: [Discuss-gnuradio] Passing GUI widgets into hier block with >> parameters >> Hello everybody, >> Is this question has some not understandable phrases or should I correct >> something :) ? or is it stupid question or so simple. >> >> >> I still have a problem. Normally is it correct to pass GUI state inside a >> hierarchical block or is it not allowed ?? >> >> >> >> All the best. >> Przemek >> >> 2015-10-15 20:38 GMT+02:00 Przemek Lewandowski <[email protected]>: >> >>> Hello >>> >>> I have a question. >>> >>> I have created many hier blocks, and I would like to pass into sam >>> values from GUI but when state is changing, it doesnt correspond to value >>> inside a hier block. >>> >>> this is my flowgraph: >>> http://postimg.org/image/qgaf705q1/a9569ee5/ >>> >>> With GUI Chooser I would like to change SideBand of SSB Modulation. It >>> is working when block responsible for switching side bands is outside of >>> hier block. but it doesnt work when it is inside. >>> >>> This is my hier block, but with removed block responsible for swithcing, >>> only Parameter left. >>> >>> http://postimg.org/image/4sbalehpl/ >>> >>> Thank You >>> Przemek Lewandowski >>> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > > ------------------------------ > John D. Hays > K7VE > > PO Box 1223, Edmonds, WA 98020-1223 > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> > > > > ---------- Forwarded message ---------- > From: Przemek Lewandowski <[email protected]> > To: "John D. Hays" <[email protected]> > Cc: GNURadio Discussion List <[email protected]> > Date: Mon, 19 Oct 2015 20:11:28 +0200 > Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 22 > Sorry for mistake, I suspected that something can be wrong with my email > on forum. Im using Gmail and didnt realized about wrong mail format. > > Thanks > > 2015-10-19 19:47 GMT+02:00 John D. Hays <[email protected]>: > >> >> >> On Mon, Oct 19, 2015 at 9:01 AM, <[email protected]> >> wrote: >> >>> Send Discuss-gnuradio mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Discuss-gnuradio digest..." >>> >>> Today's Topics: >>> >>> 1. Re: Passing GUI widgets into hier block with parameters >>> (Przemek Lewandowski) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Przemek Lewandowski <[email protected]> >>> To: GNURadio Discussion List <[email protected]> >>> Cc: >>> Date: Sun, 18 Oct 2015 18:18:27 +0200 >>> Subject: Re: [Discuss-gnuradio] Passing GUI widgets into hier block with >>> parameters >>> Hello everybody, >>> Is this question has some not understandable phrases or should I correct >>> something :) ? or is it stupid question or so simple. >>> >>> >>> I still have a problem. Normally is it correct to pass GUI state inside >>> a hierarchical block or is it not allowed ?? >>> >>> >>> >>> All the best. >>> Przemek >>> >>> 2015-10-15 20:38 GMT+02:00 Przemek Lewandowski <[email protected]>: >>> >>>> Hello >>>> >>>> I have a question. >>>> >>>> I have created many hier blocks, and I would like to pass into sam >>>> values from GUI but when state is changing, it doesnt correspond to value >>>> inside a hier block. >>>> >>>> this is my flowgraph: >>>> http://postimg.org/image/qgaf705q1/a9569ee5/ >>>> >>>> With GUI Chooser I would like to change SideBand of SSB Modulation. It >>>> is working when block responsible for switching side bands is outside of >>>> hier block. but it doesnt work when it is inside. >>>> >>>> This is my hier block, but with removed block responsible for >>>> swithcing, only Parameter left. >>>> >>>> http://postimg.org/image/4sbalehpl/ >>>> >>>> Thank You >>>> Przemek Lewandowski >>>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> >> ------------------------------ >> John D. Hays >> K7VE >> >> PO Box 1223, Edmonds, WA 98020-1223 >> <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> >> <http://www.facebook.com/john.d.hays> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > ---------- Forwarded message ---------- > From: Geof Nieboer <[email protected]> > To: [email protected] > Cc: > Date: Tue, 20 Oct 2015 00:11:58 +0300 > Subject: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testing > Hello all, > > I've completed a *beta* version of a windows binary installer for GNURadio > 3.7.8. > > Information about it is available at > http://www.gcndevelopment.com/gnuradio as is the download itself of > course. > > Essentially I compiled every package in the dependency chain from source > in 64-bit VS 2015, so it contains everything needed to run. It also > includes UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and > AirSpy. It should run on Win 7+ and has been roughly tested on Win 7 & 10. > > IMPORTANT: This is just a beta version; is 64-bit only, and I set all the > optimizations for AVX2, so it will NOT run on any CPU prior to Haswell. > Sorry about that, the 'production' version will come with two options, AVX2 > or SSE2+. > > So I'd sure appreciate feedback as I prep the next version, even if > Windows isn't your primary platform. The install is completely removable > and doesn't impact any other Python installations or environment variables > (see the website for more details). It's ~400MB download. Documentation > and notes as to "why" are available on the site. > > Cheers, > > Geof > > > > > > > ---------- Forwarded message ---------- > From: James Humphries <[email protected]> > To: Julio Hector Aguilar Renteria <[email protected]>, discuss-gnuradio > <[email protected]> > Cc: > Date: Mon, 19 Oct 2015 17:31:13 -0400 > Subject: Re: [Discuss-gnuradio] How to use an external PPS reference in > B200? > Hi Julio, > > You need to instruct the USRP which reference to use. See this page in the > UHD manual: > > http://files.ettus.com/manual/page_sync.html > > Are you using a GNU Radio flowgraph? Or are you writing code directly > using the GNU Radio python API or UHD C++ API? > > -Trip > > On Mon, Oct 19, 2015 at 1:12 PM, Julio Hector Aguilar Renteria < > [email protected]> wrote: > >> Hi, All >> >> How to use an external GPS reference in the USRP B200 ?, I do some extra >> configuration on the USRP B200? >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > ---------- Forwarded message ---------- > From: "West, Nathan" <[email protected]> > To: Geof Nieboer <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Mon, 19 Oct 2015 17:37:38 -0400 > Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for > testing > On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <[email protected]> > wrote: > >> Hello all, >> >> I've completed a *beta* version of a windows binary installer for >> GNURadio 3.7.8. >> >> Information about it is available at >> http://www.gcndevelopment.com/gnuradio as is the download itself of >> course. >> >> Essentially I compiled every package in the dependency chain from source >> in 64-bit VS 2015, so it contains everything needed to run. It also >> includes UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and >> AirSpy. It should run on Win 7+ and has been roughly tested on Win 7 & 10. >> >> IMPORTANT: This is just a beta version; is 64-bit only, and I set all the >> optimizations for AVX2, so it will NOT run on any CPU prior to Haswell. >> Sorry about that, the 'production' version will come with two options, AVX2 >> or SSE2+. >> >> So I'd sure appreciate feedback as I prep the next version, even if >> Windows isn't your primary platform. The install is completely removable >> and doesn't impact any other Python installations or environment variables >> (see the website for more details). It's ~400MB download. Documentation >> and notes as to "why" are available on the site. >> >> Cheers, >> >> Geof >> >> > Hi Geof, > > First, congrats on this achievement. Were there changes to GNU Radio > and/or VOLK required to do this? Assuming some changes were required: do > you have a public repo with your modifications and are you planning to > submit them for merging in to GNU Radio and VOLK? > > Cheers, > -Nathan > > > ---------- Forwarded message ---------- > From: Geof Nieboer <[email protected]> > To: [email protected] > Cc: "[email protected]" <[email protected]> > Date: Tue, 20 Oct 2015 09:53:23 +0300 > Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for > testing > Nathan, > > Thanks! Yes, there were some changes required, the good news that they > were fairly minor for GNURadio/volk. I'm going to refactor the build > environment next for the release version, and as I do, I'll post bug > reports and upload patch files etc.. I do have a fork set up for GNURadio > on github, but haven't uploaded the changes to it yet. I will though for > incorporation. > > Geof > > > > On Tue, Oct 20, 2015 at 12:37 AM, West, Nathan < > [email protected]> wrote: > >> On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <[email protected]> >> wrote: >> >>> Hello all, >>> >>> I've completed a *beta* version of a windows binary installer for >>> GNURadio 3.7.8. >>> >>> Information about it is available at >>> http://www.gcndevelopment.com/gnuradio as is the download itself of >>> course. >>> >>> Essentially I compiled every package in the dependency chain from source >>> in 64-bit VS 2015, so it contains everything needed to run. It also >>> includes UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and >>> AirSpy. It should run on Win 7+ and has been roughly tested on Win 7 & 10. >>> >>> IMPORTANT: This is just a beta version; is 64-bit only, and I set all >>> the optimizations for AVX2, so it will NOT run on any CPU prior to >>> Haswell. Sorry about that, the 'production' version will come with two >>> options, AVX2 or SSE2+. >>> >>> So I'd sure appreciate feedback as I prep the next version, even if >>> Windows isn't your primary platform. The install is completely removable >>> and doesn't impact any other Python installations or environment variables >>> (see the website for more details). It's ~400MB download. Documentation >>> and notes as to "why" are available on the site. >>> >>> Cheers, >>> >>> Geof >>> >>> >> Hi Geof, >> >> First, congrats on this achievement. Were there changes to GNU Radio >> and/or VOLK required to do this? Assuming some changes were required: do >> you have a public repo with your modifications and are you planning to >> submit them for merging in to GNU Radio and VOLK? >> >> Cheers, >> -Nathan >> > > > > ---------- Forwarded message ---------- > From: Jason Noble <[email protected]> > To: GNURadio Discussion List <[email protected]> > Cc: > Date: Tue, 20 Oct 2015 17:42:45 +0900 > Subject: Re: [Discuss-gnuradio] Suggestions for C++ Coding of a new PRNG > Marcus, > > Thanks for the quick response. Based on your feedback, I've decided to > look over the GLFSR code, and basically re-write my XORSHIFT code with the > GLFSR block as a guideline....not sure why I didn't consider that before. > > Then have the output vector read by the FHSS block to generate the correct > carrier signal......hmmm, ok. Let's see how long it takes me to write all > this. I want to do some testing by next week: the lab I'm visiting has some > spectrum analyzers and I want to get real-world data with my bladeRFs > before I leave here. > > > ---------- Forwarded message ---------- > From: Tom Rondeau <[email protected]> > To: Geof Nieboer <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: Tue, 20 Oct 2015 09:54:57 -0400 > Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for > testing > On Tue, Oct 20, 2015 at 2:53 AM, Geof Nieboer <[email protected]> > wrote: > >> Nathan, >> >> Thanks! Yes, there were some changes required, the good news that they >> were fairly minor for GNURadio/volk. I'm going to refactor the build >> environment next for the release version, and as I do, I'll post bug >> reports and upload patch files etc.. I do have a fork set up for GNURadio >> on github, but haven't uploaded the changes to it yet. I will though for >> incorporation. >> >> Geof >> > > > Geof, > > This is fantastic, thanks! > > Please send pull requests on github with your patches when you can. > > Tom > > > >> On Tue, Oct 20, 2015 at 12:37 AM, West, Nathan < >> [email protected]> wrote: >> >>> On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <[email protected]> >>> wrote: >>> >>>> Hello all, >>>> >>>> I've completed a *beta* version of a windows binary installer for >>>> GNURadio 3.7.8. >>>> >>>> Information about it is available at >>>> http://www.gcndevelopment.com/gnuradio as is the download itself of >>>> course. >>>> >>>> Essentially I compiled every package in the dependency chain from >>>> source in 64-bit VS 2015, so it contains everything needed to run. It also >>>> includes UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and >>>> AirSpy. It should run on Win 7+ and has been roughly tested on Win 7 & 10. >>>> >>>> IMPORTANT: This is just a beta version; is 64-bit only, and I set all >>>> the optimizations for AVX2, so it will NOT run on any CPU prior to >>>> Haswell. Sorry about that, the 'production' version will come with two >>>> options, AVX2 or SSE2+. >>>> >>>> So I'd sure appreciate feedback as I prep the next version, even if >>>> Windows isn't your primary platform. The install is completely removable >>>> and doesn't impact any other Python installations or environment variables >>>> (see the website for more details). It's ~400MB download. Documentation >>>> and notes as to "why" are available on the site. >>>> >>>> Cheers, >>>> >>>> Geof >>>> >>>> >>> Hi Geof, >>> >>> First, congrats on this achievement. Were there changes to GNU Radio >>> and/or VOLK required to do this? Assuming some changes were required: do >>> you have a public repo with your modifications and are you planning to >>> submit them for merging in to GNU Radio and VOLK? >>> >>> Cheers, >>> -Nathan >>> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > ---------- Forwarded message ---------- > From: "Washbourne, Logan" <[email protected]> > To: GNURadio Discussion List <[email protected]> > Cc: > Date: Tue, 20 Oct 2015 10:46:11 -0500 > Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the Air > Hello, > > I have still been working on getting the over the air communication to > work and I think I have definitely narrowed it down to the AGC being the > problem. I took Sean's advice and calculated the average energy per sample > for the preamble, which yielded me a value of .0078 Joules and I used that > for the reference value in the AGC2 block. When I used that value as the > reference, the correlation estimator wouldn't catch anything as correlated. > It is a real possibility that I calculated the energy per sample > incorrectly. I calculated it by only sending the preamble over the air, > then took the first 64 complex values( I used some code from the octave > files in gr-utils, to convert file sink data to complex values) from the > USRP Source block. I then found the magnitude of those values, squared > them, summed them, and then divided by 64. Dividing by 64 might be > incorrect. > > That is what I tried in terms of calculating the reference value of the > AGC, but I also just plugged numbers into the block as well, and what I > seem to get most often is the correlation estimator block spitting out > several "correlated values" that are within a few samples of each other, > which ideally shouldn't happen seeing as how the payload length is 992 > samples long and there is a null source injected roughly 32k zeros into the > communication stream. > > I have some pictures of what my output graphs look like, I am concerned > that the correlation tags are being associated with the very low amplitude > values on the correlation plot. > > These pictures are of the same communication session, screen-printed > roughly 5 secs apart. > > (If the attachments don't make it through the mailing list, please let me > know and I can host them elsewhere) > > I really appreciate your guys' help. > > Logan Washbourne > Electrical Engineering Graduate Student > (Electromagnetics) > > > On Wed, Oct 14, 2015 at 1:31 PM, Washbourne, Logan < > [email protected]> wrote: > >> 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 < >> [email protected]> 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:* [email protected] >>> <[email protected]> on >>> behalf of Washbourne, Logan <[email protected]> >>> *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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected] >>>>> > 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]> 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, [email protected] >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Sent from my Cyanogen phone >>>>>>>>>>> On Oct 2, 2015 3:12 AM, Richard Bell <[email protected]> >>>>>>>>>>> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 >>>>>>>>>>> >>> > [email protected] >>>>>>>>>>> >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> >> Discuss-gnuradio mailing list >>>>>>>>>>> >> [email protected] >>>>>>>>>>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Discuss-gnuradio mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Discuss-gnuradio mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Discuss-gnuradio mailing list >>>>>>> [email protected] >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
