Advantest R6581 Service Manual

[Mickle T.]

It is well known that the Advantest R6581 DMM is one of the most affordable 8.5 digit multimeters on the market. However, many owners are depressing by the fact that this device has very poor technical documentation and the unpredictability of some metrological parameters with the complete impossibility of setting them up.
Although the first problem was solved relatively quickly, the second problem could not be solved for many years... until today.
So, on the eve of the significant event Metrology Meeting 2022, I want to give a gift to Voltnuts community of the EEVblog forum - the Advantest R6581 DMM Service Manual.
I want to warn everyone right away that this manual is not finished (and will not be anymore) and probably contains errors, but it can be used to overcome the most critical problems of the device, including ADC non-linearity and errors in high-resistance measurement ranges.
The main essence of the service maintenance of the R6581 multimeter is entirely based on updating the data in the EEPROM in a special mode of the device, which I called the "Service Mode". This mode is a know-how of the manufacturer and is kept secret even from commercial partners of Advantest/ADCMT. However, after spending five man-years to study the firmware of the device, it was finally possible to identify an exhaustive list of commands, their syntax, the purpose of data structures, as well as to develop and validate methods for adjusting the device.

P.S. Update 10/2023.
Revision #6 of R6581 schematic diagrams: https://drive.google.com/file/d/1x6WiDJwi5rkW8gP5E-i8c49R25UckNoZ/view?usp=sharing

[branadic]

Hi MickleT.,

publishing your 5 years of effort in a single document on R6581 with all your findings is a huge contribution to the voltnut community. Many thanks for that. I can't find the right words for this amazing work with such a big impact on the performance of the meter. I can just say "wow", well done, touché. 

-branadic-

[branadic]

Thanks to help by alm we prepared an m-file (Octave or if you like Matlab) that takes an INL measurement of your R6581(D,T) with the original INL correction coefficients against your trustworth 3458A (or whatever meter you like) or calibrator and uses least square method to calculate new coefficients for improved INL.
Attached is a graph showing the result with original coefficients, INL correction virtually turned off (H0 ... H15 set to 0, 0, ..., 0, 1), manually improved coefficients, coefficients found with least square method and coefficients found on a second, smaller stepped sweep to get an idea of repeatability and stability of measurements and coefficients.

The m-file will be released here, so stay tuned.

-branadic-

[Mickle T.]

Service Manual in post#1 updated to next revision.
Some infographics about how the DIAG Internal Check is working.
As far as I understand, the readings in this mode cannot match the readings in the normal measurement mode, since a fixed offset is used instead of ADC zero, and also because post-processing settings (NULL, statistics, etc.) are not taken into account in any way. Try, for example, switching the device to 100 mVDC mode, shorting the input, calling NULL, and then switching to DIAG mode. At least in the Internal Check menu, you will be provided with a surprise

[leighcorrigall]

...

The m-file will be released here, so stay tuned.

-branadic-

Thank you, Branadic et al. 

Just fixed the overheating issue with my Fluke 5440B and my Datron 1281 seems to work well enough for a linearity comparison on the 10 V range. Looking forward to this fancy m-file!

By the way, will the script also include the remaining corrections such as OHMS and AC?

Regards.

[Kosmic]

Service Manual in post#1 updated to next revision.
Some infographics about how the DIAG Internal Check is working.
As far as I understand, the readings in this mode cannot match the readings in the normal measurement mode, since a fixed offset is used instead of ADC zero, and also because post-processing settings (NULL, statistics, etc.) are not taken into account in any way. Try, for example, switching the device to 100 mVDC mode, shorting the input, calling NULL, and then switching to DIAG mode. At least in the Internal Check menu, you will be provided with a surprise

That would explain the offset in diagnostic mode we are seeing on some units.

[Kleinstein]

Service Manual in post#1 updated to next revision.
Some infographics about how the DIAG Internal Check is working.
As far as I understand, the readings in this mode cannot match the readings in the normal measurement mode, since a fixed offset is used instead of ADC zero, and also because post-processing settings (NULL, statistics, etc.) are not taken into account in any way. Try, for example, switching the device to 100 mVDC mode, shorting the input, calling NULL, and then switching to DIAG mode. At least in the Internal Check menu, you will be provided with a surprise

That would explain the offset in diagnostic mode we are seeing on some units.

The still leaves open why the ADCs offset is so different with some units. The bad one are some 3 V off - that is a lot and not easy to explain with something like resistor tolerances or leakage.
The more natural variations in the offset should be more like in the 10 mV range.

[Mickle T.]

3 V offset in diagnostic mode can't be explained by fixed ADC zero.

[Mickle T.]

In general, the results of setting up the multimeter according to the service manual are encouraging. Testing and calculation of DCV, OHM and INL correction factors takes about 30-40 minutes in automatic mode. However, I want to draw the attention of everyone who is going to use this technique to the fact that the implementation of paragraph "14.5. Resistance transfer adjustment" will require a new calibration of the multimeter by an external resistance standard!

In addition, I categorically do not recommend measuring with a multimeter in the ranges of 10, 100 and 1000 MΩ, using a 4-wire connection scheme, as well as 2-wire, but with the AZERO function enabled. If, nevertheless, zero correction is required in the range of 10 MΩ (at 100 and 1000 MΩ it is always disabled), then it is better to carry it out once, turning it off before the main measurement(s).

[branadic]

Attached are the m-files including an example. Please note that the script runs without errors in Octave version 6.4.0 (2021-10-30), but won't work with the latest version 7, something got screwed up in the latest release.

-branadic-

[Mickle T.]

This is alpha-version of R6581 adjustment script for EZGPIB2 fork. I think it can be easily modified for any other calibrator model.

P.S. The program for fine-tuning AC ranges is still in the process of being written and debugged. However, the algorithm appears to be rather complex and time-consuming, and the setup requires a full-fledged ACV / ACI calibrator, which I definitely will not have in the foreseeable future.

[Kosmic]

Thanks Mickle and Branadic, much appreciated 

[TheDefpom]

Firstly, thanks for sharing and working on the files!

I am not familiar with EZGPIB, only recently hearing of its existence (yeah i'm probably a bit slow).

From the quick poke around I did in the files I can see commands that look like they are for the Datron calibrator, so that is very good !

Are there any instructions on using these files, I have the R6581T (which I recently repaired), and a fully optioned Datron 4700 calibrator.

I can see that the R6581T is not linear across its range, even though I am comparing it to a couple of 7.5 digit meters (Solartron 7061 and Datron 1082).

I also only recently started playing around with GPIB control of my instruments, so I am not up to speed with that fully either., I have been tinkering with Python to control my instruments using vxi11, and I can indeed change settings and read from the Datron and R6581T without problems, but I still consider myself a total novice in this area.

[baof]

Hello, Mickle T

Thank you for all these years of work and selfless sharing!

May I ask if there are any instructions found in the disassembly regarding INT CAL accuracy and temperature drift adjustment? I think there should also be relevant instructions to correct these two. All R10 resistors on the 6581 reference board use the same 390K resistor, and the connection method is different from the standard application

[Mickle T.]

INT CAL accuracy correction is specified in R6581 Service Manual, par. 1.3. Factory calibration data management. But keep in mind - HOSEI commands are very dangerous! You can easily render your multimeter inoperable.

The internal temperature sensor in the multimeter is used at two levels of abstraction.
The top layer includes the SCPI/ADC command interpreter and front panel interface handler. In this case, all temperature measurement requests are processed by the Get_Internal_Temperature() function.
The lower level means temperature measurement after the end of external or internal calibration. The special function is not used in this case. Low-level hardware configuration commands, diluted with delay flags and combined into lists (list_INT_Temp, list_EXT_Temp, etc.), are passed to the unified handler. The results of the temperature calculation after a successful calibration are stored together with the calibration constants and the date/time in EEPROM.
Thus, no correction or other processing of the temperature sensor readings is carried out in the multimeter firmware.

[Mickle T.]

More than half a year has passed since the update of the factory correction factors of two multimeters, in which ADC INL, DCV, OHM and ACV errors have been corrected. The result is rock solid
From now on, I consider the topic with Advantest R6581 closed for myself. I thank the participants of the discussion for their help.

[Mickle T.]

An updated and expanded version of the circuit diagrams has been uploaded to post No. 1:
! fixed minor bugs,
+ completed all the digital circuits on the analog assembly,
+ added a simplified circuit diagram of the AC assembly,
+ explained the purpose of the chips on the main assembly.

[Mickle T.]

An R6581 with a dim display can be made 15% brighter without having to replace it with a new VFD or OLED, simply by turning off the brightness control signal. It is likely that this can be done with a special command, but unfortunately the Hitachi H8-322 Front Panel MCU firmware is not available. Therefore, I simply raised pin 11 of the U3 chip.

[TheDefpom]

That is a brilliant diagram, do you have more for the display and digital section as I haven't seen it in the manuals you have been making available.

Also looking at it wouldn't you also have to break /CL4 as well ?

I am sure that in time I will need to replace the display in mine with something else as it is pretty dim, and having the display diagrams would certainly help with that, I haven't had the time to try and reverse engineer that area very much, I have done a little to try and figure out how it is connected but nothing like what you have been doing.

[Mickle T.]

The /CL4 signal has a constant level. Brightness is limited only by screen blanking with /CL56.

The schematics for the front panel, GPIB and AC boards are actually ready. All that remains is to redraw them in ECAD. The digital board is much more complicated, unfortunately.

[Mickle T.]

As I expected, the VFD scanning algorithm turned out to be quite cumbersome and overcomplicated in order to simplify the layout of the R6581 front panel PCB. But there is good news: even the Arduino Nano (Atmega328p) successfully intercepts traffic to shift registers.
To replace the VFD, a 5.5-inch OLED 256x64 was purchased. However, its height is too high and will require CNC milling of the internal aluminum body of the front panel. I don't really want to do this on a working device. So I'll have to wait, maybe I'll be able to find an R6581 with a faulty display and which I don't mind experimenting with

[Ismsanmar]

Regarding that issue, isn't a 3.12-inch display better than the 5.5-inch one? I know it's a little smaller than the original screen, but at least you don't have to make any modifications since it fits into the original window.
And in my case, I don't think a 328p is enough. I have done some tests on Arduino with the u8x8 library and to run the SSD1322 at a refresh rate like that of the original screen you have to do too much juggling.

[Mickle T.]

I find the 3.12-inch display to be too small to be comfortable to use with a multimeter. At least not with my eyesight.
I don't use the Arduino development environment. Only old-school low-level coding in C. In addition, the u8x8 library is completely useless here, because the only function of the interface translator is to receive a bit matrix of symbols and send it to the SSD1322 with on-the-fly conversion. No fonts are used here.
In the original, the VFD scanning frequency is ~111 Hz. For comfortable work with OLED, one third of this is enough.

[Ismsanmar]

I know that. I only used it for a fast test of the display. I wasn't planning to spend more time writing in avr-libc if in the end I wasn't going to get a framerate close to that of the original screen at low NPLC. Any of the videos on the internet showed the necesary refresh rate for the SSD1322 to be used on the multimeter.

But in the end, even if you are not going to use fonts, I did plan to use them in my project. Since I would like to emulate the original fonts on the screen, even if it is a little more work. And for this, at least in my case, the 328p falls short with its framebuffer management.

[Mickle T.]

I know that. I only used it for a fast test of the display. I wasn't planning to spend more time writing in avr-libc if in the end I wasn't going to get a framerate close to that of the original screen at low NPLC. Any of the videos on the internet showed the necesary refresh rate for the SSD1322 to be used on the multimeter.

But in the end, even if you are not going to use fonts, I did plan to use them in my project. Since I would like to emulate the original fonts on the screen, even if it is a little more work. And for this, at least in my case, the 328p falls short with its framebuffer management.

I don't quite understand the essence of your project. Are you going to recognize in real time a pixel-by-pixel image of each character output by the R6581 on the VFD, and then render those same characters on the OLED using a custom font?