Products > Test Equipment

Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)

<< < (83/91) > >>

SilverSolder:

@Dietert, that is amazing.  I haven't got to first base with the high speed measurements yet - time to get something going!

One thing I've been thinking about, regarding the ADC:  Maybe we can run it one more time?  -  currently, it runs 5 times and gets to 21 bits resolution.  What about modding the software in the controller to run it "deeper" and get more bits - e.g. "real" 7.5 or more resolution?  This might require lowering noise elsewhere in the system, but...  it would be a pretty cool mod!




dietert1:
That's a nice proposal, shouldn't be to difficult. Yet the 8080A cannot efficiently add two 32 bit quantities. Maybe the extra bits could be joined in on the GPIB host. Or fit in an Arm MCU that supports in-circuit development and debugging like we use nowadays.

My own like to have is automated ADC calibration. Apparently ADC fine tuning with those low-ohms series trimmers isn't very stable. Guess it suffers from contact resistance in the trimmers. Don't know yet how to solve that. There should be a module to generate the test voltages like 10.1 V, -10.1 V, 0.5 V, 5.1 V ... with a multiplexer. And something that replaces the trimmers and that can be tuned by implementing one of the unused commands in the firmware. Most part of automation would be on the GPIB host. Ideally one could perform ADC calibration at normal operation temperature - with all covers closed.

By the way, that fast mode test ran for 8.22 hours until now with an average speed of 333.35 samples per second. Much more stable now since i modified GPIB operations. Seems the 8502A doesn't like premature UNTALK without having sent its data yet.

Regards, Dieter

SilverSolder:

--- Quote from: dietert1 on March 11, 2021, 07:38:23 am ---That's a nice proposal, shouldn't be to difficult. Yet the 8080A cannot efficiently add two 32 bit quantities. Maybe the extra bits could be joined in on the GPIB host. Or fit in an Arm MCU that supports in-circuit development and debugging like we use nowadays.

My own like to have is automated ADC calibration. Apparently ADC fine tuning with those low-ohms series trimmers isn't very stable. Guess it suffers from contact resistance in the trimmers. Don't know yet how to solve that. There should be a module to generate the test voltages like 10.1 V, -10.1 V, 0.5 V, 5.1 V ... with a multiplexer. And something that replaces the trimmers and that can be tuned by implementing one of the unused commands in the firmware. Most part of automation would be on the GPIB host. Ideally one could perform ADC calibration at normal operation temperature - with all covers closed.

By the way, that fast mode test ran for 8.22 hours until now with an average speed of 333.35 samples per second. Much more stable now since i modified GPIB operations. Seems the 8502A doesn't like premature UNTALK without having sent its data yet.

Regards, Dieter

--- End quote ---

If we have all the individual ADC readings, maybe it is possible to make up for the flawed ADC trim after the fact?  - so the problem would be reduced to feeding the meter a sequence of known voltages before running a critical test, and then compensate all the following readings accordingly?  That way we could also remove errors introduced by the active filter, input modules, attenuators, etc.

Taking advantage of the modular design by replacing the whole controller board with a modern MCU would of course also be fun, but now we are REALLY taking it to an extreme!

The A/D module could possibly be replaced by one based on the 8.5 digit A/D discussed elsewhere on the EEVblog.  Would that be cool, or what?  Like putting a supercharged V-12 into a Ford Anglia!  :D

m k:

--- Quote from: dietert1 on March 11, 2021, 07:38:23 am ---Yet the 8080A cannot efficiently add two 32 bit quantities.
--- End quote ---

Don't know its efficiency but pretty simple it is.


--- Code: ---      lxi  sp, 4010h
      lxi  h, 7aaah  ; 7aaacccc + 99998888
      push h
      lxi  h, cccch
      push h
      lxi  h, 9999h
      push h
      lxi  h, 8888h
      push h
      lxi  h, 0
      pop  b         ; start
      pop  d
      xthl
      dad  b
      xthl
      inx  sp
      inx  sp
      xthl
      jnc  over
      inx  h
over: dad  d
      xthl
      dcx  sp
      dcx  sp        ; end
      pop b
      pop d
      hlt

--- End code ---

dietert1:
There are 7 byte registers in the 8080A. The ADC code in the 8502A disassembly is register based and operates on two 24 bit quantities. They use A for shifting in ADC bits and H to address the backplane, so it's really very tight. Guess that was the reason why they left it like it was in the 8505/6A.
And when you look at the ADC code, they first collect 12 bits of data with control codes 0C and 00, then another 18 Bits with control codes 08, 00 and 00. So it isn't about making a loop six rounds instead of five.

Meanwhile i have a data logging run of 16 hours with a total of about 20 million samples, so that seems to work now. With 30 second logging interval i have 10 000 samples to average and the stdev of those averages gets down to 0.03 ppm. Of course systematic errors add in on top of statistics, like misaligned ADC.

Regards, Dieter

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod