|Subject:||Re: [Discuss-gnuradio] Display frequency from transient plot.|
|Date:||Wed, 18 May 2016 21:05:26 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0|
>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 ;) ).
On 17.05.2016 18:44, Rob Croce wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|