Realtime Frequency Graphing - Page 1
Forum section: electronics / beginners

author: Mute
author_rank: Newbie
timestamp: March 31, 2014, 11:57:01 am
content: I have a frequency modulated signal and i'd like to plot frequency vs time. The picoscope software has a nice way to do this but my Rigol DS1074Z-S doesn't appear to have this extra functionality (unless i've missed it but i checked under the math functions).There is a frequency counter function under the "measure" section but it's really slow. For example if i configure a 1KHz square wave with a 100Hz frequency modulation and hook that to channel 1, the frequency counter shows 1KHz and doesn't update!I see from the programming guide i can log frequency over USB:Code::MEASure:COUNter:SOURce CHAN1:MEASure:COUNter:VALue?I'll give this a try in the hopes of a better update rate. I thought i'd ask to see if there are any other ways to get capture the df/dt ?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 31, 2014, 12:28:03 pm
content: I think the problem you'll have is, the scope only looks at data in its buffer. Either it does it per cycle, or it does an average over what's visible.I think most of the older ones do it by cycle. So, you need at least one cycle on screen / in the buffer, and the more cycles you have in the buffer, the less the accuracy is, because fewer samples are used for the measurement.It should be documented in the manual, how the frequency is calculated. It may be from three zero crossings (in which case the above is still true), or it could be from the number of zero crossings dividing their time span (which would average over the buffer). It could also be calculated using a peak detector on an FFT, which would be slow, but very nearly exact, especially among complex or noisy waveforms.Anyway, taking repeated measurements from a scope has the problem that, you only get a measurement when it decides to take a measurement, and it's measured from what's in the buffer. So, it depends on triggering, memory depth and (possibly) display refresh.You can more or less guarantee that the measurement will properly detect FM over several seconds, even from rather slow scopes. Measurements more often than that may be subject to any of these problems. It really depends just what they did inside -- maybe they did it were, at the moment it detects a request, it performs the calculation and pipes out the answer -- that would be ideal. But even that has the problem of USB delay and stuff... it's not very real time and predictable.I would suggest trying a higher sweep rate (so there are few cycles on screen) and as shallow a memory as you can set it to (so it has few cycles to calculate from). If you see the on-screen measurement bouncing around a lot more, you'll know you're getting somewhere. Then you might try polling it over USB, but whether you get anything consistent will be a matter of research: if you send 100 requests/sec and receive all 100 replies/sec, how many of them repeat before a new calculation is made? Do they match up with your modulation (e.g., out of a 10Hz sine modulation, do you see a sampled sine wave result? is it steppy or jumpy?) or are they just random (nondeterministic timing -- essentially, massive sampling jitter)?I think without custom software (I mean, one of those things could very easily have some serious SDR built on them, but... you'd have to get all the internal programming and hardware interfaces, and good luck with that?), you'll have a hard time doing it; better to build a proper F-to-V, or PLL, or frequency counter with a short sample gate, or something like that, to really get a solid measurement of this sort of thing.Tim