Ahhh, I see what you mean, try clicking the page number instead of the function name, does that work?
All those links will be fixed in the next manual update in March.
The 7510 has different specs for its timestamps when digitizing than the DMM6500/DAQ6510, (search for "timestamp" in the 7510 datasheet to see the lines I'll be mentioning) the timestamp resolution is 1ns for standard buffers so that's why you're seeing that small variation, the actual difference is probably less. The timestamp accuracy is spec'd to "20ns between adjacent readings". What it means is there's 20ns of uncertainty between adjacent readings, so two readings could potentially be 40ns apart, as you're seeing.
The reason for this discrepancy, incidentally, is that the 7510 uses different clocks for timestamps and digitized readings that sync up every so often. In actuality, the digitized readings are probably much closer together than what the timestamps say, it's the timestamps with the uncertainty, not the readings.
Try this script I'm attaching (same deal, change .txt to .tsp and run on the instrument), it's the same one I described in this message. It'll take 100 readings on the 10V DCV range each 1s apart, just to make sure you're not missing anything. Like I said, I saw <100ns difference between timestamps, you should see somewhere around that.
The 7510 has different specs for its timestamps when digitizing than the DMM6500/DAQ6510, (search for "timestamp" in the 7510 datasheet to see the lines I'll be mentioning) the timestamp resolution is 1ns for standard buffers so that's why you're seeing that small variation, the actual difference is probably less. The timestamp accuracy is spec'd to "20ns between adjacent readings". What it means is there's 20ns of uncertainty between adjacent readings, so two readings could potentially be 40ns apart, as you're seeing.Oh yes I don't read the fine print well.
OK +/- 20 ns meet specifications. But 100 ns is already beyond the specification. Plus in DCV modes, the spread is more than 100ns
QuoteThe reason for this discrepancy, incidentally, is that the 7510 uses different clocks for timestamps and digitized readings that sync up every so often. In actuality, the digitized readings are probably much closer together than what the timestamps say, it's the timestamps with the uncertainty, not the readings.Is there any chance that this will be fixed in 7510? After all then all sense of timestamp is lost.
QuoteTry this script I'm attaching (same deal, change .txt to .tsp and run on the instrument), it's the same one I described in this message. It'll take 100 readings on the 10V DCV range each 1s apart, just to make sure you're not missing anything. Like I said, I saw <100ns difference between timestamps, you should see somewhere around that.I ran this script from the device (just fixed BLOCK_MEASURE_DIGITIZE on BLOCK_MEASURE for the second block). And I got a constant error of 17.5 μs on each measurement and the peak to peak spread is the peak of 2500 ns.
Data in the attachment.
Honestly, it's not very likely. There simply aren't enough people that need the kind of timestamp resolution or accuracy you're talking about to justify the change. We changed the way timestamps are handled in the 6500/6510 to improve accuracy and resolution, but the 7510 is unlikely, at this time, to receive changes to how it handles them.
Wait, is this buffer from the 7510 too? BLOCK_MEASURE is depreciated in the DMM6500/DAQ6510 in favor of BLOCK_MEASURE_DIGITIZE. I'm assuming everything in this thread is about the 6500/6510 unless you tell me otherwise and the 7510 behaves differently enough that I need to know which one you're using if you want good answers, also so that I can properly replicate and log issues.
That said, I could replicate your graph with the 7510 and that amount of timestamp drift is surprising to me and the firmware engineers. I've logged an issue to look into this and see what's happening.
From the script I gave you, there's a couple places that could cause the delay offset (which is not present in the 6500) and jitter (which is much less in the 6500) worth looking at.
After spending couple of hours with the reference manual, I was able to kinda implement this missing feature. At the end, as a bonus, through a small hack I was able to upgrade the main display resolution to 8.5 digits! (sorta, see the images)
Nice hanks, but that's 7.5 digits .
Do you want to share your scripts, please? I'm very interested!
Another question, did you get a detailed calibration report, as it should be for such an instrument?
And welcome to the forum.
I was surprised when I first saw the calibration data. .... the multimeter can return such values, but not on the display.
Nice hanks, but that's 7.5 digits .
Yes, a couple of Blue Screens and some Bugs here and there, but it's liveable, though, the biggest design flaw is the FAN !
(Personal opinion )
The digits beyond about 7 digits have no real value. The noise and INL error of the DMM is likely larger than that. From some point it's also just a floating point number scaling a limited resolution value. So there will be some steps no to allow all possible values in between.
There is a little value to the 7 th digit in that one can see drift direction a little earlier and does not get extra rounding or quantization error. So it's OK for the computer to use those extra digit(s), but when writing things down by hand it's usually not worth it.
9.999981650865,Volt DC,...,6.984300,Volt DC,
9.999980233491,Volt DC,...,6.984298,Volt DC,
9.999979931922,Volt DC,...,6.984298,Volt DC,
As a workaround I can change my script to write the second voltage to a separate buffer instead of storing in the extra channel of the same buffer but It'd be waste of space unnecessarily.I can share the script, sure. But before exposing my trick to display 7+ digits I want to make sure that spying( ) Keithley guys won't have this "feature" fixed in the new firmwares
I received a "Traceable calibration certificate" with a certificate no but I don't know where to find the detailed report.
I'm not very sure about how the sense and input terminals are actually digitized internally for the volt ratio, but looking at the graph I can definitely see some concurrent jumps in both channels, which are probably from the DMMs internal noise, and I see jumps only on a single channel, which suggests that coming from the DUT. So with some digital signal processing I can hopefully extract some stats for those 3 devices separately. We'll see.
With large NPLC and filtering values I can get a very stable 7th digit. Although a single ADC output won't have a useful info in the 7th digit, with averaging I think 7th digit is usable for some limited cases.
Hey @analogRF I don’t know if you’ve bought a 6500 yet, but I put together that Probe hold script for you and anyone else (@MikeP). Also see the end for news on firmware.
It uses the App interface of the DMM so it behaves a little differently from a normal script. I put together some info below.
INSTRUCTIONS:
1. Download the attached file and change the .txt ending to .tspa
2. Make sure your DMM’s command set is set to TSP in MENU > Settings
3. Put the script on a USB drive and insert into the DMM
4. Press the APPS key and go to the USB tab
5. You can either run the script here, or save it to local memory first (it will be added to local memory automatically)
6. Click Run
....
This device is the biggest noise maker in the entire house now. I'm tempted to replace that fan with a silent Noctua fan but probably won't touch it while it's newly calibrated.
I will continue to ask about the 7510
Can you open a 7510 thread? These posts about another instrument in they DMM6500 and DAQ6510 thread are confusing.