On Tue, Oct 20, 2015 at 8:46 AM, <address@hidden> wrote:
Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 <address@hidden>
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, AllHow 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" <address@hidden>
To: address@hidden
Cc:
Date: Mon, 19 Oct 2015 10:47:12 -0700
Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 22On Mon, Oct 19, 2015 at 9:01 AM, <address@hidden> wrote:Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 <address@hidden>
To: GNURadio Discussion List <address@hidden>
Cc:
Date: Sun, 18 Oct 2015 18:18:27 +0200
Subject: Re: [Discuss-gnuradio] Passing GUI widgets into hier block with parametersHello 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.Przemek2015-10-15 20:38 GMT+02:00 Przemek Lewandowski <address@hidden>: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: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.Thank YouPrzemek Lewandowski
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--John D. Hays
K7VEPO Box 1223, Edmonds, WA 98020-1223![]()
![]()
---------- Forwarded message ----------
From: Przemek Lewandowski <address@hidden>
To: "John D. Hays" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Date: Mon, 19 Oct 2015 20:11:28 +0200
Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 22Sorry for mistake, I suspected that something can be wrong with my email on forum. Im using Gmail and didnt realized about wrong mail format.Thanks2015-10-19 19:47 GMT+02:00 John D. Hays <address@hidden>:On Mon, Oct 19, 2015 at 9:01 AM, <address@hidden> wrote:Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 <address@hidden>
To: GNURadio Discussion List <address@hidden>
Cc:
Date: Sun, 18 Oct 2015 18:18:27 +0200
Subject: Re: [Discuss-gnuradio] Passing GUI widgets into hier block with parametersHello 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.Przemek2015-10-15 20:38 GMT+02:00 Przemek Lewandowski <address@hidden>: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: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.Thank YouPrzemek Lewandowski
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--John D. Hays
K7VEPO Box 1223, Edmonds, WA 98020-1223![]()
![]()
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
---------- Forwarded message ----------
From: Geof Nieboer <address@hidden>
To: address@hidden
Cc:
Date: Tue, 20 Oct 2015 00:11:58 +0300
Subject: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testingHello 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 <address@hidden>
To: Julio Hector Aguilar Renteria <address@hidden>, discuss-gnuradio <address@hidden>
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:Are you using a GNU Radio flowgraph? Or are you writing code directly using the GNU Radio python API or UHD C++ API?-TripOn Mon, Oct 19, 2015 at 1:12 PM, Julio Hector Aguilar Renteria <address@hidden> wrote:Hi, AllHow to use an external GPS reference in the USRP B200 ?, I do some extra configuration on the USRP B200?
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
---------- Forwarded message ----------
From: "West, Nathan" <address@hidden>
To: Geof Nieboer <address@hidden>
Cc: "address@hidden" <address@hidden>
Date: Mon, 19 Oct 2015 17:37:38 -0400
Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testingOn Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <address@hidden> 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,GeofHi 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 <address@hidden>
To: address@hidden
Cc: "address@hidden" <address@hidden>
Date: Tue, 20 Oct 2015 09:53:23 +0300
Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testingNathan,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.GeofOn Tue, Oct 20, 2015 at 12:37 AM, West, Nathan <address@hidden> wrote:On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <address@hidden> 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,GeofHi 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 <address@hidden>
To: GNURadio Discussion List <address@hidden>
Cc:
Date: Tue, 20 Oct 2015 17:42:45 +0900
Subject: Re: [Discuss-gnuradio] Suggestions for C++ Coding of a new PRNGThen 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.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.
---------- Forwarded message ----------
From: Tom Rondeau <address@hidden>
To: Geof Nieboer <address@hidden>
Cc: "address@hidden" <address@hidden>
Date: Tue, 20 Oct 2015 09:54:57 -0400
Subject: Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testingOn Tue, Oct 20, 2015 at 2:53 AM, Geof Nieboer <address@hidden> 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.GeofGeof,This is fantastic, thanks!Please send pull requests on github with your patches when you can.TomOn Tue, Oct 20, 2015 at 12:37 AM, West, Nathan <address@hidden> wrote:On Mon, Oct 19, 2015 at 5:11 PM, Geof Nieboer <address@hidden> 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,GeofHi 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
---------- Forwarded message ----------
From: "Washbourne, Logan" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Cc:
Date: Tue, 20 Oct 2015 10:46:11 -0500
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the AirI really appreciate your guys' help.(If the attachments don't make it through the mailing list, please let me know and I can host them elsewhere)These pictures are of the same communication session, screen-printed roughly 5 secs apart.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.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.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.(Electromagnetics)Logan WashbourneElectrical Engineering Graduate StudentOn Wed, Oct 14, 2015 at 1:31 PM, Washbourne, Logan <address@hidden> 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?(Electromagnetics)Logan WashbourneElectrical Engineering Graduate StudentOn Wed, Oct 14, 2015 at 9:43 AM, Nowlan, Sean <address@hidden> 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=address@hidden <discuss-gnuradio-bounces+sean.nowlan=address@hidden> on behalf of Washbourne, Logan <address@hidden>
Sent: Tuesday, October 13, 2015 12:03 PM
To: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Correlation Estimator Over the AirRich,
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.
(Electromagnetics)Logan WashbourneElectrical Engineering Graduate Student
On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell <address@hidden> wrote:
RichI 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.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.Logan,How are you doing this test to see if the bit stream comes out?
On Mon, Oct 12, 2015 at 1:28 PM, Washbourne, Logan <address@hidden> wrote:
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.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.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.
Does anyone have any suggestions?
I know this thread is getting a little long, but I appreciate everyone's patience with my questions.
(Electromagnetics)Logan WashbourneElectrical Engineering Graduate Student
On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell <address@hidden> wrote:
RichAh, 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.
On Wed, Oct 7, 2015 at 9:09 AM, Washbourne, Logan <address@hidden> wrote:
Do you have any advice?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.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.
(Electromagnetics)Logan WashbourneElectrical Engineering Graduate Student
On Wed, Oct 7, 2015 at 10:47 AM, Richard Bell <address@hidden> wrote:
RichThe 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.which feels more natural to me.Previous email sent without me telling it to. Picking up from "Fuction coped below:"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, 1.0/float(sps), eb, 5*sps*nfilts)
firdes.root_raised_cosine(nfilts, nfilts*sps, 1, eb, 5*sps*nfilts)
On Wed, Oct 7, 2015 at 8:41 AM, Richard Bell <address@hidden> wrote:
The way the default values of the pfb clock sync block are entered can be a little confusing. Function copied below: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.Logan,I recommend you keep this conversation on the mailing list. You are more likely to get answers that way.
On Wed, Oct 7, 2015 at 8:34 AM, Washbourne, Logan <address@hidden> 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?
(Electromagnetics)Logan WashbourneElectrical Engineering Graduate Student
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 iPadSent 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
_______________________________________________
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
John D. Hays
K7VE
K7VE
PO Box 1223, Edmonds, WA 98020-1223 ![]()
![]()
![]()