Solartron7061

[Dek]

Hi Grize,

Thanks for checking the filament drive on your meter. Glad mine also appears to be OK.

So, next step put in the new ICs and hope for the best   

Dek.

[grizewald]

Good luck!

[Dek]

Extraction of the two logic IC went OK, snipped the legs as suggested.
I don't possess a desolder gun so heated the individual pad with soldering iron, then with a tiny nozzle on the hot air gun, carefully blown out the solder. Quick, minimum heat  - works well.

Still no 74F138, hopefully will drop through the letterbox tomorrow.
Wondering if best to put in some turned pin DIL sockets or solder ICs direct to the pcb as per original? What do you think.

Dek.

[grizewald]

That's a nice clean job! It really is so much kinder to the PCB to do it this way.

There's absolutely no harm in using quality turned pin sockets. If they're good enough for the microprocessor, they're also good enough for the glue logic around it.

[grizewald]

On the subject of solder removal, I have one of these:



While I'd love a Pace desoldering station (I used to use one at my job fixing minicomputers several decades ago), I just can't justify the price. The tool pictured is called an S-993A and it works very well. The tips are quite expensive and not the best quality in the world, but the smallest tip has a 1mm hole and clears holes on sensitive PCBs very nicely. It's always a better option than a spring loaded solder sucker. The recoil on those is guaranteed to rip the pad and track clean off the board if it hits the PCB when you press the button.

[Dek]

I'll have to treat myself to a desolder gun :-)

Postman came, postman went - no 138s 
I have 74ls138, but with the gate delay being 3x the f type, I don't recon it will "cut the mustard"

I'll go and find something else to break and wait for the next post on Monday

Dek.

[grizewald]

I'll go and find something else I can break and wait for the next post on Monday

Dek.

Careful with that axe, Eugene

 

[Dek]

The 74F138 arrived and the dog didn't shred the packet....good omen I think.

Popped the 138 into its socket having installed the other ICs over the weekend.
Prayed to the magic smoke gods (several times).
Turned on the meter and YES powered up with the usual Glug Death, which disappeared after a few seconds.

Now does the meter actually 'meter' anything -
2aa batteries - check-  agrees with my Fluke 187 looking good
Quick check on the Dekerbox and looks good.

So it appears that I'm back to where I was about a week ago 

One thing I was going to look at before the 36v disaster, was when the meter is set to DCv and nothing connected, the reading floats up to between 2v and 4v. The display immediately reads zero when the ip lead is shorted. Is this normal behaviour?

When connected to my 2aa batter pack, reading varies between (approx) 3.18736 and 3.18750. Is this to be expected.

Considering what happened I've had a lucky escape.

Dek.

[Kleinstein]

With the input set to hight Z (not 10 M) it is normal that the open input drifts at some speed. This can be used to estimate the input bias. The rate is given by input bias divided by input capacitance. If needed one could add more capacitance if one can not get the actual capacitance from a schematics or similar.  Where the input settles depends and is not very significant and eve of it drifts all the way to overload this can be OK.  Ideally one would check the drift rate with a few starting points (e.g. +-10 V, +- 3 V, 0 ).

Some 3.2 V for 2 new alkaline cells is about right. The comparison with the Fuke meter is more important that just the number , it can change a little between brands and with temperature and age.

[grizewald]

The 74F138 arrived and the dog didn't shred the packet....good omen I think.

Popped the 138 into its socket having installed the other ICs over the weekend.
Prayed to the magic smoke gods (several times).
Turned on the meter and YES powered up with the usual Glug Death, which disappeared after a few seconds.

Congratulations! 

One thing I was going to look at before the 36v disaster, was when the meter is set to DCv and nothing connected, the reading floats up to between 2v and 4v. The display immediately reads zero when the ip lead is shorted. Is this normal behaviour?

Perfectly normal.

When connected to my 2aa batter pack, reading varies between (approx) 3.18736 and 3.18750. Is this to be expected.

It sounds like a lot of variation for a battery pack and may be connected to your Glug Death problem. I'd do the same test on mine, but there's an HP 34401A sitting on top of it running a 24 hour log of a reference at the moment and I don't want to turn the 7061 on as the heat will mess up the readings from the HP.

I'm a bit short on bench space!

These meters are rather noisy, but 140μV seems kind of excessive. I'll see what mine does when my logging is finished.

[Dek]

Hi Klein and Grize,

Thanks, I am very relieved that the meter has come back from the dead !

My cobbled connection using just grabber leads temporally stuffed in the front socket might be adding to the noise.
I have some pogo pins on order to make up a 'proper' connector which I will build into a shielded lead and modified binder plug shown below.
I'll also graph the history readings so it will be more meaningful to review.

Thanks again for your help so far 

Dek.

 

[Dek]

Quick graph of the meter after its been warmed up for about 3 hrs.


I'll have to have a go at running a program to check min/max SD etc. (RTFM first though!)

Dek.

[grizewald]

That looks a lot more reasonable!

If you do your plotting with gnuplot, it will work out min, max, SD, variance, median, mean and all that stuff for you. Not to mention that so will your meter if you select the statistics program, but it's much more fun to graph things and much better at showing hidden features of the collected data.



This is from the log that's running on the HP meter at the moment.

[Dek]

I manually bashed the history figures into Excel - got fed up at 200
Ran the stats prog for about 5 mins.
N 1497
Mean 3.186598
SD 6.649784E-5
Var 4.421963E-9

I'll have to order a replacement GPIB controller IC and try gnuplot.

 

[grizewald]

There's a great little project here on EEVBlog that will turn an Arduino board into a USB-GPIB interface if you do get that replacement GPIB chip. See: https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

It works just as well on my 7061 as it does on the 34401A.

[Dek]

There's a great little project here on EEVBlog that will turn an Arduino board into a USB-GPIB interface if you do get that replacement GPIB chip. See: https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/
It works just as well on my 7061 as it does on the 34401A.

Looks like a useful project so I've ordered a GPIB connector and an Uno.
Now back to tracing the Glug Death fault.
I'll check that there isn't a power supply rail or one of the clock signals that's being lazy on start up. Or possibly the 1.5khz clear signal to IC315 isn't being 'slow' .
etc (trying not to blow it up again    )
It appears to be only a problem for on power on- If I reset the meter, it will self test and initialise OK.

Dek 

[Dek]

Been looking at the clock output form PCB 8,  not happy with what I'm seeing.

Looking at TP101, the clock signal is an approximate sinewave and I'm assuming this should be a 5v square feeding the hex inverter IC 430.


Whats more strange, the output of the inverted is not a square wave, nearer a sine, in fact so are several of the other inverter outputs. (wonder if I'm missing something here - scope ground was to the IC 0V


The clock is very unstable, ranging approximately 49.1084 to 49.155.
I've checked this with a frequency counter and it agrees 


Bit of a think needed.
<edit> looking at this ! https://www.eevblog.com/forum/metrology/solartron-7061-and-thermal-noise/25/

[Kleinstein]

The frequency is quite high. So it is normal not to have a nice square wave any more. Loading by the scope probe and the way the ground is connected can also effect the picture.

The signal after the inverters may look a little better, but even these are not that much faster. There is also a good point to have a more sine like clock: it is causing less RF emissions.

The larger problem is likely the not so stable frequency. This could be the PLL not locked. So how does the voltage at the VCO control input look like. This can be tricky to probe in some cases if it is high impedance and can thus pic up noise.

[coromonadalix]

what probes do you have ?  are they x10 or x100 ??  it may affect your signal quality ? as kleinstein wrote

[grizewald]

Been looking at the clock output form PCB 8,  not happy with what I'm seeing.

Looking at TP101, the clock signal is an approximate sinewave and I'm assuming this should be a 5v square feeding the hex inverter IC 430.

Now my very busy working week is over, I got some time to come here and catch up. 

As others have said, it may simply be your 'scope making it look like that, but I'll have a probe of mine after dinner and post some screen captures. The raw clock output and the control inputs are kind of sensitive to being probed.

When I was looking at the clock on mine, I found that the very simple setup instructions in the manual of 'adjust L401 on PCB8 until TP402 reads 3.0V +/- 0.2V' to be woefully inadequate. For a start, you can't probe TP402, even with a X10 probe and expect the PLL to lock as the probe steals enough current to stop the PLL from locking. Instead, I removed PCB8, powered it from one of my bench supplies and then used a counter, with its timebase derived from a GPSDO to adjust the free running frequency of the oscillator to as close to 49.152MHz as I could get. That ensures that the frequency should be in the range that the PLL should be able to achieve a lock with.

I discovered how sensitive the clock control at TP402 was when I was trying to monitor TP403 and TP404 (the 50Hz from the mains and the 50Hz created by dividing down the 49.152MHz clock) while also monitoring TP402. The PLL never even got close to locking. When I removed the probe from TP402, it got much closer to a lock, but never actually achieved a stable lock. I'm guessing that either the varicap on PCB 8 or one of the other components is a bit 'tired'.

If you probe just TP403 and TP404, you can see if the PLL ever does achieve a lock. On mine, the leading edges of the signals cross slowly back and forth, but never actually align and stay there. It's almost as if the time constant for the PLL is wrong.

Oddly, when you look at the circuit diagram of the optional crystal oscillator, it doesn't even use the control signal from the PLL, which makes me wonder how important the lock to the mains frequency actually is. I tried feeding in a reasonably accurate 49.152MHz from a signal generator with PCB8 removed, but it did nothing to improve the approximately +/- 12μV of noise that I see on my 7061 when measuring on the 10V DC range with the inputs shorted.

Earlier this week, I had an order from Mouser arrive and part of that order was some 49.152MHz crystals, so I'll be making up an oscillator board that I can try as a replacement for PCB8. It won't be locked to the mains, but it should at least be fairly stable.

[Kleinstein]

How important the frequency lock to mains is depends on the signal measured. If everything inside the meter is fine an not much internal hum, there can still be hum from the signal to measure. With a short there should be essentially no hum and thus low importance of the PLL lock. The same is true for good quality reference with cables that don't pick up much hum.  Especially something like an AC measurement may pick up quite some hum and thus be more sensitive to the PLL lock.

For a test one could check with an intentional 50 Hz signal to see how good this is suppressed to get an idea.
With just a fixed clock and no PLL there may be a slow beat frequency visible.

Especially a passive PLL filter can be very sensitive, so the measurement could effect the PLL to much. This can be DC loading and AC coupling of some mains hum.

Adjusting the PLL to a give frequency is probably OK, provided the control voltage is at a defined state (e.g. mid range).
The PLL lock does not have to be in phase, a constant phase shift can be acceptable (depends on the detector and filter).
For the PLL it would be nice to have some lock indication.

Edit: A fixed frequency should not be such a big problem. With my ADC I use a fixed frequency and not even well matched length. The noise is still very low (e.g. < 1 µV).

[Dek]

Hello Klein, Coro and Grize,

Yes, looks like you are correct, my setup (100mhz scope cheapo x10 probes) appears to be distorting the clock signal due to its limitations, so at least nothing appears to be seriously wrong there.
I've rechecked this with a 200mhz scope x10 probes (supposedly 350mhz) and with slightly better results, but the clock frequency is varying significantly, drifting from max to min in about 10 sec (by eye) (screen grab TP101)

Section 4.2.5 where the manual 'explains' clock adjustment, I see on my scope a 50hz  pulse that slowly varies between 1.62ms and 1.17ms
(TP402 WRT TP508)
I was expecting to see a DC voltage here, so somewhat confused.
Dek.


Checking TP403 and 404, I see that there are not precisely locked. Persistence set to infinite, shows the drift of TP404 wrt triggered TP403.

[branadic]

Yes, looks like you are correct, my setup (100mhz scope cheapo x10 probes) appears to be distorting the clock signal due to its limitations, so at least nothing appears to be seriously wrong there.

You can't expect to see a 50MHz square wave signal with a 100MHz scope. It needs >250MHz at least to get something that barely looks like a square wave.

-branadic-

[grizewald]

They look more locked than mine! I'll grab a shot of how (not) well locked my clock is next.

First up is TP101 (yellow trace) vs IC430 pin 6.



You could almost be forgiven for thinking that the inverter isn't actually inverting. Then again, the clock period is just over 20ns and the propagation delay of the inverter is around 4ns, so actually, the output of the inverter is going low just as the clock signal rises past the logic 1 threshold.

On the clock control signal from the PLL chip at TP402, what you will see is the signal go positive when the clock's leading edge comes after the 50Hz leading edge, when the clock leading edge comes before the 50Hz, the control signal goes negative and when both edges are simultaneous, the control output goes tristate.

[grizewald]

Here's the PLL on mine having a hard time.

Ch1 is the 50Hz mains reference
Ch2 is the comparison 50Hz divided down from the clock
Ch3 is the clock control output from the PLL



The rising edge of the comparison clock is after the rising edge of the 50Hz mains. Therefore the clock control output goes high in an attempt to pull the clock back to match the 50Hz rising edge. The only problem is, with a 10X probe on the control output, it can't pull the edge back far enough.

So I disconnect my probe from TP402 and a second or so later, the phases lock.



So maybe I was not remembering my last testing properly as it appears that I do now have a locked PLL as long as I don't try robbing the varicap of electrons to observe the control signal.

If this doesn't happen for you, it may be a good idea to try my way of setting the frequency of the oscillator outside of the meter and then see what happens when you put it back in. It's incredibly frustrating trying to set it to exactly 49.152MHz though as the adjustment slug is very sensitive. Obviously, you can only adjust the slug with a plastic tool, but even then, you'll think you've got it set perfectly and then when you take the plastic screwdriver out of the slot in the slug, the frequency will hop up 5KHz.