Thanks, Marcus. Your vector source looks a lot simpler!
Spent more time with it, and may have discovered what's going on. The drfiting is actually sawtooth periodic, and ceases when the samp_rate is a power of two. This suggests that there is an NCO type of oscillator behind the source, and there is excess phase accumulation when the samp_rate is not a power of two. That excess eventually rolls-over and resets. At higher sample rates it's easier to see. At high samp_rate (384000) the error in time is almost, but not quite one time sample. The error appears to be bounded. For the application being debugged, that bounding is important (slipping cycles is bad). I like Python, but use it infrequntly enough that I forget about it capabilities until the need to solve a specific issue arises, then its fast-re-learning time. My background many years ago was in digital IC design, so that is programmed into old neurons. -- Tom, N5EG On Sat, Dec 5, 2015 at 2:48 AM, Marcus Müller <[email protected]> wrote: > Hi Tom, > > first of all: Nice flowgraph! I especially like this part: > [image: flowgraph] > to give you a single 1 every 1000 samples; I'd never come up with this! > Also, from looking at this, I'd say you're a digital designer; how far am > I off? [1] > > So, to your actual problem: I guess you're right, there's a problem with > numerical accuracy. > I made a quick demo flow graph: > [image: sampler] > which, in theory, should be output constant 1, but instead shows the slow > drifting. > I do think this is in the range of what I'd expect of numerical accuracy, > but as I don't have the time to test this right now, I'm attaching my test > flow graph. The right thing to do would be calculating the angular speed of > the output and see how large it is compared to the angular precision of > float32 put through cos(.). > > Best regards, > Marcus > > > > > [1] My much more signal-theoretic approach would have been this: > [image: interpolation] > i.e. interpolating a stream of 1s with a filter that isn't actually doing > anything, i.e. has "[1]" as taps. > Or, even shorter: > [image: Vector source] > because GRC / python allows us to just specify a vector that we sample. > > On 05.12.2015 06:15, Tom McDermott wrote: > > After some further investiagation, it appears that this may be a slow, > long term > analog drift in the cosine wave source (perhaps due to single precision > math?). The > voltage values aren't the same at each point in the waveform - they slowly > drift > over many minutes of computer runtime. > > -- Tom, N5EG > > > > On Fri, Dec 4, 2015 at 3:48 PM, Tom McDermott <[email protected]> wrote: > >> In working on some waveform sampling tests, have encountered an apparent >> drift >> between two gnuradio sources that are run at the same rate. I've tried >> to structure >> the flowgraph so that the QT GUI does not get involved in the exact >> sample count >> integrity between two flow graph paths. >> >> The attached flowgraph constructs a sampling pulse near the zero-crossing >> time of >> the cosine wave, then displays that sampled analog value. Over time, the >> cosine >> source appears to be slipping in time compared to the square wave source. >> The >> analog sampling pulse samples the cosine source 'near' the zero crossing. >> But with >> increasing run-time of the flow graph, it appears to be drifting off. I'm >> at a loss to >> explain this. >> >> Attached is the simplest GRC flowgraph that demonstrates the effect. It >> needs to >> run for a few tens of seconds before the analog sampled value starts to >> grow. >> The time sample at 6 milliseconds is the sampled analog value. Even if >> it's not exactly >> zero, it should remain relative stable in analog value. >> >> Any advice on what I might be doing wrong here? >> >> -- Tom, N5EG >> >> >> >> >> >> >> > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > 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
