All right, that makes me feel better. A few corrupted samples is perfectly fine since the setting should only change before transmitting/receiving, not during.
Thanks, Sean On Tue, Dec 20, 2016 at 10:21 AM, Kevin Reid <kpr...@switchb.org> wrote: > On Tue, Dec 20, 2016 at 8:38 AM, Sean Horton <seanhorto...@gmail.com> > wrote: > >> What is the best way to change settings such as gain, taps, frequency >> values, etc of various blocks while running? The current setup I'm >> refactoring receives new configs over tcp, and a block outputs the new >> config values to probe signals, and those probe signals are used to change >> various settings. In the case of setting some usrp source parameters >> (center frequency), it appears to not properly work, so for the usrp sink >> and sources, I am going to pass messages to change the parameters. This >> isn't possible for other blocks, though, as they do not have message >> inputs. >> >> If I should stick with the current method, though, I'm really curious how >> there is mutual exclusion, as the values are being changed while the >> flowgraph is running. I have looked at the source code for some of the >> blocks I'm using, and I don't see any mutexes. This makes me think this >> isn't the best way to do what is being done. >> > > Calling the setter methods is fine. Mutexes are not necessary for simple > numeric parameters, because one thread (the block work thread) is only > reading and one thread is only writing (your control thread) and there are > no particular invariants to be maintained. > > The worst thing that could happen is reading a half-written large value > and producing bad data for a period, but changing parameters in many cases > will result in some kind of “glitch” in the sample stream anyway, so this > is merely “noisier”. > -- Sean Horton
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
