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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 >>> <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> -- >>> Very Respectfully, >>> >>> Dan CaJacob >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto: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
