| Products > Test Equipment |
| Some old school instruments showing how it's done (HP 3325A and Fluke 8506a) |
| << < (43/91) > >> |
| SilverSolder:
--- Quote from: garrettm on February 08, 2021, 06:00:51 am ---Using 1kV range, zero off and internal triggering at the DMM and a 10 second gate time at the counter, I got the following results using the Scanner Advance. S0: 19.5 Hz, 51.3 ms / reading (51.3 ms / sample) S1: 18.0 Hz, 55.6 ms / reading (27.8 ms / sample) S2: 16.5 Hz, 60.6 ms / reading (15.2 ms / sample) S3: 14.0 Hz, 71.4 ms / reading (8.9 ms / sample) S4: 10.9 Hz, 91.7 ms / reading (5.7 ms / sample) ... S10: 0.234 Hz, 4273 ms / reading (4.2 ms / sample) S11: 0.117 Hz, 8547 ms / reading (4.2 ms / sample) If you factor in the number of ADC samples per reading, you can see that we converge on an average of about 4.2 ms per sample from the ADC. From what SilverSolder has said, the meter takes 4 samples per mains cycle when in synchronous mode. That implies 4.17 ms per sample with a 60 Hz AC mains and correlates with my rough measurements. So Fluke isn't completely full of BS. However, the meter appears to add a variable delay between groups of sequential readings used for the average. The question is, how, or even if, we can minimize this internal delay. I assume the Controller averages the raw sequential ADC readings and then applies the range scaling, calibration corrections and possible math functions afterward. I doubt this process makes up for the observed delay. Using 4.16... ms as the digitizing time required for each individual sample and multiplying this by the number of sequential samples for each mode, we obtain the total digitizing time. Subtracting this from the previous reading period, we obtain the following delays. S0: 47.13 ms (51.3 - 4.16...*2^0) S1: 47.27 ms (55.6 - 4.16...*2^1) S2: 43.93 ms (60.6 - 4.16...*2^2) S3: 38.07 ms (71.4 - 4.16...*2^3) S4: 25.03 ms (91.7 - 4.16...*2^4) ... S10: 6.33 ms (4273 - 4.16...*2^10) S11: 13.67 ms (8547 - 4.16...*2^11) --- End quote --- The issue might be that the internal auto-trigger works at a leisurely pace, that cannot be increased? If we use binary mode via GPIB, we would have to send a '?' to trigger every ADC reading individually. Another option might be to trigger using the BNC input on the back, using a square wave generator, and see if the speed can be increased that way? |
| garrettm:
I ran the numbers again using period measurements on the frequency counter with averaging turned on. The data looks a little less noisy than before. The variable delay is interesting. The numbers indicate sequential sampling is perfomed by the ADC. The single sample digitizing period matches what Fluke has promised. As SilverSolder has suggested, we may need to send manual triggers over the bus to get higher acquisition speed. --- Code: ---Sampling Reading AVG Digitizing AVG Processing Digitizing Exponent Period Time / Sample Delay Period 0 52.2 52.20 48.03 4.17 1 55.2 27.60 46.87 8.33 2 60.3 15.08 43.63 16.67 3 68.8 8.60 35.47 33.33 4 89.4 5.59 22.73 66.67 5 137.5 4.30 4.17 133.3 6 270.9 4.23 4.23 266.7 7 537.7 4.20 4.37 533.3 8 1071 4.18 4.33 1067 9 2140 4.18 6.67 2133 10 4273 4.17 6.33 4267 11 8540 4.17 6.67 8533 --- End code --- I played with the external trigger input and couldn't get the meter to trigger faster than when in free-run via the internal triggering. Max 17 Hz externally, and about 19-20 Hz internally. I did notice that I could use a larger trigger frequency (30 Hz) when I use S1 sampling or higher. Interestingly, the scan advance was then half the frequency of the external trigger signal. Although, I didn't mess with this much further. *Formating tables on this forum is like herding cats! |
| dietert1:
After some fiddling with setup strings i just got 100 separate readings from each of our Fluke 8502s within 859 msec, so that is about 8 msec per reading. This is with a GPIB over USB setup, with high speed reading mode "!" and sending a separate trigger "?" for each reading. In this mode the instruments do not follow the samples per reading command characters "Sn". And i don't yet understand the meaning of "T" or "T1" continuous reading modes. Expected a continuous stream of samples without repeating trigger commands. But without, the process gets stuck with a GPIB query timeout when trying to read the second sample. The readings look reasonable with about +/- 1 ppm noise, so averaging them should yield averages without "sticky levels". Have to check that yet. Regards, Dieter |
| joeqsmith:
--- Quote from: dietert1 on February 08, 2021, 10:05:54 am ---After some fiddling with setup strings i just got 100 separate readings from each of our Fluke 8502s within 859 msec, so that is about 8 msec per reading. This is with a GPIB over USB setup, with high speed reading mode "!" and sending a separate trigger "?" for each reading. In this mode the instruments do not follow the samples per reading command characters "Sn". And i don't yet understand the meaning of "T" or "T1" continuous reading modes. Expected a continuous stream of samples without repeating trigger commands. But without, the process gets stuck with a GPIB query timeout when trying to read the second sample. The readings look reasonable with about +/- 1 ppm noise, so averaging them should yield averages without "sticky levels". Have to check that yet. Regards, Dieter --- End quote --- I would like to see the commands you are sending. Maybe I was doing something wrong when trying to get the serial port to work in high speed mode. |
| joeqsmith:
--- Quote from: SilverSolder on February 08, 2021, 06:09:34 am --- --- Quote from: joeqsmith on February 07, 2021, 10:55:04 pm ---[...] So I looked at the schematic and I notice U24 routes A13. Then we see U23 ties pin 26 high. Looking at my original manual, it is also routed like this. They must have planned on adding some features to U24 at one point and decided to support the 27128. [...] --- End quote --- The disassembler found three jumps outside the confines of the 16K available: Ignoring branch outside ROM to 40D8 at address 25A2 Ignoring branch outside ROM to 40E9 at address 25B9 Ignoring branch outside ROM to 40CB at address 2555 So perhaps there are some special versions of this meter that have extra functionality? - slowly, light is beginning to dawn on the disassembly effort... thanks to help from @retiredfeline in a separate thread on 8080 assembly coding. [Edit] Another thing: The code appears to start in U24 (at address 0000 in that EPROM), and continues into U23. A 'gotcha'! :D --- End quote --- They have 2K of RAM. I wonder are they jumping there? The RAM may have been faster so they may have copied critical routines from ROM to RAM. Just a guess. |
| Navigation |
| Message Index |
| Next page |
| Previous page |