Well, there's multiple things you can do; a very easy thing would be to put your external Python code into a GNU Radio block and let the GNU Radio scheduler call it as soon as there's a "chunk" of fresh samples.
You could also go for message passing, or zmq inter-process
messages. Or simply take the data out of a vector sink?
This depends a lot on what you're trying to do, i.e. the bigger
picture. What do you need these numbers for?
It's the very nature of general purpose OSes running on general purpose computers that things usually are not "continuous" in time, but happen by means of exchanging buffers with a chunk of workload at once; so possibly this isn't even a problem, because the program you want to use to work on that data might be expecting buffers of samples, too.
Best regards,
Marcus
Hello Marcus:
Thank you for the quick reply. My initial thought was that the external code would query the grc block at a rate of 32kHz. I WAS assuming that there would be a unique value available every 1/32000s. Since this is not the case, I'm left wondering how best to get all 32000samples per second out of this block and into an array in python so that I can manipulate the data. It seems as though this may be a more in depth question than I realized.
-Ed
-------------------------
Hi Ed,
to what do you need that number "delivered"? That's the interesting point here; whether your external code "polls" a function, or expects to get a message of some sorts, or listens on a socket, or...
Also note that it's not really like there's a constant "trickle" of random numbers, one every 1s/32000; GNU Radio is buffer-based, meaning that throttle gets a block of e.g. 4096 input items, passes them, and then waits 4096/32000 until it looks for new input.
Best regards,
Marcus
On 19.07.2016 20:32, Ed Coleman wrote:
Considering the simple flow graph attached, a random number is generated at a sample rate of 32kHz. I’m seeking a method to ‘expose’ the floating point number to external python code. This code would need to be updated at every 'tic' of the sample rate. Initially I had considered using the probe function but, from what I have read, it appears that is not appropriate for such a fast update rate. Any suggestions would be appreciated.
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio