Marcus, thank you for all the suggestions. This is a great group. Yes for development I do not need the Zedboard, but for my experimental system I need this to interface with my receiver circuitry. And yes it turned out to be a software/OS system issue which I fixed.
I was able to figure out the frequency counter, thanks for the suggestions about the implementation. A last issue I am facing and wondering if there is anything that can be done is that my carrier frequency of my transmitter is drifting by ca. +/- 3 MHz (0.07%),(this is a separate issue I will deal with). However for now, this is causing me to have to re adjust the LO receiver frequency on my GNUradio script when I no longer see the received pulses, in order to re-"find" the carrier frequency. My RX bandwidth is set to 20MHz (I tried higher too) so I am unsure why a +/- 3MHz would drift the signal out of range. I am simply taking Complex-to-Mag on the received signal. My question is, is there anyway in GNURadio that I can automatically find the center frequency peak and update the LO frequency while the program is running so I don't lose the signal? Or, implement a wider receive bandwidth. Per your last comment, the RFComm block is here: https://wiki.analog.com/resources/tools-software/linux-software/gnuradio On Wed, May 18, 2016 at 3:05 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Rob, > >When I boot my system, I get the below error. When I try to log out from > the Applications Menu, I get the error below that. Any suggestions wold be > great as I am stuck at the moment. > > to be brutally honest: you don't need a zedboard to run GNU Radio to > prototype this kind of thing: Just grab anything that contains GNU Radio > and runs on your development PC; for example, the GNU Radio live DVD. I'm > very sorry, but this looks like there's some OS/environment specific > problem with what you're running on the Zedboard, and the discuss-gnuradio > mailing list might really not be overly helpful with that. > > > It seems the script is not receiving/time-stamping the incoming signal > correctly. I think it may be in the way I am configuring the FMComms2 > block to take in my data but I am not sure. In the below plots, the > frequency counter is showing around 2.5kHz, but my modulating frequency on > my transmitter is set to 49.94k > > Hm, the main thing here is that you of course need to scale the length of > the moving average and its scale factor according to your actual sampling > rate. There's nothing in my flow graph that would react to any time stamps: > It only sees a sequence of numbers and assumes you used the right sampling > rate in calculating these settings. Otherwise, you'll get something that is > off by some factor. So make sure the RFComm source is really running at the > 320kSps you configured it to. And, of course, get rid of the throttle block > – a throttle block does nothing but slow down the amount of samples > processed per second, and should never be used in a flow graph that > contains an actual hardware sink/source. Generally, in this kind of DSP, > there's no "additional" info like sample times or rates attached to samples > – they're nothing but numbers in a very long row of numbers > > When you look at your time signal plot, you'll notice a little more than > about 7.5 signal periods in what is displayed as 3ms – which would be 2kHz, > not the 49.9kHz you claim. So, I'd look into that; if you don't use the > same LO to generate the tone, however, then a frequency offset of ca 47kHz > at a center frequency of 4.2514 GHz is about 11ppm – that's not an overly > great value for a frequency accuracy, but would still be in the league of > possible things (as we know nothing on what lurks below the RFComm3 block > so far ;) ). > > Best regards, > Marcus > > > On 17.05.2016 18:44, Rob Croce wrote: > > Marcus, sorry I have not responded to your suggestions but I have issues > with my system, maybe the experts here can provide some guidance. GNURadio > fails to open so I cannot run my tests. > > When I boot my system, I get the below error. When I try to log out from > the Applications Menu, I get the error below that. Any suggestions wold be > great as I am stuck at the moment. > > I am running GNURadio on the Zedboard with the ADI FMComms3. > > > > > > > On Fri, May 13, 2016 at 10:26 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Hi Rob, >> >> hope I didn't come on too cross yesterday; of course, the frequency >> counting method works just as well, if you know your edges are sharp and >> you can pinpoint a certain threshold. >> >> I come from a very SDR-y background myself, and so I always presume your >> signal quality will need significant rework until you can just measure the >> distance between two rising edges. And instead of doing that, I'd just look >> for the peak in the FFT (or do a parametric frequency estimation, or >> something else – more often than not, the optimum way either depends >> heavily on the model of your signal, or it's not even easy to find one >> optimal method, because many methods work). >> >> That being said: You could implement your own frequency counter. In fact, >> doing so can be extremely simple: >> >> You could simply count the number of edges during e.g. one moving average >> period. >> >> The idea would then be to convert your edges to single-sample impulses; >> to do that, I'd high-pass your input signal; in fact, a filter that just >> subtracts the last sample from the current one (taps=1,-1) will do just >> fine for sharp edges (use an optimized (=bandpass?) filter and/or a schmitt >> trigger (the Threshold block acts like on) before that filter if your >> signal doesn't work like that ). >> Since we only care about rising edges, let's cut off all the negative >> edges by using a Threshold block, and then sum everything up using the >> "moving average" block (which I think we should rename to "running sum"): >> >> >> >> >> Best regards, >> Marcus >> >> >> On 13.05.2016 14:37, Rob Croce wrote: >> >> Thank you for the suggestions. I do in fact come from a very analog >> background, I have implemented many frequency counters in micro's, so I am >> thinking in this way. I will try the suggestions on FFT/frequency sinks. >> >> On Thu, May 12, 2016 at 4:58 PM, Marcus Müller < >> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote: >> >>> By the way, I can barely decipher your screenshot. I strongly recommend >>> using the screenshot functionality of your operating system instead of >>> using a camera to digitize the analog lightwaves that were generated from a >>> screen that converted the digital picture to light... >>> that being said, I don't really understand your question >>> >>> The time between rise and fall is known since it is plotting it on the >>> time axis, >>> >>> So: What is the very definition of "frequency"? Right, it's the rate at >>> which a periodic thing happens. >>> so you measure the time distance between two rising edges, and do >>> 1/that, and instantly have the frequency. >>> That's a very "analog measurement device" or "cycle counting" way of >>> doing this. >>> >>> oscilloscope calculates and displays a frequency number. >>> >>> Hm. What do *you* think the oscilloscope does? >>> Dan's recommendation was absolutely on-spot. Use a spectrum/fft sink. If >>> you don't understand what "spectrum" is, read a bit wikipedia :) That's >>> really the easiest way I could think of. >>> Other than that, read up on autocorrelation, and how to calculate it in >>> a DSP system. >>> >>> Best regards, >>> Marcus >>> >>> On 12.05.2016 22:38, Rob Croce wrote: >>> >>> OK thanks. I just need to display a number for the frequency of the >>> pulses. The time between rise and fall is known since it is plotting it on >>> the time axis, so I am wondering if there is anyway I can extract frequency >>> that way. Similar to frequency counting on a micro, or how an oscilloscope >>> calculates and displays a frequency number. >>> >>> On Thu, May 12, 2016 at 4:30 PM, Dan CaJacob < <dan.caja...@gmail.com> >>> dan.caja...@gmail.com> wrote: >>> >>>> I would need more details about what you're trying to accomplish, but >>>> my first reaction would be to attach an FFT GUI sink. >>>> >>>> On Thu, May 12, 2016 at 4:26 PM Rob Croce < <rob.cr...@gmail.com> >>>> rob.cr...@gmail.com> wrote: >>>> >>>>> Hi all. I have transient pulses that I am displaying using the >>>>> transient plot, and I am wondering how I can display the frequency of the >>>>> pulses. The duty cycle is similar for all pulses, just the frequency is >>>>> varying. Is there a simple way to do this? >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> -- >>>> Very Respectfully, >>>> >>>> Dan CaJacob >>>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://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
