Author Topic: 3458A Worklog  (Read 12355 times)

0 Members and 1 Guest are viewing this topic.

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog
« on: January 07, 2019, 01:41:27 am »
This unit is equipped with option 002 and was received with "RAM TEST 1 LOW" error.
It was first powered up on Nov 24th, on Dec 1st it was taken apart for further inspection and cleaning.
Besides a bit of dust on fan & filter it looked as it came straight out of factory.
The datecodes on the ics reveales a manufacturing date from late '89 to early '90.
Remarkable that the calram still seems to be in good condition and maintaining caldata after nearly 30 years.
Obviously it is high time for replacement of the 3 Dallas NVSRAMs - to save the calram a Linux-Tool for GPIB was used.

Next thing to check was heart of instrument: condition of adc (A3-board)
Manual data for cal 72 & 175 was captured between Nov 26th and Dec 9th, since then the acal dc data was captured by script every 5min.
The first two weeks were not promising: the SN18A check revealed drift of > 0.43ppm/day.
It appeared to become a member of A3-sickness club, but fortunately the drift went down to sub 0.01ppm/day for last week  :-+
The adc shows a TC of ~0.33ppm, that is below the stated 0.4ppm in HP Journal p. 13.
This seems to be in spec and shows why it is a good idea to do regular acal for precision measurements even in the 10V range - if the lab temperature is not rock stable (which home lab is?).
In conclusion the adc seems to be in reasonable condition after a month of settling and ~8ppm total drift.

In the meantime nvsram, caps and mains filter were ordered.
Late on Dec 27th it went down for replacement of nvsrams and update to latest FW.
This took a bit longer than estimated - as it revealed that uv light for e.g. developing pcbs (UVB) is not good for erasing eproms (UVC)  :palm:, but after 24h exposure all bits where cleared and newest FW version 9.2 could be programmed successfully.
After this the device turned on and showed a convergence error once, after reset everything was fine and on several power cycles no error came up anymore.

Things to do:
-ordering special caps (radial 8200µF & big 15mF) and fan
-replacement of electrolytics, mains filter & fan
-investigate input leakage, noise, stability, TC etc.

probably: reduce LTZ1000 temperature set point with parallel 100k to reduce drift even more

EDIT 2019-05-21 (moved table from second to first post):

Overview of replaced parts:

A4 - inguard power supply
part #descriptionpitch [mm]manufacturerreplacementmanufacturer
C07, C082,200µF 35V 85°C 18x35mm SMC7.5Nippon Chemi-Con2,200µF 35V 105°C 16x25mm FR Type APanasonic
C0915,000µF 16V 85°C 35x26mm SME10Nippon Chemi-Con18,000µF 16V 105°C 30x30mm LGUNichicon
C1722µF 50V 85°C 10x11mm 513D3,5Sprague22µF 50V 105°C 5x11mm FR Type APanasonic

A5 - outguard controller
part #descriptionpitch [mm]manufacturerreplacementmanufacturer
U121, U122DS1235YW-150 NVSRAM28PDallasDS1230Y-120+ on precision socketMaxim
U132DS1220Y-150 NVSRAM24PDallasDS1220AD-150+ on precision socketMaxim


A6 - outguard power supply
part #descriptionpitch [mm]manufacturerreplacementmanufacturer
C1, C11680uF 50V 85°C 16x22mm SXE7.5Nippon Chemi-Con680µF 63V 105°C 16x25mm LXZ (max 25mm - height limited by case)Europe Chemi-Con
C88,300µF 35V 85°C 25x67mm 53D70Sprague10,000µF 35V 85°C 25x61mm TVXNichicon
C200, C20147µF 63V 85°C 8x15mm SME3,5Nippon Chemi-Con47µF 63V 105°C 8x11,5mm EB Type APanasonic
C202330µF 25V 85°C 10x16mm SME5Nippon Chemi-Con330µF 25V 105°C 8x11,5mm FR Type APanasonic
C203220µF 16V 85°C 8x15mm SME3,5Nippon Chemi-Con220µF 35V 105°C 8x11,5mm FR Type APanasonic
C15, C162.2nF 250V~ Y2 40/085/56 3,5x13x7mm PME 27110RIFA2.2nF 300V~ Y2 55/105/56 4x13x9,5mm MKPWIMA

Case
part #descriptionpitch [mm]manufacturerreplacementmanufacturer
Fan60x60x25mm 12V 0.7W powered with 15VPapst60x60x25mm 24V 2.88W 109R0624D4011 (12-27.6V)Sanyo Denki
Mains Filter3A 47nF 2x750µH FN 32340Schaffner6A 47nF 2x800µH KFSSchurter
« Last Edit: May 21, 2019, 12:37:08 pm by MiDi »
 
The following users thanked this post: Rax, Inverted18650

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: Part 2 - Caps
« Reply #1 on: January 07, 2019, 01:41:57 am »
On January, 25th the unit went down for another refurbishment.
It was planned to replace the caps, mains filter and fan, but only caps were replaced for now - explanation below.
There is an overview awailable at bottom with all original and replacement parts that were used - it can be easy copied to favorite spreadsheet program.

Replacing all electrolytic capacitors was straight forward and there were no surprises.
A thick copper wire was used to desolder both pins of the caps at the same time - desolder guns are overrated.
The old caps were quite in good condition as a quick check with LCR-tester revealed.
Just a bit more ESR and loss than replacements - would be nothing to worry about for now, but worth replacement for a couple of bucks for good sleep next years.
A4 C09 & A6 C8 were replaced with next higher value available for best fit - as these caps have wide tolerance, a bit more capacitance would not do any harm.
The hidden yellow C17 on A4 was missed, but will be replaced next time.
The visual check on A6 catched attention on the two 2.2nF Y caps C15, C16 near mains fuse, they look cracked like spider app.
They were dropped for now and are replaced next time - there are already Y caps in mains filter, so this should not be an issue.





Mains filter from Schaffner has no good reputation due to several fails, so better to replace it.
It was decided to do it with remaining things next time, as it would be good idea to drill the rivets with closed case from outside to keep the chips out.
Afterwards the case has to be opened again for replacement and all remaining work will be done in one step next time.

The fan introduced quite some vibrations and has this annoying metal sound similar to old noisy hard drives.
It is supplied with unusual 15V and it was intended to be replaced with 24V type that is rated down to 12V.
When comparing both fans it seems that the chosen one would be reasonable with similar current draw and airflow.
As it turned out there is no standard for the pitch (corrected: the pitch is same) and size for mounting holes of "standard" fans and the screws did hold the replacement fan only slightly.
It is a bit quieter and introduces no significant vibration, but a slightly mounted fan seems no good idea.  :--
For now there came no option to mind how to solve this, but it was not intended to put the old fan back without any improvement.
There was fitted a bend copper wire into the slots for balancing and after some fiddling the best position and weight was found to minimize introduced vibration.
Maybe it will be replaced in future...



Another odd thing is a bend top cap for LTZ1000.
Not shure if this is critical and should be fixed, any recommendation?



ADC-Drift test is going on and gave unpleasant surprises, although it is still in spec.



EDIT 2019-05-21: Moved Replacement table to first post.
« Last Edit: December 03, 2021, 10:47:49 pm by MiDi »
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: Part 3 - Mains Filter & Fan
« Reply #2 on: January 07, 2019, 01:42:28 am »
Time for the last episode: Mains Filter & Fan

The unit went down on April 27th for the remaining replacements (list of parts updated & finalized).

Drilling the rivets of the mains filter was a bit harder than thought - my HP3457A did not struggle that much.
After lots of chips and a bit of brute force it was released from its former job and replaced with new Schurter type.
The new one is a bit longer, but no problem to fit it in its place.



The RIFA MP Y-Caps on board were removed last time and now refitted with WIMA MKP (see attached picture).
Interestingly the time did not improve on size of this types (compared to electrolytic ones), the new ones are thicker and higher - this gives confidence, that they will last long after me.





For the problem with the new fan and its bigger screw holes a simple solution has been elaborated.
Fill them with epoxy (e.g. J-B Weld) and after curing drill them to size of holes from original fan.
(the spacings are identical, corrected statement in former post - I obviously squinted as the picture already showed this)
Although J-B Weld ist tought to be the strongest epoxy, it did not stick enough on cleaned, but unprepared holes when screwing it  ::)
After filing the inside of the holes to roughen them a bit, the procedure was repeated with success.
The new fan is not significantly quieter, but the annoying metal scratching sound has gone now.



I decided to fix the bend cap - just to be safe - but it defended to go into its intended form.
Heating multiple times to finally ~200°C and bending it with quite some force to its desired shape, it bended back again after cooling down  :box:
Sanding with 600 grid finally it gave up and went flat (picture of assembly of both caps and ref-board attached).

Before:


After:


Last thing was to replace overlooked 22uF yellow cap - just a mere formality (see attached picture).

Hopefully all the sweat comes to a happy end and unit is now in good condition.
The ADC drift actually settled to ~0.035 ppm/day for 3 weeks now, before it stayed at ~0.05ppm/day for two months.
The "noise" generated by acal dc is around 0.1ppm-pp according to cal 72, from this point an acal on my unit would be sufficient every 3 days.
With ~0.33ppm TC of ADC this becomes the mayor drive to perform an acal - at least for every °C change (see attached picture of last 3 weeks).

My unit seems to stop drifting during power down, but soon there will be more data to confirm this.
The measured stability before and after final work against external LTZ1000 showed drift in sub-ppm region - fortunately no unpleasant surprises :-+.
Combined noise/drift (+TC) from unit and external reference are ~0,13 ppm stddev and ~0,5ppm-pp (3 days, 1°C span, 100NPLCs, 7V, acal every hour)
Combined TC maybe ~-0,3ppm/°C, but the external ref is not characterized nor trimmed for TC.
This data is just for reference, this has to be repeated with better setup.



There are a couple of things left for full characterization and to be shure it is in good condition:
-log input noise for the ranges and NPLCs
-check input bias current at different voltages and ranges
-measure TC of whole unit
-calibration
-long term drift


Big thanks goes to the 3458A nuts - especially to TiN and his great articles - with the help of this superb documentation the work was nearly straight forward.
« Last Edit: December 03, 2021, 11:02:56 pm by MiDi »
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: 3458A Worklog
« Reply #3 on: January 07, 2019, 04:31:02 am »
Welcome to the club.  :-+
Now you need SR104, 732A/B/C and second 3458A.... rabbit hole only starts here...  :popcorn:

Quote
The first two weeks were not promising: the SN18A check revealed drift of > 0.43ppm/day.
It appeared to become a member of A3-sickness club, but fortunately the drift went down to sub 0.01ppm/day for last week  :-+
I would hold the breathe, as sometimes bad A3's give you little tease, before they go back driftin. Don't ask me how I know...
SN18A testing should be done weeks after long offline storage anyway, so you are sure data is valid, and not just initial settling of the unit (which often takes few weeks of 24/7 operation).

Quote
The adc shows a TC of ~0.33ppm, that is below the stated 0.4ppm in HP Journal p. 13.
Pretty horrid, if that TC is actually of the unit, and not the measurement setup. I'd say good happy 3458A should be <0.1ppm TC on main 10V range (no ACAL of course).
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 
The following users thanked this post: MiDi

Offline Dr. Frank

  • Super Contributor
  • ***
  • Posts: 2384
  • Country: de
Re: 3458A Worklog
« Reply #4 on: January 07, 2019, 07:40:45 am »


Quote
The adc shows a TC of ~0.33ppm, that is below the stated 0.4ppm in HP Journal p. 13.
Pretty horrid, if that TC is actually of the unit, and not the measurement setup. I'd say good happy 3458A should be <0.1ppm TC on main 10V range (no ACAL of course).

Hello TiN,

how do you measure that on your 3458As?

Per specification, about 0.5ppm/°C is the T.C.  w/o ACAL, that is mostly the R-ladder matching T.C. of U180, and 0.15ppm/°C is with ACAL, i.e. latter is mostly the LTZ1000As T.C.

I've determined about 0.23ppm/°C for CAL? 72 (i.e. purely U180).
Did an ACAL directly after power-up, in cold state, that extrapolation fits nicely with statistical data.
Combined T.C. of my box is about 0.4ppm/°C.

I think, MiDis 3458A is fine as well.

Frank

« Last Edit: January 07, 2019, 07:54:46 am by Dr. Frank »
 
The following users thanked this post: e61_phil, MiDi, notfaded1

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: 3458A Worklog
« Reply #5 on: January 07, 2019, 03:26:50 pm »
Quote
Hello TiN,

how do you measure that on your 3458As?

Well, I remember we discussed this before at EEVBlog. Perhaps it's time we create separate thread "DMM temperature stability comparison project", not to pollute this fine thread?

I was interested in total tempco of the DMM (that is from terminals to the output data, end-to-end, rather than specific 3458A's component contributor) so I did not use CAL? 72 data to evaluate tempco but rather variated ambient temperature (aircon on, about +18-20c, aircon off about +30c ambient), while keeping stable aged LTZ1000 reference in isothermal chamber (+/-0.01c at all times). Resulting data (don't recall graph links right now, but they are somewhere public) show me that both of my 3458A's had no visible tempco (below 0.1ppm that is, down it the noise). After that test I stopped doing silly ACAL DCV every 1C of TEMP? change. I did repeat same test few more times, with equal result.

I'm willing to test this again once new A3 board for my 3458C arrives, so we can use more meters in the mix (and I still have 8508 to test too).
In fact I have somewhat indicative plot, just quick check of K2002 warmup stability from 1 week cold state. But temperature changed too, so you can also see invisible tempco of my reference 3458 units (STD and B box, green lines).

So that's why I say good 3458 should be 0.1 ppm/K or better, even though official spec (old and not updated) is 0.5ppm/K.
My standalone HP 3458A A9 (old STD version) reference also have tempco <0.02ppm/K over 24-50c range, so A9 contribution to tempco can be much much smaller.
During my own modules testing/assembly all LTZ references that fall outside of <0.05 ppm/K box at 18c-50c I consider as fail  ::).
« Last Edit: January 07, 2019, 03:30:52 pm by TiN »
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 
The following users thanked this post: MiDi

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
Re: 3458A Worklog
« Reply #6 on: January 07, 2019, 04:51:52 pm »
Well, I remember we discussed this before at EEVBlog. Perhaps it's time we create separate thread "DMM temperature stability comparison project", not to pollute this fine thread?
As there are placeholders and I appreciate all your input and feedback, it would be no problem for me to "pollute" this thread - far from it!

These valuable information backed my feeling, that this unit might be on the high side for adc tc.
Perhaps the newer adcs have improved tc/stability?
Collecting autocal data will go on for several weeks - lets see, how stability evolves.
For now I have a bit of confidence, as it shows a quite smooth settling curve.
 

Offline Dr. Frank

  • Super Contributor
  • ***
  • Posts: 2384
  • Country: de
Re: 3458A Worklog
« Reply #7 on: January 07, 2019, 05:19:59 pm »
Maybe we should really open another thread about the different T.C. specifications and HW versions of the 3458A.

I was not aware, that TiNs 3 DMMs all should have such low T.C.s, and we did not discuss that in detail, either, if I recall that correctly.
But I also can hardly believe that, for some reasons.

The LTZ1000 references inside the 3458A have never been trimmed for lowest T.C. by hp, as far as I can tell, even up today, in the 'new' version of the 34470A.
I really doubt that hp has ever selected these references for zero T.C., either.

Then, the T.C. of U180 is the sum of about 6..8 different resistors, and even if these all are sitting on the same hybrid / chip, I really doubt that such ultra low T.C.s are really systematically possible.I really doubt, that  KS has really redesigned U180 after 2000. Probably they just live from a last time build of this hybrid...as they live from bodges and All Time Buy from other terminated components..

I also really doubt that they ever had budget, resources and brains to make any fundamental redesign / improvement on the 3458A in the last 20 years, apart from these slight compatible changes due to terminated components, basically A5 only.

The only obvious component change regarding T.C. was the 40k reference resistor, which had been changed from the old Vishay technologies with about 1..2 ppm/K typ., non -oil filled to the VHP101, about 0.2 ppm/K, oil filled type, somewhere around 1995.

In the end, I think that the old specifiaction from 1988, which is still valid, applies to the old instruments, before 1996 at least, but obviously also to my instrument from about 2000, apart from OHM TC and stability, maybe.

So to say, that T.C. > 0.1ppm/K is nOK, is to my opinion not correct.

Maybe TiN really has unbelievable luck in getting 3 A3 ADCs with exceptional low T.C., multiplied by the unbelievably low T.C. of his 3458As  LTZ references, or agilent really has changed U180 to better technology in the last years, or maybe we should really define a reliable method of determination of the different T.C. parameters of the 3458A.

MiDi, your instrument really seems to be be ok, and fine.. don't expect too low a T.C., even the more stable 8508A has 0.3ppm/K as best T.C. only, and that really sounds much more realistic.

Frank
« Last Edit: January 07, 2019, 05:38:27 pm by Dr. Frank »
 
The following users thanked this post: AG7CK

Offline sokoloff

  • Super Contributor
  • ***
  • Posts: 1799
  • Country: us
Re: 3458A Worklog
« Reply #8 on: January 07, 2019, 05:56:36 pm »
Maybe we should really open another thread about the different T.C. specifications and HW versions of the 3458A.
I think there's value in that; I also think there's value in a basic "so you bought a good bench meter and want to know where it stands; here's the first 5 things to do and why..." with sub-threads of "here's how to do that on model XYZ".
 
The following users thanked this post: MiDi

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: 3458A Worklog
« Reply #9 on: January 07, 2019, 06:02:18 pm »
Okay, let's discuss here.
I think it will benefit us all to get down this rabbit hole.

Perhaps I got bit rude, using horrid word for 0.3ppm/K TC. It's just my level of acceptance on 3458A is high after all that effort put into units. Official spec on 3458A 10V range is 0.5ppm/K without help of ACAL
« Last Edit: January 07, 2019, 06:39:43 pm by TiN »
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 
The following users thanked this post: MiDi

Offline AG7CK

  • Regular Contributor
  • *
  • Posts: 131
  • Country: th
Re: 3458A Worklog
« Reply #10 on: January 08, 2019, 03:55:54 am »
...
 the drift went down to sub 0.01ppm/day for last week
...

If I am not mistaken, this means that all digits on the meter are steady. For instance readings varying between [9.999 999 9] and [10.000 000 1] flickers +-0.01ppm.

I have never seen a 8.5 digit meter showing 7 or 10 volt DC without flickering in the last (at least 1 or 2) digits in any video from any member here or elsewhere. It would be interesting if you could explain and show how you do your "sub 0.01 ppm" measurements.
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: 3458A Worklog
« Reply #11 on: January 08, 2019, 04:01:04 am »
0.01 ppm/day is not meter measurement, but the meter ADC gain stability. It does not include measurement noise.

Sent from my Lenovo K900_ROW using Tapatalk

YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 
The following users thanked this post: engiadina, Inverted18650

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
Re: 3458A Worklog
« Reply #12 on: January 26, 2019, 05:21:09 pm »
Short update: managed replacement of elkos on friday, details coming soon.

For now, only two things I stumbled over:

The two Y mains caps C15, C16 next to mains fuse look weird and I decided to drop them for now until replacement arrives.
There are Y caps inside mains filter, so this should not be an issue.






The second thing is a bend cap for LTZ1000, not shure if the gap is an issue  :-//

« Last Edit: January 26, 2019, 05:23:21 pm by MiDi »
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: Part 2
« Reply #13 on: February 11, 2019, 11:26:26 pm »
Took a bit longer than estimated, but now here is part 2.
 
The following users thanked this post: Andreas

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Re: 3458A Worklog
« Reply #14 on: February 12, 2019, 12:36:07 am »
Nice :)
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog - back from Maker Faire
« Reply #16 on: August 18, 2019, 10:11:36 pm »
An update of ADC-Drift after 16 days downtime and returning from PTB@Maker Faire.
Take yourself a picture of drift when powered off for some time...
The trip to the Maker Faire seems not to have affected ADC, was a bit afraid about it.
Comparing against my LTZ1k it showed drift ~-1ppm after returning.

« Last Edit: August 18, 2019, 11:02:20 pm by MiDi »
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: AC error fixed
« Reply #17 on: August 13, 2021, 06:44:34 pm »
Couple of weeks ago unit got faulty with error "204, HARDWARE FAILURE -- AC VOS DAC CONVERGENCE: 181" and interesting readings on AC with shorted input:





First hit was - how could it be something else :-DD - xDevs describing that this error direct us to assembly A2 (AC Converter 03458-66502) with U404 Elantec EL2039 600MHz op-amp showing huge voltage between input + & -.
And yepp, this is the described fault in this unit too - this saved me much time to investigate the error: big thanks go out to TEKTRON (this time not Illya)!

Elantec EL2039 is long time obsolete and no drop in replacement is awailable, luckily there are couple offers awailable on the usual selling platforms.
I ordered two pcs. from two different sellers from china and hoping not to get fakes  :scared:
Luckily one seller sold original parts with convenient date code for my unit - as different packages and finally acetone test revealed, the other two are fakes.
Top left is faulty specimen, bottom left replacement spare (other measured fine and already soldered in), right are fakes and went straight into the bin:



Unit is now working without error again - but have no AC calibrator at hand to verify specs, but AC auto-cal should do that to a degree.
Attached are top & bottom pics of A2 assembly, there seem to be quite some differences to later revisions.

« Last Edit: August 13, 2021, 07:14:31 pm by MiDi »
 
The following users thanked this post: TiN, wolfy007, syau

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: Thermal Images
« Reply #18 on: August 13, 2021, 11:37:04 pm »
Attached 22 ziped thermal images taken with UTi260B - the raw images can be extracted/converted with UNI-T-Thermal-Utilities.
Overview top & bottom:





« Last Edit: August 13, 2021, 11:45:14 pm by MiDi »
 
The following users thanked this post: wolfy007

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A Worklog: Drift & Ratio stability
« Reply #19 on: June 05, 2022, 11:27:16 pm »
Wanted to know how good is ratio mode, so I tested it for more than half a year (same 7V LTZ1000 on both inputs):



Edit: The formula used for the ratio plot (blue): value = ( [current ratio] - median(all ratios) ) * 1E6

In addition the 3 1/2 year ADC drift attached.

« Last Edit: June 06, 2022, 10:10:35 am by MiDi »
 
The following users thanked this post: TiN, Andreas

Offline Andreas

  • Super Contributor
  • ***
  • Posts: 3248
  • Country: de
Re: 3458A Worklog
« Reply #20 on: June 06, 2022, 05:21:08 am »
Helllo,

one question:
Ratio LTZ#2 against what? Against itself?
Is LTZ#2 a 7V or a 10V reference?

with best regards

Andreas
 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
Re: 3458A Worklog
« Reply #21 on: June 06, 2022, 10:03:13 am »
Ratio was performed with same 7V LTZ1000 on both inputs, added that info to initial post.
 

Offline martinr33

  • Frequent Contributor
  • **
  • Posts: 363
  • Country: us
Re: 3458A Worklog
« Reply #22 on: June 07, 2022, 06:13:48 am »
There are a few decoupling caps to add to the early version of the ADC. Some small tantalum electrolytics, and some ceramic decouplers. My apologies for not having pictures to hand, but I figured you would like to know.

 

Offline MiDiTopic starter

  • Frequent Contributor
  • **
  • Posts: 600
  • Country: ua
3458A fast reading
« Reply #23 on: October 09, 2023, 11:18:24 pm »
For characterizing ULF-noise of an ULF-ULNA there was the need to get fast measurements over a day with minimum difference between aperture time and time between samples to minimize the error (see why).

As it seems there is no way to read the FIFO continuous while measurements are taken I came up with this python code to test the throughput (Github-Repository):

Code: [Select]
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# developed & tested with Python 3.9

from time import perf_counter_ns, sleep
import atexit
from Gpib import *
from statistics import mean, median, stdev

gpib_address = 22

def setup(addr):
    inst = Gpib(0, addr)
    inst.timeout(gpib.T10s)
    inst.clear()

    inst.write("TARM HOLD")             # stop measurements
    inst.write("PRESET FAST")           # preset to fast mode, see p. 156 for high-speed mode
    inst.write("END ALWAYS")            # EOI line set true when the last byte of each reading sent (read needs end of data info)

    #inst.write("DISP OFF")              # set by PRESET FAST
    #inst.write("MATH OFF")              # set by PRESET FAST
    #inst.write("MEM OFF")               # set by PRESET FAST
    #inst.write("AZERO OFF")             # set by PRESET FAST
    #inst.write("NRDGS 1,AUTO")          # set by PRESET FAST
    #inst.write("TRIG AUTO")             # set by PRESET FAST (triggers whenever the multimeter is not busy)
    inst.write("MFORMAT SINT") # DINT set by PRESET FAST
    inst.write("OFORMAT SINT") # DINT set by PRESET FAST
    inst.write("DEFEAT ON")             # !!! input protection reduced (only +-100V up to 10V range allowed, +-1100V on 100V/1000V range) !!! see p. 157
    inst.write("LOCK ON") # local lock - does nothing for speed, but prevents interruptions by use of frontpanel
    inst.write("APER 1.4E-6") # fastest see manual p. 160
    #inst.write("NPLC 1")                # for testing throughput with NPLCs
    #inst.write("DCV 1")                 # DCV 10 set by PRESET FAST
    inst.write("ARANGE OFF")            # needed according to p. 156 for high-speed mode, really needed if set to a range?
    inst.write("DELAY 0") # sets the delay to its minimum possible value (100 ns) - see p. 159

    return inst

def run_measurement(inst, runs=10000):
    data = []

    for _1 in range(3):                            # warmup
        value = inst.read()

    start = perf_counter_ns()
    for i in range(runs):
        value = inst.read()
        time_ns = perf_counter_ns()
        data.append([time_ns, value])
    stop = perf_counter_ns()

    return data, start, stop

def exit_handler(inst):
    inst.clear()             # needed to exit fast mode
    inst.write("DISP ON")             # enable diplay
    inst.write("DISP MSG,\"                 \"")    # better as DISP OFF to save display life
    inst.write("LOCK OFF")             # local lock disable
    print('Exited gracefully')

def main():
    global gpib_address
    ns_to_ms = 1_000_000
   
    dmm = setup(gpib_address)
    atexit.register(exit_handler, dmm)
   
    print (f"Starting throughput test with DMM address {gpib_address}, this will take some time ...")
   
    dmm.write("ISCALE?")
    scale = float(dmm.read().strip().decode("ascii"))

    dmm.write("TARM AUTO")                          # start measurements (always armed) - see p. 159

    sleep(1)                                        # give the DMM some time to process settings
   
    count = 10_000
    data, start, stop = run_measurement(dmm, count)
   
    delta_times = []
   
    for n, datum in enumerate(data):
        delta_time = datum[0]-data[n-1][0] if n > 0 else datum[0]-start # first delta_time is special
        print (f"{n:6.0f}: {datum[0]} > {int.from_bytes(datum[1], byteorder='big', signed=True) * scale:3.6f}V dt: {delta_time/ns_to_ms:.3f}ms")
        delta_times.append(delta_time)
       
    print(f"Scale: {scale}")
    print(  f"mean: {mean(delta_times)/ns_to_ms:.3f}ms"
            f"\nmedian: {median(delta_times)/ns_to_ms:.3f}ms"
            f"\nstdev: {stdev(delta_times)/ns_to_ms:.3f}ms"
            f"\nmin: {min(delta_times)/ns_to_ms:.3f}ms @{min(range(len(delta_times)), key=delta_times.__getitem__)}"
            f"\nmax: {max(delta_times)/ns_to_ms:.3f}ms @{max(range(len(delta_times)), key=delta_times.__getitem__)}"
            )
    print(  f"runtime: {(stop-start)/ns_to_ms:.3f}ms"
            f"\ntime per sample: {(stop-start)/ns_to_ms/count:.3f}ms/spl")

if __name__ == "__main__":
    main()

Throughput test results with Agilent 82357B GPIB adapter on a RasPi 3B:
mean: 2.577ms
median: 2.584ms
stdev: 0.109ms
min: 2.210ms
max: 7.976ms


The python code used for the measurements:

Code: [Select]
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# developed & tested with Python 3.9

from time import sleep
from datetime import datetime, timedelta, timezone
from Gpib import *
import atexit
from multiprocessing import Process, Queue

measurement_filename = "3458A 10V 1NPLC test.csv"

gpib_address = 22

def setup_dmm(addr):
    inst = Gpib(0, addr)
    inst.timeout(gpib.T10s)
    inst.clear()
    inst.write("PRESET FAST")
    inst.write("END ALWAYS")
    inst.write("ARANGE OFF")
    inst.write("DISP OFF")              # Disable Diplay
    inst.write("MATH OFF")
    inst.write("MEM OFF")
    inst.write("OFORMAT DINT")          # SINT, ASCII
    inst.write("DEFEAT ON")
    inst.write("LOCK ON")               # Local lock
    inst.write("DCV 10")
    inst.write("NPLC 1")
    #inst.write("APER 1.4E-6")
    inst.write("AZERO 0")
    inst.write("TARM HOLD")
    inst.write("NRDGS 1,AUTO")
    inst.write("TRIG AUTO")
    inst.write("DELAY 0")
    return inst

def run_measurement(inst, filename, scale, queue, finish):
    while not finish:
        data = inst.read()
        test_time = datetime.now(timezone.utc).astimezone()
        queue.put(f"{test_time.isoformat()}\t{int.from_bytes(data, byteorder='big', signed=True) * scale:.6e}\n")

def write_data(value, filename, finish):
#    with open(filename, 'a') as file_handle:        # append
    with open(filename, 'w') as file_handle:        # overwrite
        while not finish:
            while not value.empty():
                file_handle.write(value.get())
            sleep(0.01)

def exit_handler(inst, finish, write_process, measurement):
    finish = True                                   # stop processes
    inst.clear()             # needed to exit fast mode
    inst.write("DISP MSG,\"                 \"")    # enable Display and empty
    inst.write("LOCK OFF")                          # local lock disable
    while write_process.is_alive() or measurement.is_alive():
        print("Waiting for processes to end...")
        sleep(0.01)
    print('Despite the errors: exited gracefully')

def main():
    global measurement_filename
    global gpib_address
   
    data = Queue()                                  # multiprocessing queue for data
    finish = False                                  # process shared variable
    dmm = setup_dmm(gpib_address)

    write_process = Process(target=write_data, args=(data, measurement_filename, finish))
    write_process.start()

    dmm.write("ISCALE?")
    scale = float(dmm.read().strip().decode('utf-8'))
    dmm.write("TARM AUTO")

    print (f"Collect Data DMM {gpib_address} to \"{measurement_filename}\"")

    measurement = Process(target=run_measurement, args=(dmm, measurement_filename, scale, data, finish))
    measurement.start()

    atexit.register(exit_handler, dmm, finish, write_process, measurement) # graceful exit no matter what

    print("Measurement running... finish with CTRL-C")
    measurement.join()
       
    print("Done with measurements")

if __name__ == "__main__":
    main()

Results for 1NPLC (50Hz/20ms and more than 6 million datapoints):
mean: 21.808ms
stdev: 0.058ms
min: 10.848ms
max: 33.124ms

The deviation of 1.8ms gives only a small error for the NSD - the white noise part is ~4% high - which was acceptable.
« Last Edit: October 09, 2023, 11:27:04 pm by MiDi »
 
The following users thanked this post: e61_phil

Offline CurtisSeizert

  • Regular Contributor
  • *
  • Posts: 139
  • Country: us
Re: 3458A Worklog
« Reply #24 on: November 18, 2023, 06:47:40 am »
I struggled with this same thing, and I am reasonably satisfied with the solution. The key is if you want to make FIFO reads non-blocking use "INBUF ON".

This is the script I use to digitize samples from the 3458a, except the couple lines for sample timing, which I put in to demonstrate that it works as advertised. I put in the t0 bit to make the list of sample times readable.

Code: [Select]

from pyvisa import ResourceManager
import time
import pandas as pd

DCVrange = 0.1
NPLC = 0.1
numsamp = 1000
sfreq = 50
sleeptime = 1

stime = 1/sfreq
aper = stime/2
logfile = 'test.csv'


rm = ResourceManager()
dmm = rm.open_resource('GPIB1::22::INSTR')

dmm.timeout = None

dmm.write("END ALWAYS")
dmm.write("BEEP OFF")

#dmm.write("MFORMAT ASCII")
dmm.write("OFORMAT ASCII")

print("")
print("Voltage meter: ", dmm.query("ID?"))


print("")
print("Waiting %d seconds" % sleeptime)
time.sleep(sleeptime)


dmm.write("DCV %f" % DCVrange)
dmm.write("APER %f" % aper)
dmm.write("TIMER %f" % stime)
dmm.write("NRDGS %d, TIMER" % numsamp)
dmm.write("AZERO ONCE")
dmm.write("MEM OFF")
dmm.write("INBUF ON")
dmm.write("RATIO OFF")

dmm.write("TARM AUTO")
dmm.write("TRIG SGL")


df = pd.DataFrame(columns = ("V","freq"), dtype = float)
V = []
times = []
t0 = time.time()

count = int(0)


while count < numsamp:

    V.append(dmm.read_ascii_values()[0])
    times.append(time.time()-t0)

    pct_comp = count/numsamp
   
    print(end='\x1b[2K\r')
    print("Progress {:2.1%}    ".format(pct_comp), end="\r",)
 
    count = count + 1

df["V"] = V
df.to_csv(path_or_buf= logfile)

delta_t = times[numsamp-1]-times[0]

print("Average sample time: ", delta_t/(numsamp-1))


Running 1000 samples, with stime = 0.02, I got 0.020000514s for the average sample time. I would not trust this code to give you an accurate indication of the aperture jitter unless you are running on a real time operating system. Even then, there is uncertainty in how long the transfer will take, the conversion from ascii to float, etc. The way that I used to check aperture jitter was to use those settings to digitize a 9 Hz sine wave and then took an FFT. I can't remember the results when I did that offhand, but they were good enough for the LF measurements I am doing. I hope this helps.

Also, I noticed you had asked me about this in another thread and I forgot to respond. My apologies for not doing it sooner.
 
The following users thanked this post: MiDi


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf