So I have a Rigol DS1054Z connected to a signal generator. What I found was that the frequency measurement accuracy if the scope is horrible.
I'm measuring a 134 KHZ signals, 5V PP. My multi-meter accurately reads the correct frequency but the scope will read 131 KHZ and if I increase the frequency just a bit it jumps to 139 KHZ and the multi-meter still reads correctly.
Has anyone run into this type of error? For now I can't rely on the scope at all.
if your sample rate is too low, edges will not be reconstructed correctly. How many cycles are on screen when you make the measurement? and how fast is your sample rate?
@James, thanks for the help. I was at a 20us time base. I have 134KHZ signal to measure and at 2us and 4 cycles showing the scope measures correctly but as I up the time base it goes south. Here are the readings:
2us 134KHZ
5 133
10 135
20 131
50 143
100 125
However, a little googling lead me to turn on the "measure | counter" and that accurately shows the frequency at all time bases.
I can't trust the Rigol scope's measurements. As a matter of fact what lead me here is I'm trying see the modulation from a pet animal FSK 134.2 microchip and can't display it at all. I need a higher time base than the carrier to see the frequency modulation. I thought it was operator error but now I'm wondering if the scope is even capable.
Is this typical of digital scopes? I'm wondering if a Textronix would be better or if I need a spectrum analyzer...
zappullae:
I was at a 20us time base.
That's not what I asked. I asked about the sample rate. Without know how your memory depth is configured, I have no idea what the sample rate would be at that time base setting.
zappullae:
but as I up the time base it goes south.
Again, this is related to the sample rate. If you aren't getting enough samples on the edges, especially if it is a fast edge coming out of a signal generator, menu the measurement attempts to find the (by default) 10-50-90% points, they'll be "moving" around.
zappullae:
However, a little googling lead me to turn on the "measure | counter" and that accurately shows the frequency at all time bases.
This difference is because the Rigol scopes include a hardware frequency counter. So this is using a hardware method to measure the frequency, instead of the software measurement. (It is just like having a standalone frequency counter.)
zappullae:
I can't trust the Rigol scope's measurements.
Yes, you can. But first, it sounds like you need some education on how a digital oscilloscope samples data and makes measurements.
zappullae:
I need a higher time base than the carrier to see the frequency modulation.
You may need to enable long-memory captures. Scopes tend to turn off deep memory by default so that their update rates stay reasonable. In the Acquire menu, you should have the option of increasing the memory depth. This setting will enable you to get higher sample rates on long timebases. (It also allows the opposite.) The best case it should be 10x the fastest component of your signal. (Rarely is an option.) 5X is better. 2.5X is the minimum for decent automated measurements.
You may also need to go into the Measurement settings and change from 10-90 to 20-80 measurements. If there is ringing on the signal, that will throw off the automated measurements as well.
zappullae:
I thought it was operator error but now I'm wondering if the scope is even capable.
I was a field application engineer (FAE) for a scope company (not Rigol) for 10 years. Every single time someone complained "the scope isn't accurate!" or "It can't make that measurement!" it was a result of operator error. I include using the wrong scope as operator error. (Using a 1.5GHz scope to measure a 1GHz signal with a 2ns rise time.)
zappullae:
Is this typical of digital scopes? I'm wondering if a Textronix would be better or if I need a spectrum analyzer...
Midrange scopes operate similarly. The only advantage a different model or manufacturer would be if you got deeper memory and faster sample rates. (But if you go with higher sample rates, you need even more memory.) With a digital scope, memory depth and sample rate are far more critical than the timebase setting. The timebase setting just tells you how long of a capture you get. Longer captures require either a slower sample rate or a long memory depth.
If the fundamental of what you're measuring is 134kHz, that means you are tending to look at very long capture times. The scope is likely dropping the sample rate (and memory depth) to fill the screen. It may be sampling too slowly for the signal. You need to force it to use more memory or lock the sample rate--in the acquire menu.
Is this typical of digital scopes
No its definitely not
Rigol seem OK but you get what you pay for
This is far better, about the same price as a Rigol as well
http://uk.farnell.com/keysight-technologies/edux1002a/digital-storage-osc-50mhz-2-ch/dp/2690190
Edit
James theres no excuse, it cant be put down to operator error IMO. its a pathetic 134kHz signal the scope is MHz. the sample rate should be automatic
I have used many scopes in my time, never ever have I seen such a chronic error as the OP claims
its simply not good enough
edit 2
if the sample rate wasnt high enough then the waveform would be distorted and you would say, thats not right!
It appears the OP didnt have that issue just the numbers were out by a ridiculous amount
Obviously only the OP knows how the outputs looked maybe a picture would help
I'm going to amend one of my previous statements. I have an MSO2202A and a function generator. I can see what you are seeing. And I have a revised explanation for the "issue." It's a sampling problem, but probably not related to the sample rate. Long story short: when you use the automatic (or built-in) measurements, the scope software works best when there is ONE event on screen.
I never asked, what is your source for the signal? Let's look at two different sources and see the results.
Measuring with Function Generator
Image 01 - 134kHz Single Cycle
So in image 01, you can see a single cycle, I measure 134kHz as expected. When I "zoom out" to 20us (show in 02), I see 131kHz. Stable, but changed. For 03, I forced the memory depth to 1.4Mpts which now gives a 138kHz measurement. In my case, I'm sampling 2Gs/s in all cases. So what's going on?
Image 03 - 20uS at 1.4Mpts
Well, as you get to longer time bases, the scope display has more sample points than pixels.So it starts to drop some of those points. Which, on "real" signals, isn't typically an issue. A 134kHz signal will have a relatively slow rise time. A rise time of 2.5us wouldn't be unheard of, but still, you'd expect something in the microsecond range.
I never asked what YOUR source was, but my source is a function generator. So look at #04. That's the rise time measurement from my function generator. It's about 15ns. About 100-150 times faster than a natural 134kHz signal would have.
Image 04 - Function Gen Rise Time
Turns out that most of the scopes in the class, make measurements with the on-screen data set. Not the data stored in acquisition memory. So for display reasons, points are getting dropped. Which means placement of the 50% threshold is moving around on this fast edge. Which is why at slower time bases you're seeing a different measurement.
Okay, so does that mean all digital scopes are shit? Well no. It's an engineering tradeoff between keeping the scope waveform lively and making reasonable measurements. (And a great reason why they included a hardware frequency generator. Frequency is the most common and most affected measurement with this tradeoff.)
The signal has a 15ns rise time on a 134kHz signal. That's way out of whack for what this scope normally sees.
Here's a more realistic example: Arduino
I'm using my Arduino Uno to generate a 60kHz signal. (I shot for 134kHz but did the math wrong. Also, I'm using digitalWrite instead of port manipulation, so occasionally a signal with a 2x time period sneaks in. So I'm using gating to minimize that messing up the measurement stats.)
First, #05, single waveform. Measuring 60.6 kHz. (The "ghost" you see from persistence is the 2x time periods messing up the experiment.)
Image 05 - Arduino 60 kHz
Next, #06, 20us with multiple waveforms, Measuring 60.9 kHz.
Image 06 - Arduino 60 kHz
Much closer than we saw with the function generator. But what's going on? Well, even though this is a "real" signal, the Arduino's rise time is still pretty fast, as #07 shows. It's about 3ns. Still very fast for a 100kHz (ish) signal.
Image 07 - Arduino Rise Time
Lesson
Automated measurements on a digital scope are best done with a single event on screen. AND, watch your rise times.
One more thing...
I should point out that higher-end digital scopes WILL use sampled plus interpolated data for reconstructing edges when making measurements. They'll also measure every event on screen or in memory to increase statistical samples. But that's a difference class of scope that generally runs about 10X the price.
AAANNNDD before the rabble-rousing of "but I DON'T WANT TRADEOFFS! I want my long capture waveform AND my accurate single cycle measurement!!"
That's what the "Delayed" mode in the timebase menu is for... See attached. (Some scope manufacturers call this "zoom mode".)
James,
I just received a Rigol 1104 yesterday. Would you please show the arduino test setup you mention? I have never used an oscilloscope.
Thanks
@James, the sample rate is 1 GSA/sec and memory depth was set to Auto. I tried all the memory depth settings and they did not change the frequency measurement at all.
@Resonator, I agree this is a pathetically slow signal to measure especially given I have the Rigola hack applied and it should be a 100MHZ scope with only 1 channel being measured.
So, any suggestions on how to capture the frequency modulation other than a new scope?
zappullae:
@James, the sample rate is 1 GSA/sec and memory depth was set to Auto. I tried all the memory depth settings and they did not change the frequency measurement at all.
See my revised post with screen shots embedded.
zappullae:
@Resonator, I agree this is a pathetically slow signal to measure especially given I have the Rigola hack applied and it should be a 100MHZ scope with only 1 channel being measured.
Again, see my revised post with screen shots embedded. It is how digital scopes in this class work.
zappullae:
So, any suggestions on how to capture the frequency modulation other than a new scope?
You are perfectly capable of capturing a frequency modulation at 134kHz. Use the FFT in the Math menu. You aren't going to see a modulation with the statistical measurement.
Also, looking at your screen shots. You MUST fill the screen with your waveform. Otherwise, you WILL get inaccurate measurements. Using half the screen means using only half the resolution of the A/D.
Lastly, it is best to keep the Trigger level near the center of a P-P waveform., not near the bottom like you have it.
@James, my source is a signal generator. It was a tank curcuit but to narrow down why I'm not seeing the frequency modulation I simplified and ended up with signal generator connected to the tank circuit and then even more to just the signal generator when I noticed the carrier frequency was off, at least I thought it was off given the reading on the scope.
Also, I looked at the FFT feature and would have expected a change in the peak around 134khz when a tag was on the coil. Unfortunately I don't see any change at all with or without the tag in place.
zappullae:
would have expected a change in the peak around 134khz when a tag was on the coil.
I don't know what you mean by "tag".
When I'm doing FFT, especially on a repetitive signal, I'll load way more cycles on screen then I can see. The more data you give the FFT, the more accurate it will be. Right now, it is pretty course. I'll also switch to Single-capture trigger so that I can make adjustments without the scope chugging along with each new acqusition.
By the way...
Your previous comment, "I agree this is a pathetically slow signal to measure especially given I have the Rigola hack applied and it should be a 100MHZ scope with only 1 channel being measured." is a common fallacy.
More bandwidth does NOT mean a more accurate measurement (all the time). In fact, on a slow signal with a slower rise time, more bandwidth can cause inaccuracies. Higher bandwidth amplifiers tend to have more noise than lower bandwidth. So by having more bandwidth, you end up with more vertical noise on your signal's edges. Which makes it more difficult to make measurements.
In a case like this, where I am measuring a very slow signal, I would turn on the 20Mhz bandwidth filter in the channel menu. It'll reduce any high-frequency noise. It'll also let you drop the sample rate down without worry of aliasing high frequency effects. (but depending on your signal's rise time, may distort the signal.)
A tag is an implantable pet microchip transponder. There are 2 types, ASK and FSK. I'm trying to read with the FDX-B 134.2 FSK type chips.
Here's the FFT spectrum with a tag on the coil. BTW. I know the tag is good as I can read it with a commercial reader.
I would also like the thank you for your guidance.
zappullae:
A tag is an implantable pet microchip transponder. There are 2 types, ASK and FSK. I'm trying to read with the FDX-B 134.2 FSK type chips.
Alright, now you're out of my realm. 
I don't know much about how RFID works (yet).
My guess though is that you may not be able to capture the "blip" on the scope (using a constant source). I would imagine you need to "turn on" your carrier for some period of time to charge up the tag and then turn the source off when the tag responds. The response would induce a signal on the coil. Which may or may not be at the same frequency.
I think leaving the signal running constant and trying to see the response, is going to be difficult (if not impossible) on the scope. If for no other reason, the signal coming back is going to be very, very weak compared to your source.
So you might be ready for a new thread. "How do I measure RFID on a scope?" 
LOL. Ok James, now that I know what I'm looking at your suggestion of a new thread is appropriate. Just as FYI regarding micro-tags. What you describe is the HDX version (half duplex) of RFID. The ISO standard for pets is an FDX type (full duplex) where the carrier is constantly on. What happens is the carrier charges the tag's capacitor to power up it's chip. The chip is laser etched to output a bit stream of 0s and 1s representing its unique data which turns its driver on and off. That flows to a small coil wrapped around a ferrite core.
What happens is the driven output of the tag interferes constructively and destructively with the magnetic field of the carrier and modulates it which is picked up by the transceiver (reader that I am trying to construct).
Net net what we have is an air coupled transformer the primary being the carrier coil and the secondary (interfering) being the tag's coil.
