Yes, it worked but the CPU load is immense as the function probe is
probing about as fast as it can and of course there is still overhead in
looking up the time. Basically if the time in seconds is the same as
last time it just returns the previous sample without repeating any
calculations. I will try and sync it to the sample rate to see if that
slows it down.
Mike
From: Seth Hitefield [mailto:[email protected]]
Sent: 30 November 2014 16:25
To: Mike W.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Sampling slowly
That may work, but it may cause problems with the scheduler if you are
using stream ports.
Sent from my iPhone
On Nov 30, 2014, at 10:47 AM, Mike W. <[email protected]
mailto:[email protected] > wrote:
I looked at that but I don’t know how to and it’s extremely difficult to
understand. It is probably possible to bodge using the system timer to
avoid a re-calculation if called within less than a specific time, e.g.
10 seconds. This is what I am thinking at the moment. Basically reduce
the workload.
Mike
From: Seth Hitefield [mailto:[email protected]]
Sent: 30 November 2014 15:35
To: Mike W.
Cc: <[email protected] mailto:[email protected] >
Subject: Re: [Discuss-gnuradio] Sampling slowly
I would suggest looking at the message-strobe block and using messages.
Sent from my iPhone
On Nov 30, 2014, at 10:11 AM, Mike W. <[email protected]
mailto:[email protected] > wrote:
Looking for help
I have written a source block to do satellite predictions. It acts as a
source of a float representing the input parameter – e.g. elevation. The
block probes predict via UDP, looks at the string returned and selects
the asked for parameter.
So far fine, but I would like to probe it slowly, not on every sample.
This appears to be impossible. If I use a probe and function probe and
ask it to update each second, the probe grabs data from the source runs
at full sample rate. Unfortunately probe seems to have almost no
documentation and I don’t understand the source but I assume it goes as
fast as it can get input samples.
If I try combining say an add block with a decimated version of the
sample rate (coming from a USRP) and probe again, it still runs too
fast. It is as if it is trying to cache a set values. Logically I can
see that might be useful to maintain a constant rate where blocks take
different times.
Is there a simple fix or do I need to implement some form of trigger
port – and if I do will it still cache data?
Mike