Look at the FLL; It's nothing but a system that locks on tho the energy that goes through a pass band's edges; if there's suddenly more energy in the upper edge band, it corrects the frequency so that it follows up, and vice versa. However, 0.07% = 700 ppm. I've never met an oscillator that bad; the worst you can buy on mouser.com is 200ppm, and I don't think someone who's building RF eval boards will use something like that. There's something going horribly wrong with your hardware setup, here; probably some oscillator control loop running wild, rotten to the core.
Best regards, Marcus On 24.05.2016 23:52, Rob Croce wrote: > 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 > <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> >>> 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 >>>> <[email protected] <mailto:[email protected]>> >>>> 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 >>>> <[email protected] <mailto:[email protected]>> >>>> 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> -- >>>> Very Respectfully, >>>> >>>> Dan CaJacob >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
