On Saturday, 4/15/2017 1:15 PM, John Robertson wrote:

> 
> As an example - Common/Ground designs in early arcade games were not 
> always at their best. A number of early electronic pinball games used to 
> burn up driver transistors and coils at random until I traced the 
> problem - which was  a design error where all the commons (MPU, Audio, 
> Solenoids, Lamps) came together at the regulator board through several 
> different pins, and as each pin connection oxidized slightly it allowed 
> ground potential differences between the MPU and the solenoid logic 
> grounds, leading to the transistors being slightly biased on...
> And this game logic had been designed by Rockwell.
> 
> John

This sort of poor design is common in consumer electronics.  Likely
the engineer wanted more or better ground connections, but got shot
down due to increased cost of connectors with either more pins or
better plating (silver or gold).  As long as the oxidation issue
happens _after_ the warranty period expires, there's no incentive
to correct the design, either.

-- 
Gabor

On Saturday, April 15, 2017 at 7:26:52 AM UTC-7, Neon John wrote:
> You are correct.  The production part is designed in Eagle but since
> Autocad destroyed Eagle, I quickly replicated the design in KiCAD. Too
> fast, it seems.
> 

Yeah, you have a lot of company in that particular boat. :(

-- john, KE5FX

On 2017/04/15 9:37 AM, rickman wrote:
> On 4/15/2017 12:21 PM, John Robertson wrote:
>> On 2017/04/11 7:26 PM, John Larkin wrote:
>>> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>>>
>>>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>>>> <jjlarkin@highlandtechnology.com> wrote:
>>>>
>>>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>>>
>>>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>>>
>>>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>>>
>>>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and
>>>>>>> vary
>>>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>>>
>>>>>> Why not?  Don't bother with the output frequency, just vary the
>>>>>> number
>>>>>> of flops wiggling.
>>>>>
>>>>> That would work too. Maybe have a 2-bit heat control word, to get
>>>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>>>> single on-off bit could be a simple bang-bang thermostat.
>>>>>
>>>>> The PLL thing would be elegant, proportional control of all the flops
>>>>> in the distributed heater array.
>>>>
>>>> You can do the same thing with the flops.  Use a shift register to
>>>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>>>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>>>> left...
>>>>
>>>> There are all sorts of algorithms  that can be built into spare flops.
>>>>>
>>>>> I'm thinking we could reduce the overall effect of ambient temp
>>>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>>>
>>>> Seems reasonable.  IBM used to add heater chips for the same purpose
>>>> (bipolar circuits run faster at high temperature).
>>>
>>> CMOS is slower at high temps. Somewhere between about 1000 and 3000
>>> PPM/K prop delay.
>>>
>>
>> Do you use that property of CMOS (slower the warmer it gets) as an
>> automatic negative feedback loop for your heater?
>
> That would likely not work nearly as well as directly measuring the
> temperature of the die.  Notice he said the chip has a built in
> thermometer.  The only issue with using the thermometer is the
> temperature across the die will vary.  Using the delay to control the
> heater might work well in concept, but would be hard to measure and
> still only work for the output being measured.  Any other outputs will
> be spread around the die and so not isothermal.  But mostly the timing
> would be hard to measure.
>
> He has an oven/refrigerator.  He could measure the change in timing over
> temperature for some number of samples.  This would give him an idea of
> how much spread is involved.  There are multiple sources of timing
> spread and he can control one and sort of control another.  He wants an
> idea of how much timing spread is left.
>

Thanks for the explanation. I am not a qualified board designer, just a 
bit of a hacker designing and making the few I need for my restoration 
business. It is nice to get the background of design considerations as I 
find that information useful in determining where designs have gone 
wrong in our equipment and try to make improvements to the systems.

As an example - Common/Ground designs in early arcade games were not 
always at their best. A number of early electronic pinball games used to 
burn up driver transistors and coils at random until I traced the 
problem - which was  a design error where all the commons (MPU, Audio, 
Solenoids, Lamps) came together at the regulator board through several 
different pins, and as each pin connection oxidized slightly it allowed 
ground potential differences between the MPU and the solenoid logic 
grounds, leading to the transistors being slightly biased on...
And this game logic had been designed by Rockwell.

John

On 4/15/2017 12:21 PM, John Robertson wrote:
> On 2017/04/11 7:26 PM, John Larkin wrote:
>> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>>
>>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>>> <jjlarkin@highlandtechnology.com> wrote:
>>>
>>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>>
>>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>>
>>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>>
>>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
>>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>>
>>>>> Why not?  Don't bother with the output frequency, just vary the number
>>>>> of flops wiggling.
>>>>
>>>> That would work too. Maybe have a 2-bit heat control word, to get
>>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>>> single on-off bit could be a simple bang-bang thermostat.
>>>>
>>>> The PLL thing would be elegant, proportional control of all the flops
>>>> in the distributed heater array.
>>>
>>> You can do the same thing with the flops.  Use a shift register to
>>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>>> left...
>>>
>>> There are all sorts of algorithms  that can be built into spare flops.
>>>>
>>>> I'm thinking we could reduce the overall effect of ambient temp
>>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>>
>>> Seems reasonable.  IBM used to add heater chips for the same purpose
>>> (bipolar circuits run faster at high temperature).
>>
>> CMOS is slower at high temps. Somewhere between about 1000 and 3000
>> PPM/K prop delay.
>>
>
> Do you use that property of CMOS (slower the warmer it gets) as an
> automatic negative feedback loop for your heater?

That would likely not work nearly as well as directly measuring the 
temperature of the die.  Notice he said the chip has a built in 
thermometer.  The only issue with using the thermometer is the 
temperature across the die will vary.  Using the delay to control the 
heater might work well in concept, but would be hard to measure and 
still only work for the output being measured.  Any other outputs will 
be spread around the die and so not isothermal.  But mostly the timing 
would be hard to measure.

He has an oven/refrigerator.  He could measure the change in timing over 
temperature for some number of samples.  This would give him an idea of 
how much spread is involved.  There are multiple sources of timing 
spread and he can control one and sort of control another.  He wants an 
idea of how much timing spread is left.

-- 

Rick C

On 2017/04/11 7:26 PM, John Larkin wrote:
> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote:
>
>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin
>> <jjlarkin@highlandtechnology.com> wrote:
>>
>>> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>>>
>>>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>>>> <jjlarkin@highland_snip_technology.com> wrote:
>>>>
>>>>> We have a ZYNQ whose predicted timing isn't meeting decent margins.
>>>>> And we don't want a lot of output pin timing variation in real life.
>>>>>
>>>>> We can measure the chip temperature with the XADC thing. So, why not
>>>>> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
>>>>> the PLL output frequency to keep the chip temp roughly constant.
>>>>
>>>> Why not?  Don't bother with the output frequency, just vary the number
>>>> of flops wiggling.
>>>
>>> That would work too. Maybe have a 2-bit heat control word, to get
>>> coarse steps of power dissipation, 4 groups of flops. I suppose a
>>> single on-off bit could be a simple bang-bang thermostat.
>>>
>>> The PLL thing would be elegant, proportional control of all the flops
>>> in the distributed heater array.
>>
>> You can do the same thing with the flops.  Use a shift register to
>> enable flops in a "thermometer code" sort of thing.  Too low - shift
>> right.  Wait.  Still to low - shift right.  Wait.  Too high - shift
>> left...
>>
>> There are all sorts of algorithms  that can be built into spare flops.
>>>
>>> I'm thinking we could reduce the overall effect of ambient temp
>>> changes by some healthy factor, 4:1 or 10:1 or something.
>>
>> Seems reasonable.  IBM used to add heater chips for the same purpose
>> (bipolar circuits run faster at high temperature).
>
> CMOS is slower at high temps. Somewhere between about 1000 and 3000
> PPM/K prop delay.
>

Do you use that property of CMOS (slower the warmer it gets) as an 
automatic negative feedback loop for your heater?

John

On Sat, 15 Apr 2017 10:23:42 -0400, Neon John <no@never.com> wrote:

>On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin
><jjlarkin@highland_snip_technology.com> wrote:
>
>
>>The LM35 is supposedly not c-load stable, but most things are c-load
>>stable with enough c.
>>
>>It is a kinda tricky part.
>
>It is in this design.  There are several hundred of these boards in
>service in our products.  I added the cap because the processor was
>picking up lots of RFI from the intense RF field inside the induction
>heater.
>
>John
>John DeArmond
>http://www.neon-john.com
>http://www.tnduction.com 
>Tellico Plains, Occupied TN
>See website for email address

LM35 output is an emitter follower with a weak pulldown. An ideal RF
detector.

And it latches up if it possibly can.

LM71, SPI interface, is a nice part.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics

On Fri, 14 Apr 2017 15:56:43 -0700 (PDT), "John Miles, KE5FX"
<jmiles@gmail.com> wrote:

>On Friday, April 14, 2017 at 8:48:05 AM UTC-7, Neon John wrote:
>> Complicated.  Here's my simple controller.
>
>I'm not sure I get how this works.  Should D1 and L2 be swapped?
>
>-- john, KE5FX

You are correct.  The production part is designed in Eagle but since
Autocad destroyed Eagle, I quickly replicated the design in KiCAD. Too
fast, it seems.

Sorry about that.

John
John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address

On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin
<jjlarkin@highland_snip_technology.com> wrote:

>The LM35 is supposedly not c-load stable, but most things are c-load
>stable with enough c.
>
>It is a kinda tricky part.

It is in this design.  There are several hundred of these boards in
service in our products.  I added the cap because the processor was
picking up lots of RFI from the intense RF field inside the induction
heater.

John
John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address

On 14 Apr 2017 10:07:41 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:

> Thanks John, that is pretty simple.  Of course the processor
> requires a program, but if you put it up, that's good.  And
> include the controller code-burning instructions.

I'll put up the code and instructions on programming.  I used Atmel's
Studio development environment (unfortunately based on Microsoft
Studio) for development (use GNU-C suite backend) and use AVRDUDE in a
command script to program in production.

The genuine Atmel programmer is about $35 from Digikey et al but there
are plenty of articles on the web about how to build $5 programmers. I
notice that AVRDUDE even has a model based on a parallel port. Check
out http://www.avrfreaks.com.

John

John DeArmond
http://www.neon-john.com
http://www.tnduction.com 
Tellico Plains, Occupied TN
See website for email address