Datron 1271 repair

[rigrunner]

A while ago a picked up a faulty Datron 1271 and have been meaning to post repair details for a while.  I recently built an LTZ KX reference and measuring this was enough to be reasonably certain that the 1271 is working as it should.  Most of this is from notes i've made during the repair but some is from memory.

The 1271 was offered on the usual auction site as "Powers up but unresponsive front panel" by what appeared to be an individual seller. Once i'd won the auction I found out that the seller was an employee of a calibration house that offered repairs. If I had know this before hand I probably would have bid less, but hindsight is a wonderful thing. I'm under no illusion with used electronics from auction sites, I treat pretty much everything I buy from ebay as a parts only purchase.

Initial inspection

The meter powered up as expected with the defaults: DCV, 1KV range 6.5 digits resolution.
Applying 10V to the terminals showed a sensible reading and a short showed close to 0V.
Other than the power switch there was no response from any of the front panel buttons.
After a few minutes there was an interesting smell that was reminiscent of schaffner AC filter so it was powered off quickly and the covers removed for a closer look.

The first thing I noticed was the that mains earth connectors were all disconnected due to a missing nut and the rear panel was loose because the retaining screws weren't fully tight.  A sure sign that someone has already been inside previously

The IEC mains filter and plastic shroud were covered in thick ooze. The Waycom WF 120-3/05 filter appears to have been leaking into its shroud for some time. This was replaced with a Roxburgh RID-0642-H. The earth connection between the filter and the chassis is by exposed braid so I placed shrink wrap over the live and neutral terminals as an extra safety precaution.  The earth connections were placed on to their post and secured with a new nut.

[rigrunner]

Fault finding

The Digital assembly power supplies were measured and found to be within specification.
(I can't find my notes for these measurements )
Test points are:

TP501 = -14V
TL502 = 5V
TP502 = 45V
TP504 = -14V (unregulated)

TP503 = 0V reference

My first check for the keyboard fault was to remove the fascia and check the front panel buttons were actually connected and were contacting when pushed.  The buttons were all fine, the repair wasn't going to be that easy.

The signal from the keys input the display PCB through ribbon cables via SK22 & SK23 and are fed to a 74C922 key encoder.  The keyboard signal leaves the display panel through PL21 and enters the digital assembly via PL2. Line KB5 acts as a clock signal to flip-flop U302 and signals U203 CLA3721 ASIC that a key is pressed by pulling FP_INT_L low. All 6 keyboard lines KB0-KB5 are fed through buffer U301 74HCT244 and placed on the 8 bit BUFFERED_DATA(0:7) bus when latched by RD_FP_L signal generated by PAL U111.

I traced these signals and the keyboard input was being read and placed on the lower 8 bit bus but still no response to a key press from the system.

At this point i thought the ROM might be the issue. The meter is quite old and bit rot is not unheard of. I pulled the ROMs U103 and U104 and read them several times checking the read data for differences between reads. One ROM produced bit errors at 5V but read ok at 5.5V. I burned a couple of new ROMs from the data and tested the 1271 again. No change, it still ignored keyboard input.

I hooked up the GPIB port to see if that worked. Sending commands to the 1271 caused Rem to illuminate on the main front display and subsequent commands caused a 68000 bus error displaying error "9002 - Unexpected Exception" on the secondary display and locked up the 1271. The only thing i hadn't checked at this point was the SRAM. Swapping U105 and U112 caused the 1271 to run for a little while and then crash, but whilst it was running it did respond to the keyboard! After replacing U105 and U112 with a pair of NOS M5M5256BP SRAMs the 1271 powered up with everything functioning – success.

[rigrunner]

I replaced the power supply electrolytic capacitors as a matter of course.
The replacements I used are in the table below. Note that if you choose to replace with different parts that space is limited and you won't be able to install anything taller than 25mm.

ID          Original       New                                    Farnell #
C501        1000uf 40v     Panasonic  ECA-1HHG102 1000uF 63V      9693009
C502        470uf 63V      Panasonic ECA-1JHG471 470uF 63V        9693068
C510        220uf 40V      Rubycon 100YXJ220M12.5X25 220uF 100V   2346277
C513, C514  2200uf 16V     Panasonic ECA1EHG222 2200uF 25V        9692851
C515        470uF 25V      Panasonic ECA-1JHG471 470uF 63V        9693068
C520        330uF 100V     Nichicon UVZ2A331MHD1TO 330uF 100V     1822727

The digital assembly withdraws from the main chassis complete with the rear panel.
To remove:
 
Unplug the pcb cable plugs from their sockets
Remove the two plastic edge covers
Remove the 4 countersunk screws located at the corners of the rear panel
Remove the 3 securing screws along the centre of the rear panel taking note that one of the screws is shorter than the others.
Withdraw the digital assembly from the chassis, keeping the terminal release bar above the components as you pull the assembly.


After the capacitor replacement the voltages were measured as:

TP501 = -13.92V
TL502 = 5.00V (3.3mV RMS)
TP502 = 47.03V (107mV RMS)
TP504 = -14.164V

[rigrunner]

With the digital assembly now fully working i could run a full self test. This failed with one error 2863 which points to the Ohms assembly. The service manual says that 2863 is a Gain Drift error - Digital comparison of the present Gain Magnitude against that recorded at the most recent Internal Source Cal 0.999,000 < Drift Ration < 1.001,000.

Mickle.T suggested that this might be sign of long term drift and performing an internal source cal might be the solution. The internal source cal had an effect in that it caused the self test to pass for a short period after warm up but the self test failed when cold and also after a long power on time.

The service manual shows pathways against each test condition and associated errors. Switching in pathway 53 and monitoring the displayed value showed an upward creep over time that didn't seem to stabilise no matter how long i left the 1271 powered on.

I monitored a few points on the Ohms assembly around the constant current sink and found the voltage on the gate of Q207 was drifting upward slowly. I replaced R216 10M? 1% 0.12W 100PPM and D203 1N458A which stabilised the voltage at Q207 gate.

After another internal source cal was performed the 1271 passed self tests continuously once warmed up.

[rigrunner]

With everything seemingly working it was time to inspect the other boards.

A pair of FETs, Q114 & Q119, on the AC assembly looked a little crusty with flux. I removed these,  cleaned the board and reinstalled them. I also replaced C133 100uF 40V whilst the board was out.

The DC assembly also had a pair of crusty looking FETs, Q206 & Q207. The flux around the leads of these seems to have eaten into the top of the PCB a little. I removed them both and cleaned the board around them before reinstalling.

The final task was to replace the electrolytics on the Digital assembly.

I think i was just in time with this as the large electrolytics had started to leak. C004 was the worst but all of the large caps showed some electrolyte leakage.

The replacements I used are in the table below. Note that if you choose to replace with different parts that space is also limited here, but not as limited as with the Digital assembly. I stuck with 25mm capacitors as per the digital replacement parts, but you can probably just about squeeze in 30mm.


ID          Original       New                                    Farnell #
C001, C004  1000uf 40V     Panasonic  ECA-1HHG102 1000uf 63V      9693009
C007, C012  220uF 63V      Rubycon 100YXJ220M12.5X25 220uF 100V   2346277
C015        2200uF 16V     Panasonic ECA1EHG222 2200uF 25V        9692851
C912        470uF 25V      Panasonic ECA-1JHG471 470uF 63V        9693068

C002, C003,
C005, C006,
C009, C010, 1uF 63V        Wurth WCAP-ATLL 860160672002 1uF 50V   2495115
C011, C014,
C016, C017

C309, C313,
C314        10uF 50V       Wurth WCAP-ATLL 860160672009 10uF 50V  2495117

After the capacitor replacement the voltages were measured as:

TL001 = +15.215 (0.4mV RMS)
TL002 = -15.090 (0.4mV RMS)
TL003 = +35.542 (0.4mV RMS)
TL004 = -35.093 (0.4mV RMS)
TL005 = +5.038 (0.9mV RMS)

0V from U002 centre pin or heat sink.


With a little help from ManateeMafia I determined that the calibration key is this one from RS

“Key for Operated Switch” RS Stock no.: 319-792

All that is left to do is find a way of dumping the calram and convert to f-ram with one of ManateeMafia's converter boards.


Finally a big thank you to Mickle.T and ManateeMafia for answering the questions i had whilst working on this

[rigrunner]

The remainder of the pictures and ROM images.

[Mickle T.]

Thank you very much for the excellent job, rigrunner!
Based on the ROM dump it was very easy to reverse the last two semidocumented GPIB commands.
1) DUMP gives a r/o access to the selected 16 bytes memory region.
Usage:
DUMP? memory_type, address
memory_type can be PRIM (primarily calibration constants set in NVRAM), SECN (selfcal constants in NVRAM), IPZ (Input Zero constants, psw e.t.c.), RAM (16 Kb part of normal RAM);
address must be even!!!
Usage example. Loading DCV 1 kV range input zero constant (32 bit):
DUMP? IPZ, 96
0060 74FF 74FF 74FF 7424 7400 7400 7400 7400

2) YEUK gives a sequential r/o access to the 8 Kb asynchronous buffer with a low level results of A-D conversion (without calibration constants applying and averaging).
Usage example.
YEUK - resets an internal read and write pointers to zero and starts to fill the buffer. If trigger type is set to External and ADC is in the idle state, buffer has no any changes.
YEUK? - reads a one stored value to GPIB and increment the read pointer.
All the values in the buffer are triplets of sequential floating-point numbers: 1 - main value, 2 - small variable offset, 3 - result of their summation. The order of magnitude of the numbers depends on the current ADC scale length.

[rigrunner]

You got further than me with the rom disassembly in a very short space of time 
I'd determined that DUMP? and the following 4 entries in the command table were the secret to dumping nvram but i hadn't yet worked out how the command worked.

I've dumped the PRIM = 2KB, IPZ=2KB and SECN=96B.
Comparing the binaries to the special firmware that ManateeMafia posted on xdevs and it looks like the IPZ occupies the first 2KB of nvram and the PRIM part occupies the second 2KB.

[rigrunner]

Here's my nvram and ManateeMafia's special nvram. It looks like a good match.

[ManateeMafia]

Great job on the repair! 

More Datron/Wavetek meters saved from the hands of would-be butchers. I think you have added a great tool to your lab if you plan on keeping it. I couldn't find a download from my FRAM boards so I will have to get a copy from both of my 1281 and post them.
It will be added to my to-do list once I clear the bench.

[rigrunner]

Great job on the repair! 

More Datron/Wavetek meters saved from the hands of would-be butchers. I think you have added a great tool to your lab if you plan on keeping it. I couldn't find a download from my FRAM boards so I will have to get a copy from both of my 1281 and post them.
It will be added to my to-do list once I clear the bench.

Thanks   It is a keeper.

The SECN data is 4KB and not 96B as i first thought and that fits nicely into the 8KB space.

First time i've written anything in python and i can't say that i like the indenting, but attached is a piece of code that should dump the 1271/1281 nvram regions into 3 separate files along with a combined nvram image. (It requires linux-gpib)

It takes about 5 minutes for everything to come down via GPIB and shows progress for each region as it goes along.

Reading nvram from Datron Instruments 1271 to 23900-7.X.nvram
Dumping PRIM to "23900-7.PRIM.nvram"
PRIM done.           
Dumping IPZ to "23900-7.IPZ.nvram"
IPZ done.           
Dumping SECN to "23900-7.SECN.nvram"
SECN done.           
Creating 23900-7.nvram.bin
Finished.

[Mickle T.]

1271 DC Assembly PCB have some hardware incompatibilities between an older (1989) and newer (1992) versions. Firmware is incompatible too.

[rigrunner]

Interesting - I haven't come across any firmware earlier than my V2 rom in my searches. The 1281 seems to have made it to V3 rom.

The diagrams i have mention DC400866 V1.1 and 1.3 with the old line locking.

[doktor pyta]

Great job! Thanks for posting.

Note: Something like year ago I added a switch to disconnect filament of both VFDs in my 1271.
It is connected in series with F504 or F505 fuse (one of them).
The switch was placed on the rear panel.

I can confirm that this modification does no harm to the meter/ display.

[rigrunner]

Great job! Thanks for posting.

Note: Something like year ago I added a switch to disconnect filament of both VFDs in my 1271.
It is connected in series with F504 or F505 fuse (one of them).
The switch was placed on the rear panel.

I can confirm that this modification does no harm to the meter/ display.

Switching off the display is on my list of things to do. My fall back plan was a toggle switch on the supply lines 
Glad to hear it's not detrimental to the display. I wasn't sure how they'd react to that.

[pelule]

High rigrunner,

great job.
What CPU board version do you have?
Is it already a newer one with the U110/PAL 20L8?


BR
/PeLuLe

[rigrunner]

Hi pelule,

What CPU board version do you have?
Is it already a newer one with the U110/PAL 20L8?

I have 400901 V1.9 digital board and the programmable logics are all suffix  10 :-  400902-10, 400903-10 and 400904-10. I think they are all dated 20th June 89 but it's hard to tell from the pictures i took. If i take the covers off again i'll make a proper note of the labels.

[Mickle T.]

I have the same 400902/3/4-10 chips, but they are all dated 29th January 92.

[pelule]

As far as I have understood Datron part system, the definition of the content is defined by the No (the Datron part number).
The date just gives, the day/date, the PAl is programmed.
So all of the named PALs should have the same content.
/PeluLe

[TheSteve]

I have used rigrunner's python script before to dump my 1281 but recently found it didn't match a physical read of the chip. The data was correct but PRIM and SECN data were in the wrong order in the complete nvram.bin file.
I swapped the order when it creates the output file and it now gives me a dump which matches.
I also used it with vxi11 so that line is at the top and can be commented out to go back to a different gpib controller.
I've attached the very slightly changed file.

[rigrunner]

I've got a 1281 almost repaired. I'll dump that and compare with my 1271 when it's up and running.

[TheSteve]

The dump now matches the output from the ezgpib script that pelule wrote (based off of your python code I believe). So it is odd to me they didn't match with the original python script.

[rigrunner]

There are some address differences between the 1271 logic boards. One 1271 rom version matches the 1281 addresses and the other has a bank change.
Could be that, or more likely my code

Can you post your 1281 dump? I'll compare against my original 1271 dump.

[TheSteve]

My 1281 dump is attached.

I had wanted to also use the script with a 4920M but it seems the operation of the DUMP? command is a little different. It doesn't accept arguments and just spits out cal values for the range currently selected. If you keep sending DUMP? it will increment through the cal data but doesn't seem to be able to dump the entire nvram image.

[rigrunner]

Definitely different to my 1271.
I'll dump my 1281 as soon as I have it back together and compare that.

Which firmware version is your 1281 running? Mine has v3.12 on a later revision digital board. My 1271 also has the later digital board - the second of the two on Tin's page here https://xdevs.com/fix/d1281/#dig_pcb

Edit: The 1271 does something similar with the dump command if the args aren't supplied. Perhaps it's just a case of working out the correct args for the 4920M?