Re: [Discuss-gnuradio] Fwd: Multiplying the inputs with a scalar/vector in my own block

[Marcus Müller]

Hi Pavan,

I already answered on the list. But here goes my text again:

Hi Pavan,
1)
if you really just need one tone, try a sampling rate like 500kS/s, and transmit a constant. Use the offset tuning capabilities to put the tone away from the LO leakage, to avoid cancellation.
2)
Yes. C++ blocks tend to be much much faster. The fact that you're seeing underruns proves that your PC couldn't keep up with the sampling rate you used.

Best regards,
Marcus

On 09.06.2016 19:19, Pavan Yedavalli wrote:

I didn't receive a post acknowledgment, so just sending again! Sorry for the redundancy, if so.

---------- Forwarded message ----------
From: Pavan Yedavalli <address@hidden>
Date: Thu, Jun 9, 2016 at 9:58 AM
Subject: Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block
To: GNURadio Discussion List <address@hidden>

Hi Marcus,

Thanks for getting back to me. This seems to make sense, but I guess wrt your suggestions for moving forward:

(1) You said a bit of trial and error would be good. Can I trial and error with my sample rate? This is the value in the USRP sink block and on the signal sources, correct (see attachment)? And just to be clear, this is sample rate, and not clock rate, correct? So, I should try to reduce that from 1 MHz to something smaller just to see what would happen? Since my application isn't driven on samples of data, I don't believe I need a high sampling rate - I just want a single tone to be transmitted with no data, so I think I'm okay with the sampling rate being smaller. Is this one approach to take? I guess I'm not sure how to determine what would be a good sample rate for my application. Is there a decent rule of thumb?

(2) Are you suggesting that I do my created block in C++ instead of Python, and if so, could I still use GRC/python to use the block in the overarching system? Speed clearly is an issue, but I didn't think (know?) that my requirements of sample rate was so high. I guess I will try (1) first and see whether my application functions the way I want it to with a trial/error of low sample rate, but if it doesn't and I need to have a high sample rate, then I will move toward implementing the block in C++. Is that a reasonable approach moving forward?

Thank you again for your patience and help.

--

Pavan

--

Pavan

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio