|
Hm, yes, for things that move really slowly this of course works
– I can't argue with that (nor can I argue with Marcus the First);
I'd just argue that the algorithm Sean describes sounds so
complicated that intuitively, it sounds like what he'd *like* to
have is some DSP on a downsampled version of his signal.
But maybe I should have *asked* about that, before jumping to
conclusions; so:
Sean, what is the purposeof this operation? As in: what's the
physical meaning of the in- and output of all this?
Best regards,
Marcus
Meh, I use function probes to capture 'stuff' that changes
slowly--timescales of seconds or tens-of-seconds.
I wouldn't do this for faster stuff, but doing that allows you
to use "ordinary" python in a python module, with the probe
value as calling parameter.
On 2016-12-21 11:47, Marcus Müller wrote:
Hi Sean,
you really shouldn't be doing that at all.
If you want to do signal processing, write a simple python
block that operates on a sample stream.
The signal probe is really just that, for sporadic "debug"
and "display" operation, not for any "useful" application.ö
Best regards,
Marcus
On 21.12.2016 17:30, Sean Horton
wrote:
I have a function probe to get an int from one
block's output, and been using a function probe to get the
value of the probe signal. I now want to have the block
output a vector of ints, and use a probe signal vector to
capture them, and nave a few function probes to get index 0,
1, and so forth. How do you do that? It does not seem to be
as simple as replacing level with leve[index] (where index
is 0, 1, etc) in the function probe's function name field.
In my test setup, the function probe never changes from the
default value, which is not one of the values in my vector
source I'm using for testing.
--
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|