Hi Santos, you're not actually describing your problem all that well, but there's the central question:
Are you using a throttle block, or is your flow graph rate-limited by a hardware device (e.g. a USRP or HackRF or Audio sink)? ===Not using throttle or rate-limiting hardware=== GNU Radio just works as fast as it can. The sampling rate you configure in your signal source has nothing to do with how fast that signal is generated – it just says "ok, generate a signal with period f_signal/f_sample samples". This is DSP – everything is measured in sample durations, and there's no "real world time" involved in any of these calculations. Hence, your number sink will just show the value of an incredibly fast changing signal at the time it updated its display. Not very useful ===Using throttle or other rate-limiting blocks=== You might be under the wrong impression that if you use throttle e.g. with 1kHz throttle rate, you'll actually get one sample every 1ms. That's not the case – GNU Radio generally works on sample chunks, ie. the signal source fills its output buffer as fast as it can, GNU Radio wakes up the downstream block, and hands it everything there is in that buffer. So assume, that, for example, the block that limits your rate (throttle, hardware interface) gets handed 8192 samples at once. It will now take the time it needs to process these 8192 samples – for example, with a throttle set to freq=1k, it will copy these 8192 samples from in- to output, and simply sleep for 8.192s! In other words, your number sink does see 1000 samples per second _on average_, but in much, much greater chunks than 1 sample at a time. Hence, for really low rates, where your eye is faster than the number of sample packets per second that are generated, your number sink simply gets an update very seldom, and when it gets it, it's going to be a lot of samples at once. Best regards, Marcus On 06.09.2016 21:17, Santos Campos wrote: > Ah that did slow it down to more real time! > > So, data isn't really streaming out of the signal source block like > the parameters would suggest, is it? > My expectation with forcing a long period was it'd stream high for 10s > and low for 10s. > > On Tue, Sep 6, 2016 at 1:24 PM, Nicolas Cuervo > <[email protected] <mailto:[email protected]>> wrote: > > Hi Santos, > > inside the number sink there is a field called "Update Period", > which you can reduce to a value that suits your needs. For what I > understand of your setup, maybe you have a rather big number here > in comparison with the update rate of the sink. Try reducing this > value and let us know if this helps you solve your problem. > > Cheers, > > -Nicolas > > On Tue, Sep 6, 2016 at 7:49 AM, Santos Campos <[email protected] > <mailto:[email protected]>> wrote: > > Hello, all! > > I'm using a square wave to make a clock(frequency = .05 Hz, > Period = 20s). > It shows up well in a time sink, but has trouble gaining > stability in a number plot. > > How can I get the number sink to update in real time? > > Thanks and any help is much appreciated! > > -Santos > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > > > -- > /* > Santos Campos > University of Michigan '17 | Computer Engineering > Virtual EM Inc | Engineering Intern > santosecampos.com <http://santosecampos.com> > (269)419-5113 > */ > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
