Solartron7061

[Kleinstein]

For a reasonable Allan variation plot it would need some 1000 points - so about 1 hours worth of data with a short and preferably little drift and no jumps from drift correction.
I used a program AlaVar5 , that needs ascii (CSV) data with time and voltage. AFAIR space separated and as an odd point that took me some time to find out the values in the first row needs to include a decimal point.

The plot from the drifty part with a short suggest a peak to peak noise of some 10 µV and thus some 1.7-2 µV RMS. So the 2.8 µV number likely includes some drift / jumps.
This number looks better, but still higher than the about 0.7 µV of noise I can account for from the theoretical side.


There are a few possible sources for drift: one is the amplification to produce the +- reference. The other parts are the precision resistors. these have quite some effect: a 1 ppm drift in the resistor ratios (reference part) can result in 20 µV of drift for the ADC. For this reason the resistors used should be really good quality, but could still show some slow drift (e.g. warming an releasing humidity).
The OP used in the inverter for the reference (e.g. make -10 v from the +10 V) can also contribute to drift. It's drift is amplified about 2 times.

Leakage (getting less when warming) could also be a factor.

The rather jumpy curve with the drift correction suggest that there is something not working very well with the drift correction - like too much noise. AFAIR there was a problem with the 8081 and too little waiting time. Causing trouble. Because of dielectric absorption the drift correction can be problematic when measuring a voltage different from 0. I don't know if and how they take the effect into account.

[Dek]

So the +32V rail looks like it needs some attention.
As a simple comparison looking at the + and - 32V rails on the scope, +32V has 50mV ripple and the -32V rail 5mV
Not sure whats going on the the RAM back up battery- D502 could be duff, so this also needs looking at.

Along with the new filter I've on order from Mouser,  also a LTC1052 .

<edit> D502 was toast, the poor battery was back feeding the 5v rail..... temporarily soldered in a 1N4148 and things look like they should be.

I'm not surprised that diode was toast after its alkali bath. Well spotted!

I think we both saw that the +/- 32V rails were only used by the expansion sockets? That's why I haven't bothered swapping the capacitors on that rail yet, but I will and it will certainly be an issue for your memory expansion board if I'm remembering correctly.

Ah yes, that's a bit or a worry then as the PSU rails look OK.
The GPIB interface will be useful to look into this much further, just need the new controller IC to flop through the letterbox!

[grizewald]

For a reasonable Allan variation plot it would need some 1000 points - so about 1 hours worth of data with a short and preferably little drift and no jumps from drift correction.

I used a program AlaVar5 , that needs ascii (CSV) data with time and voltage. AFAIR space separated and as an odd point that took me some time to find out the values in the first row needs to include a decimal point.

Do you have a reliable link for that program? The site it originates from (http://www.alamath.com) doesn't seem to exist any more and I wouldn't touch any of the download sites it appears on with a bargepole.

What bothers me about all of this is that some of our thoughts about fixing the problems are not based on the correct assumptions in my opinion. I don't believe for a second that these meters showed any of these kind of problems when they were new. We must assume that the Solartron engineers who designed the meter knew what they were doing. Therefore, the root causes of the noise and drift problems we are seeing must be rooted in degradation of components or increased PCB leakage over time and not in any fundamental design error on Solartron's part - like "forgetting" to decouple the integrator OP amp's rails.

The noise levels on my meter make the last 1.5 digits a random number generator, even with filtering enabled. There's no way Solartron would have been able to sell the meters if this was the case when they were new.

[Dek]

The noise levels on my meter make the last 1.5 digits a random number generator, even with filtering enabled. There's no way Solartron would have been able to sell the meters if this was the case when they were new.

I tend to agree.
Switching to DCI (rear terminals shorted) and DC I see that last two digits jump about the same as the DCV (although the meter has only been warming for 1.5hrs).

[grizewald]

To have a proper look at the stability of the voltage reference section, I could make a high quality test lead that I can connect to test points 301, 302 and 303 and bring the voltages out to my scope without coupling a load of noise to them in the process.

I have some three core shielded PTFE cable. The three cores are PTFE insulated multi-stranded silver plated copper wire. All three wires are twisted together. The cable is thin enough that I could slightly enlarge an existing hole in the rear panel and be able to connect it and close the case.

What I'm a little unsure about is how to actually connect the shield. The whole analogue board is floating, so I really don't want to connect the 0V test point to mains ground via my Rigol scope. I don't really want to connect the shield to the 0V point either as I'm going to end up coupling whatever the shield picks up into the analogue board's floating ground.

I also have a battery powered Micsig scope which would get rid of the mains ground issue. I suppose I could connect the shield to the Micsig at the Micsig end and leave it open at the other end, but then if I include the 0V point from the meter inside the cable to give the Micsig the ground reference to measure the voltages against, that ends up being the same as connecting the shied (and whatever it is picking up) to the floating ground anyway.

 

[grizewald]

The noise levels on my meter make the last 1.5 digits a random number generator, even with filtering enabled. There's no way Solartron would have been able to sell the meters if this was the case when they were new.

I tend to agree.
Switching to DCI (rear terminals shorted) and DC I see that last two digits jump about the same as the DCV (although the meter has only been warming for 1.5hrs).

No nasty offset on your DCI reading though?

I'm starting to think that my best plan of attack is to get the analogue board out of the machine and clean it properly and see if there's a mechanical reason for my DCI offset. It's at least a more concrete starting point than I have now.

[Dek]

The noise levels on my meter make the last 1.5 digits a random number generator, even with filtering enabled. There's no way Solartron would have been able to sell the meters if this was the case when they were new.

I tend to agree.
Switching to DCI (rear terminals shorted) and DC I see that last two digits jump about the same as the DCV (although the meter has only been warming for 1.5hrs).

No nasty offset on your DCI reading though?

I'm starting to think that my best plan of attack is to get the analogue board out of the machine and clean it properly and see if there's a mechanical reason for my DCI offset. It's at least a more concrete starting point than I have now.

DCI offset.........if the meter would just stay still for a few seconds :-) 
anywhere between 7mA and  40mA
It will run at about 10mA for about 20 sec then increase to say 20mA or more then drop again - looks cyclic.
Did I say I could do with the GPIB working

Running a prog for ~2 mins give me>
(No filter 7 digits)
N=90
Max= 0.05340576
Min= 6.347656E-3
PP= 0.04705810

[Kleinstein]

The Very noisy DCI part looks like a different problem. Even with the noise is it at least reading a current only approximately right.
An offset of some 5 mA sounds like too much for just leakage on the board.  The current ranges should use some 200 mV range, so one could check that lower voltage range too.

For the reference section, sensing the internal reference and checking the reference part for noise with the scope are two parts and could be done separately. When using the scope there would be a connection to mains ground. This makes some sense as the ADC can cause spikes from the switching that could effect the reference part.

Connecting the internal reference to the input is separate and not really testing the stability of the reference. It is more checking the rest of the instrument and taking the reference out of the equation for a large part. So reference drift would essentially not effect those measurements. One can still check (include or not) the amplification from 7 V to +-10 V.  These signals are relatively low impedance, so there would be no need for special shielded cables - just connect the input, not ground !

For the noise, there are 2 points that have changed since the meter were build / designed: the mains grid got more noisy from an increasing number of PV and some wind turbines. SMPS can also contribute to mains noise. So the PLL for the frequency can have a harder time than it was some 30 years ago. The other point is that there is more RF around, especially mobile phones. So there can be possible new EMI susceptibility issues.

For the high resolution end, it is quite normal that the RMS noise is at about step of the last digit. So it is kind of normal that the last digit does move, up and down. The current 2.8 or 2  µV RMS noise is something like 3 or 2  times higher than this convention. So the noise is already better than 6 digit level - though not really 7.5 digit level. The drift level without the zero step every 10 minutes is relatively high. Still this is from quite some time ago - the expectations may not have been that high back than. given the drift level the zero step every 10 minutes makes about sense. If it was much better the time interval could have been longer. I don't know if there are specs for this and maybe the noise.

For the Allan variance, I could use the program if you provide some data (e.g. CVS data in some form, e.g. zip compressed).
I found the software on TiN's xdevs server - if you dare.  https://doc.xdevs.com/docs/_Freeware/

[grizewald]

For the Allan variance, I could use the program if you provide some data (e.g. CVS data in some form, e.g. zip compressed).
I found the software on TiN's xdevs server - if you dare.  https://doc.xdevs.com/docs/_Freeware/

I'll trust a download from TiN's server much more than I would allowing some dodgy website's Javascript, that's for sure! Anyway, I'll be installing it into a Windows virtual machine, so I'll just take a snapshot of the VM before installation, run it, and then revert the snapshot afterwards. Thanks for the detective work!

I think Dek's machine still has some more serious problems to be found. Mine might have an unwanted offset on DCI, but it can be nulled out and the meter would have passed calibration on the DCI range without adjustment if it wasn't for the unwanted offset at 0 on DCI.

You're right about testing the reference voltages of course - just connect the probe inputs without the grounds!
 My excuse is I've been really sick for the last week.

While the theories about SMPS, mobile phones and increased mains EMI in general are attractive, I just don't buy it. That the mains of 30 years ago was cleaner and more predictable in frequency than it is today doesn't sound that likely. 30 years ago, most of Europe still had a large manufacturing industry with lots of heavy machinery creating interference which was certainly magnitudes larger than what we see today. The Solartron's are also very well shielded boxes with conductive linings on the panels inside with will soak up most RFI sources, just as they are intended to do. Also, if this was the case, then how is it that tggzzz's meter is so quiet? Or, for that matter, my 20 year old 34401A? Nah, I don't buy those theories.

I certainly accept that the last digit on any meter, regardless of counts, is generally a random number generator, but the second to last should be stable to +/- 1 count.

It's interesting to note that in the 7061 manual, one can find the following statement:

DRIFT CORRECTION
The instrument automatically compensates for internal drift every
15 minutes but does not interrupt a GPIB input or a keyboard trigger.
Under remote control, drift correction may be turned on and off.
For example, in tracking measurements lasting longer than 15 minutes,
drift should be turned off for continuity of results.

It's interesting that they suggest turning off drift correction on longer measurements. That's all they say about it, so I'm not sure what I should really make of that.

I think I may have to accept that the 7061 is no 3458A and keeping hoping that I'll see one pass by me at the right price some day!

Anyway, I'll get some appropriate logs and see what looking at the Allen plots might reveal. I'll also connect up my Time current source to the rear terminals and have a quick look at how stable mine is on current readings. Plots to follow!

[Kleinstein]

The measurement from Tggzzz is in the 2 V range. Here the ADC noise is reduced by the gain to 1/10 , so some 0.2-0.3 µV_rms from the ADC and  some noise from the amplifier. The 0-0.5 Hz noise from an ICL7650 should be somewhere then 0.5 µV_pp range, so not very high.
 
For the DC drift, one could check how sensitive the DC offset is to things like loading the 5 V supply on the analog board. There could be some effect via delays in the Glug switching that depend on the supply.

[Dek]

Repaired the solder resist in the battery area, best I could anyway. It was a very crusty in the area between the battery and the regulator.
I attached a small 3.7v lippo via a 330 resistor to power the EAROM while the main battery was taken out.
All the caps , diodes and resistor were taken out too so that I could give the affected area first a polish with a fibreglass brush, IPA wash then paint with the new solder resist.
Looks much better, if not quite factory fresh
Arduino GPIB adaptor built and ready for when the controller IC finally arrives.
Dek.

[Dek]

The GPIB controller IC arrived today - plopped it in and connected up WaveyDipoles  Arduino USB GPIB interface
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/
Quick check using ++read  and heypresto - it sent back a reading
Typed the bee(p) command and the 7061 gave a joyous BEEP
So all is hunkydory in Solartron world, for the moment at least.

Quick log of the meter with IP terminals shorted
DCV Range 1 set  6 digits just to test the logging is working.
I manually cut and paste the readings from Putty into excel do a Data to columns and then graph.
Now to do some comparison tests with Grisewald and his 7061 - haven't seen him for a while, hope he's OK.

Dek

[Dek]

Now with the GPIB logging working I have took a series of measurements, generally over approximately 1 hr periods.

Graphing the whole hours of data does look like random noise, but 'zooming' in, the noise appears to be not actually random noise but a cyclic oscillation, possibly caused by the PLL not locking  (page 4 of this thread).
The frequency of the oscillation does appear to be very similar to that of the PLL lock drift.
The fact that the PLL doesn't actually lock has always bugged me.

I have a 49.125 clock from mouser arrived today, so I will bodge up a replacement clock board Manhattan style and see if that eliminates the variation I am seeing.
1st image is from a cold start,
2nd image after 4 or 5 hrs

[Dek]

Made up a small clock board using a Crystec clock oscillator.

Currently logging the meter as it warms up as in the first trace above filter on range 0.1 6 digits (7 displayed).
Just looking at the display, doesn't look to be much improvement.
Once the data is graphed will be able to see if it's any better and also run a range 10 7 digits log with no filtering for comparison to the second trace above.

Dek.

[Kleinstein]

The 0.1 V is usually limited by the input amplifier. So there is not much change from the clock expected. The more critical one would be the 10 V range, as this is often limited by the ADC.

AFAIR the solartron meters use a continuous integration with only very rare zero cycles. The noise can be of 2 types: one is noise that actually accumulates over time this is very low frequency noise. The second is noise in getting the comparator levels. This is higher frequency, and causing one reading to read high and the next to read low. So there would be some corelation between adjacent readings.

Noise of the 1 st type causes the noise from the average of N adjacent readings to go down with N line square root N or a little slower (if 1 /f noise it present). Noise if the 2 nd type goes down approximately like 1/N, so considerably faster. So looking at the Allan deviation (which is essentially look at the noise with different amounts of averaging) would give a hint if the noise is more the 1 st or 2 nd type.

[Dek]

Hi Kleinstein,

Well,  the new oscillator shows a different result compared to the original clock board.
This is a quick trace from the log. ( Range 0.1 6 digits filter on)
The large spikes have gone,  the oscillation error is more consistent.
I think the variation in clock frequency of the original board due to the PLL not locking, randomises the "oscillation" making the error look more like random noise which possibly it is not.

I'll run a log set on range 10 7 digits and no filter and see what that looks like.
Dek



 

[Kleinstein]

The 0.1 V range readings look a lot like some beat frequency. I see 3 frequencies that can contribute: mains frequency, the input chopper and the ADC clock. As things have changed the ADC clock should be one of them.

The filter function can also be tricky, as it can hide effects of some outliers. Unfiltered data are easier to analyze. One can always apply the filter later in the spreadsheet program if needed.

What is the x axis / time scale ? It looks like the oscillation is relatively fast.

Is there a very fast mode (more than 250 SPS) with the 7061, so one could see the actual level of 50/100 Hz hum from the input signal ?

[Dek]

The 0.1 V range readings look a lot like some beat frequency. I see 3 frequencies that can contribute: mains frequency, the input chopper and the ADC clock. As things have changed the ADC clock should be one of them.
The filter function can also be tricky, as it can hide effects of some outliers. Unfiltered data are easier to analyze. One can always apply the filter later in the spreadsheet program if needed.
What is the x axis / time scale ? It looks like the oscillation is relatively fast.
Is there a very fast mode (more than 250 SPS) with the 7061, so one could see the actual level of 50/100 Hz hum from the input signal ?

Hello Kleinstein,
Thank you for your reply.
X axis is about 1 sample per sec - I'll check exactly later.
Looking at the trace today, there are some other repeatable artifacts in the sine wave i.e the small reversal about 2/3 up/down the sine wave.
Maybe or maybe not this is significant.

I'll run a Range10 7 digits no filter log shortly and also look at the fast burst mode to see if that germinates another clue.

Dek



 

[Dek]

Run for about 1 hr.
1 sample / 2 sec
Range 10
7 digits
No filter.
Will now try the burst / fast mode.

[grizewald]

Nice to see you still working on this Dek. I've been working like a madman since I was last here, hence my silence.

I just finished bringing my 7151 back to life - well sort of. In the end, I had to come to the conclusion that the analogue board probably has a dead 68P01 microprocessor. First I found that the transistor that drives the -RESET line to the processor from the watchdog circuit had turned into a 300 ohm resistor, then I found that the EPROM which sits on top of the processor was blank and couldn't be re-programmed either. Even after finally getting a new 2764 to give the processor a program to run, it didn't help. The analog board just sits there turning various relays on and off.

Then I noticed that the analogue board is identical in the 7150+ and the 7151, so I took the analogue board from the 7150+, put the 7151 EPROM in there and got a working 7151 for my efforts with the 7150+ relegated to the position of parts mule.

The reason why I mention this is the interesting difference when it come to how Solartron implemented the drift correct feature in the 7151. On our 7061 meters, a drift correct is performed once every 15 minutes. On the 7151, it is either performed every 10 seconds, or before every reading when in 6x9 mode. Despite that, the meter's readings will regularly cycle through about +/- 60μV in either direction but at times will remain stable for several minutes.

I also received my ESR tester and had to replace a bunch of electrolytic capacitors on the 7151, so I'm about to dismantle to 7061 and do the same thing. I'm hoping to find some which need replacing and that doing that might bring a little more stability to my 7061.

Your last graph seems to show the same behaviour as I see on mine, plenty of random noise plus significant changes on each drift correction. We obviously bought the same part at Mouser as I also have a Crystek 49.152MHz oscillator ready to replace the PLL controlled clock. It looks like it made a difference for your meter so I'll get mine built and see what effect it has on mine.
 

[Kleinstein]

The noise is really quite high, even for the Solatron design that is not really low noise. It looks like both "high frequency" noise going up and down fast, like an error for the comparators and also some low frequency noise, a little like popcorn noise.
The quite regular up and down from the 0.1 V rangs is no longer there, at least not much. So this is more like a thing of the input amplifier, and not of the ADC itself. Even with not so perfect frequency match it is not likely to have so much hum to cause the regular signal for the 0.1 V range. The very good 50 Hz suppression due to the PLL is more a thing if the signal to measure contains quite a lot of hum.

Not having decoupling at the ICL7650 is suspicious. Like with other slow OPs there could be ripple from the -15 V side coming through and cause some trouble (not just noise, but also INL errors).

[Dek]

Hello Grizwald,
Glad to see you back, beginning to worry the plague had bitten you :-)

I was looking for a 7150+ before I bought the 7061, nice little meters for not much money. Still looking for a clean one at a reasonable price.

The 49.152 oscillator works quite well. The outout was about 7v Pk-Pk so I've added a divider to lower this a bit - The frequency drops  to about 49.15189mhz with the main cover on, the PCB is too high to get the clock enclosure lid on at the moment.

I'm attempting the test Kleinstein suggested which is the burst measurement. I have set up the meter to do this on pressing the trigger button and the readings can be see in memory- Hist.
Burst measurement although about 1000 sps it is only in 4 digit mode.
You can also set up the sample mode and select say 5 digit mode, this will take 100 readings in about 2 seconds which might provide a more usable resolution.

I'm now trying to configure the GIPI adaptor to upload the readings from memory automatically so they can be fed into excell
The DUmp command only returns 1 result, where it should dump all for the readings in memory.
I'm having a fiddle about to see if I can get the memory to automatically upload to PuttY, then set up a macro in the GPIB controller to do the same.

I've also a LTC1052 to swap over to see if that helps with the variation we're seeing.

Dek.

[grizewald]

I attached a small 3.7v lippo via a 330 resistor to power the EAROM while the main battery was taken out.

Totally not needed. The EAROMs are early versions of what we now call flash memory. They keep their contents without power.

[grizewald]

The noise is really quite high, even for the Solatron design that is not really low noise. It looks like both "high frequency" noise going up and down fast, like an error for the comparators and also some low frequency noise, a little like popcorn noise.

True, Dek's noise is an order of magnitude more than mine, so there's still something basic wrong.
...

Not having decoupling at the ICL7650 is suspicious. Like with other slow OPs there could be ripple from the -15 V side coming through and cause some trouble (not just noise, but also INL errors).

The thing is, the original design does not have any added decoupling for the ICL7650. If that actually is a problem, then the meter would have had these noise issues when new. Logical deduction says that can't be the case.
The PCB layout is such that the ICL7650 is right next to the smoothing capacitors from the +/- 15V rails. So I'd say the designers realised that there was no need for extra decoupling.



(The ICL7650 is the LTC1052 in my case.)

[Kleinstein]

I've also a LTC1052 to swap over to see if that helps with the variation we're seeing.

Dek.

Exchanging the ICL7650 could have an effect: The ICL7650 uses an internal chopping frequency somewhere in the 500 Hz range. With some bad much this may interfere with the forcing frequency in someway, that is in a comparable range. So even if perfectly OK some of the AZ OPs may not like the environment, if they happen  to use an odd frequency.

With only 4 or 5 digit resolution the fast modes may not be sensitive enough to see hum, at least not very good. One may be able to use a 2nd meter to check for hum - still not so easy, as hum can come via so many paths and also effects other meters / scopes.