[John Larkin]

This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?

John

[John Larkin]

On Sat, 20 Oct 2007 18:36:04 -0700, ChairmanOfTheBored
wrote:

On Sat, 20 Oct 2007 14:04:48 -0700, John Larkin
wrote:


I noticed a few process indicators to mention to your PCB maker's QA
folks. Not the contract makers the assembled the unit (or you guys if it
was your folks), the PCB itself.

The stains under the dip package location are indicative of mask
delamination or poor adhesion of it. A condition known as "haloing".

I think that's just the lighting. The board looks OK to me.



Change the resistor packs to the next form factor size up perhaps.

Yeah, we should stop using these things.



They must be on the bottom of the assembly as I don't see them
anywhere.

R34 on top, near the two big blue inductors, is one. There are several
more on the bottom, near the uP. These things just don't solder well.
The other part we have trouble with is the US8 packages, the ones on
the bottom with red epoxy holding them on. Hard to solder, hard to
inslect, a real SOB to replace.


Nice layout, John.

Thanks.

John

[Spehro Pefhany]

On Sat, 20 Oct 2007 20:36:10 -0700, the renowned John Larkin
wrote:

On Sat, 20 Oct 2007 18:36:04 -0700, ChairmanOfTheBored
wrote:

On Sat, 20 Oct 2007 14:04:48 -0700, John Larkin
wrote:


I noticed a few process indicators to mention to your PCB maker's QA
folks. Not the contract makers the assembled the unit (or you guys if it
was your folks), the PCB itself.

The stains under the dip package location are indicative of mask
delamination or poor adhesion of it. A condition known as "haloing".

I think that's just the lighting. The board looks OK to me.



Change the resistor packs to the next form factor size up perhaps.

Yeah, we should stop using these things.

There are two edge forms, one is a bit more expensive and solders a
bit better IME. My most recent tiny board (1.75 x 2.9") has 10 of them
(0603x4) which is a lot nicer than 38 discrete 0603 or 0402 resistors.


They must be on the bottom of the assembly as I don't see them
anywhere.

R34 on top, near the two big blue inductors, is one. There are several
more on the bottom, near the uP. These things just don't solder well.
The other part we have trouble with is the US8 packages, the ones on
the bottom with red epoxy holding them on. Hard to solder, hard to
inslect, a real SOB to replace.


Nice layout, John.

Thanks.

John


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

[John Larkin]

On Sun, 21 Oct 2007 07:15:54 -0500, Spehro Pefhany
wrote:

On Sat, 20 Oct 2007 20:36:10 -0700, the renowned John Larkin
wrote:

On Sat, 20 Oct 2007 18:36:04 -0700, ChairmanOfTheBored
wrote:

On Sat, 20 Oct 2007 14:04:48 -0700, John Larkin
wrote:


I noticed a few process indicators to mention to your PCB maker's QA
folks. Not the contract makers the assembled the unit (or you guys if it
was your folks), the PCB itself.

The stains under the dip package location are indicative of mask
delamination or poor adhesion of it. A condition known as "haloing".

I think that's just the lighting. The board looks OK to me.



Change the resistor packs to the next form factor size up perhaps.

Yeah, we should stop using these things.

There are two edge forms, one is a bit more expensive and solders a
bit better IME. My most recent tiny board (1.75 x 2.9") has 10 of them
(0603x4) which is a lot nicer than 38 discrete 0603 or 0402 resistors.


Got any part numbers or links? It would be worth switching.

And the US8's seem to be getting worse. ROHS plating maybe?

John

[John Larkin]

On Sun, 21 Oct 2007 12:55:23 -0700, ChairmanOfTheBored
wrote:

On Sun, 21 Oct 2007 11:37:39 -0700, John Larkin
wrote:

On Sun, 21 Oct 2007 07:15:54 -0500, Spehro Pefhany
wrote:

On Sat, 20 Oct 2007 20:36:10 -0700, the renowned John Larkin
wrote:

On Sat, 20 Oct 2007 18:36:04 -0700, ChairmanOfTheBored
wrote:

On Sat, 20 Oct 2007 14:04:48 -0700, John Larkin
wrote:


I noticed a few process indicators to mention to your PCB maker's QA
folks. Not the contract makers the assembled the unit (or you guys if it
was your folks), the PCB itself.

The stains under the dip package location are indicative of mask
delamination or poor adhesion of it. A condition known as "haloing".

I think that's just the lighting. The board looks OK to me.



Change the resistor packs to the next form factor size up perhaps.

Yeah, we should stop using these things.

There are two edge forms, one is a bit more expensive and solders a
bit better IME. My most recent tiny board (1.75 x 2.9") has 10 of them
(0603x4) which is a lot nicer than 38 discrete 0603 or 0402 resistors.


Got any part numbers or links? It would be worth switching.

And the US8's seem to be getting worse. ROHS plating maybe?

John

It appeared as if you are still using lead alloy processes to me.

Yup, nice shiny joints!


But yeah, vendors going RoHS on terminations can be a pain in the ass.
Being mil, we are exempt, HOWEVER, some vendors have done the RoHS up
your ass screw over on MIL parts that were not supposed to have it done
to them, so we end up having to send some parts out to be re-plated. Talk
about taking a hit on reliability, and cost!

My brother-in-law is pretty high up in Textron. He tells me they're
spending big bux to send ROHS parts out to be retinned with real
solder.

John

[Tom Del Rosso]

"ChairmanOfTheBored" wrote in message


As far as I can tell, mil parts don't get the in depth scrutiny in
the manufacturing process they used to get anyway.

Nuclear weapon handling procedures aren't getting as much scrutiny either.


--

Reply in group, but if emailing add another
zero, and remove the last word.

[Tom Del Rosso]

"John Larkin" wrote in
message news
This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?

That may be the first DIP socket I've seen on one of your boards.


--

Reply in group, but if emailing add another
zero, and remove the last word.

[John Larkin]

On Sun, 21 Oct 2007 23:36:12 -0400, "Tom Del Rosso"
wrote:

"John Larkin" wrote in
message news
This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?

That may be the first DIP socket I've seen on one of your boards.

That's for the eprom. It holds the uP code and the fpga configuration.
I like using plugin eproms, because if we change anything, we can send
the customer a new chip and he can just plug it in. If we use flash,
field upgrading is a lot trickier and riskier.

The two extra pins are for debugging. One is the microprocessor \WRITE
line, and one is +3.3 volts. When we test code, we plug in a little
ram board instead of the eprom, and load it through the bdm port, the
little 10-pin header.

Of course, they are otp eproms, sort of an oxymoron, but that's what
most people call them.

John

[Joerg]

John Larkin wrote:
On Sun, 21 Oct 2007 23:36:12 -0400, "Tom Del Rosso"
wrote:

"John Larkin" wrote in
message news
This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?
That may be the first DIP socket I've seen on one of your boards.

That's for the eprom. It holds the uP code and the fpga configuration.
I like using plugin eproms, because if we change anything, we can send
the customer a new chip and he can just plug it in. If we use flash,
field upgrading is a lot trickier and riskier.


Yep, keep it simple. Lawrence just shared a hilarious link in an older
s.e.d. thread and the story is much closer to today's EE life than I
wish it was:

http://www.thalia.org/humdec97.html

I almost spilled my morning coffee ...


The two extra pins are for debugging. One is the microprocessor \WRITE
line, and one is +3.3 volts. When we test code, we plug in a little
ram board instead of the eprom, and load it through the bdm port, the
little 10-pin header.

Of course, they are otp eproms, sort of an oxymoron, but that's what
most people call them.


--
Regards, Joerg

http://www.analogconsultants.com/

[John Larkin]

On Mon, 22 Oct 2007 07:54:43 -0700, Joerg
wrote:

John Larkin wrote:
On Sun, 21 Oct 2007 23:36:12 -0400, "Tom Del Rosso"
wrote:

"John Larkin" wrote in
message news This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?
That may be the first DIP socket I've seen on one of your boards.

That's for the eprom. It holds the uP code and the fpga configuration.
I like using plugin eproms, because if we change anything, we can send
the customer a new chip and he can just plug it in. If we use flash,
field upgrading is a lot trickier and riskier.


Yep, keep it simple. Lawrence just shared a hilarious link in an older
s.e.d. thread and the story is much closer to today's EE life than I
wish it was:

http://www.thalia.org/humdec97.html

I almost spilled my morning coffee ...


As soon as anybody doing an embedded system says "let's use Java",
fire them.

John

[John Larkin]

On Sun, 21 Oct 2007 22:46:18 -0700, ChairmanOfTheBored
wrote:

On Sun, 21 Oct 2007 23:36:12 -0400, "Tom Del Rosso"
wrote:

"John Larkin" wrote in
message news
This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?

That may be the first DIP socket I've seen on one of your boards.


Keeps firmware "quick and dirty". No frills required.

Well, I'd have preferred "quick and clean." We did one box that was
flash based, field upgradable, and it added a lot of hassle, both in
the design and in walking customers through upgrades.

The last two pieces of test geat I bought (Keithley 2100 DVM, Aeroflex
spectrum analyzer) both were shipped with pretty serious bugs,
probably on the theory that, hell, it's flash, let's ship now and we
can always upgrade them later. I've convinced both vendors that they
actually have bugs, and am waiting for fixes. If I ever get them, I'll
have to reflash the instruments somehow, and hope it works.

The Aeroflex is designed and made in Korea, and Keithley refuses to
answer my question about whether they designed the DVM; they certainly
didn't manufacture it.

John

[Joerg]

John Larkin wrote:
On Mon, 22 Oct 2007 07:54:43 -0700, Joerg
wrote:

John Larkin wrote:
On Sun, 21 Oct 2007 23:36:12 -0400, "Tom Del Rosso"
wrote:

"John Larkin" wrote in
message news This its the first article of a new waveform generator. It took me a
while, an hour or two, to find a stuck bit on the uP data bus; turned
out it was a bad solder joint on one of those tiny quad resistor
packages. Something about their geometry makes them hard to solder and
hard to inspect.

Seems as though the most reliable thing we solder is BGAs. Who woulda
thunk it?
That may be the first DIP socket I've seen on one of your boards.
That's for the eprom. It holds the uP code and the fpga configuration.
I like using plugin eproms, because if we change anything, we can send
the customer a new chip and he can just plug it in. If we use flash,
field upgrading is a lot trickier and riskier.

Yep, keep it simple. Lawrence just shared a hilarious link in an older
s.e.d. thread and the story is much closer to today's EE life than I
wish it was:

http://www.thalia.org/humdec97.html

I almost spilled my morning coffee ...


As soon as anybody doing an embedded system says "let's use Java",
fire them.

John


Agreed ;-)

Same goes for .NET.

--
Regards, Joerg

http://www.analogconsultants.com/

[Michael A. Terrell]

John Larkin wrote:

As soon as anybody doing an embedded system says "let's use Java",
fire them.


Napalm, or flame thrower?

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

[Joel Koltner]

"Joerg" wrote in message
...
As soon as anybody doing an embedded system says "let's use Java",
fire them.

John

Agreed ;-)

Same goes for .NET.

You guys realize that that sort of "technology" is all over things like
Agilent and Tek scopes, network/spectrum/logic/etc. analyzers, etc. these
days, right? As soon as the marketing guys say, "This has to have a web
interface that can completely control the interface and display its screen
remotely!" while one certainly has many choices besides Java or .Net, at that
point someone who'd suggest, "Let's do it in straight C or assembly!" is the
one who ought to be fired. :-)

[Joel Koltner]

"John Larkin" wrote in message
...
Well, I'd have preferred "quick and clean." We did one box that was
flash based, field upgradable, and it added a lot of hassle, both in
the design and in walking customers through upgrades.

What was the hardware interface? We have some widgets that, by contract, have
to be field upgradeable and the way the update software works is that, once
configured properly (which we can do here before sending them the upgrade
software), you drop the device into its battery charger and -- poof! -- about
3 seconds later it's been completely re-flashed (128KB of microcontroller
code). It's all done over USB.

I'd be a little concerned about the ability of someone to successfully take
apart your box and stick in a new EPROM if they couldn't manage to run the
typical flash ROM update program without needing a lot of hand-holding...

The last two pieces of test geat I bought (Keithley 2100 DVM, Aeroflex
spectrum analyzer) both were shipped with pretty serious bugs,
probably on the theory that, hell, it's flash, let's ship now and we
can always upgrade them later.

That's the general mentality of most programmers (and their managers) these
days. There are even folks who'll try to make the business case that it's
better for a company overall to ship a product with known bugs than to delay
its release (and thus revenue) by fixing them first. Unfortunately, they're
probably right in that most people today are completely used to the
Microsoft-model of Internet-based patches/upgrades.

The Aeroflex is designed and made in Korea, and Keithley refuses to
answer my question about whether they designed the DVM; they certainly
didn't manufacture it.

I'd take a refusal to answer a question like that as an admission that they
didn't design it themselves.

---Joel

P.S. -- Remember that discussion we were having about HP-35S calculators? I
found a pretty nasty bug in how it evalutes equations sometimes... for
particular program sequences it evaluates...

-R*X/(X*Q-R)

as

-R*X/([completely different variable than X]*Q-R)

:-(

I've advised HP of this; they haven't written back up other than to
acknowledge receipt.

(Some might recognize that equation up there are having to do with L-matching
networks with a load of R+jX and a quality factor Q.)

---Joel

[Joerg]

Joel Koltner wrote:
"Joerg" wrote in message
...
As soon as anybody doing an embedded system says "let's use Java",
fire them.

John
Agreed ;-)

Same goes for .NET.

You guys realize that that sort of "technology" is all over things like
Agilent and Tek scopes, network/spectrum/logic/etc. analyzers, etc. these
days, right? As soon as the marketing guys say, "This has to have a web
interface that can completely control the interface and display its screen
remotely!" while one certainly has many choices besides Java or .Net, at that
point someone who'd suggest, "Let's do it in straight C or assembly!" is the
one who ought to be fired. :-)


Yeah, even the new DSO here requires .NET to move live images to the PC.
Didn't like 2.0, wanted the old 1.1. Oh man. The topper was this morning
when a German said he wanted to register on their WEEE organization for
that new electronic waste tax which the Eurocrats have "invented". The
server responded that he could not register because he was using a Java
version that was too new!

The quality of all those programming environments has IMHO seriously
tanked lately. Problem is, us analog guys can't completely escape it.

--
Regards, Joerg

http://www.analogconsultants.com/

[Joerg]

Joel Koltner wrote:
"John Larkin" wrote in message
...
Well, I'd have preferred "quick and clean." We did one box that was
flash based, field upgradable, and it added a lot of hassle, both in
the design and in walking customers through upgrades.

What was the hardware interface? We have some widgets that, by contract, have
to be field upgradeable and the way the update software works is that, once
configured properly (which we can do here before sending them the upgrade
software), you drop the device into its battery charger and -- poof! -- about
3 seconds later it's been completely re-flashed (128KB of microcontroller
code). It's all done over USB.

I'd be a little concerned about the ability of someone to successfully take
apart your box and stick in a new EPROM if they couldn't manage to run the
typical flash ROM update program without needing a lot of hand-holding...


IrDA used to be an excellent tool for doing that with minimal cost at
the target. But it fell from grace, most laptops don't have it. There
are adapters though. I used an older spectrum analyzer at a client last
week (Rohde&Schwarz FSH23). It only had IrDA but there was a transfer
cable which made it RS232 so my laptop could talk to it. That kind of
saved our day.


The last two pieces of test geat I bought (Keithley 2100 DVM, Aeroflex
spectrum analyzer) both were shipped with pretty serious bugs,
probably on the theory that, hell, it's flash, let's ship now and we
can always upgrade them later.

That's the general mentality of most programmers (and their managers) these
days. There are even folks who'll try to make the business case that it's
better for a company overall to ship a product with known bugs than to delay
its release (and thus revenue) by fixing them first. Unfortunately, they're
probably right in that most people today are completely used to the
Microsoft-model of Internet-based patches/upgrades.


Not with folks like me. When a company seriously burns me chances are
I'll never use them again for the next 50 years or so.

And I guess with Vista even MS got a big egg in the face, didn't they?


The Aeroflex is designed and made in Korea, and Keithley refuses to
answer my question about whether they designed the DVM; they certainly
didn't manufacture it.

I'd take a refusal to answer a question like that as an admission that they
didn't design it themselves.


That would be my guess as well. Usually things become obvious very soon
if you can read some of the firmware back out or parse the next firmware
upgrade for common error message words like "the" or "input", then read
some of the messages. If they are lacking articles and have the usual
typos you'd know. My DSO instantly revealed it when I accidentally
unplugged the USB cable: "DSO not connect".

---Joel

P.S. -- Remember that discussion we were having about HP-35S calculators? I
found a pretty nasty bug in how it evalutes equations sometimes... for
particular program sequences it evaluates...

-R*X/(X*Q-R)

as

-R*X/([completely different variable than X]*Q-R)

:-(

I've advised HP of this; they haven't written back up other than to
acknowledge receipt.

(Some might recognize that equation up there are having to do with L-matching
networks with a load of R+jX and a quality factor Q.)


I guess those can't be re-flashed, or can they?

--
Regards, Joerg

http://www.analogconsultants.com/

[Phil Hobbs]

Joel Koltner wrote:
"Joerg" wrote in message
...
As soon as anybody doing an embedded system says "let's use Java",
fire them.

John
Agreed ;-)

Same goes for .NET.

You guys realize that that sort of "technology" is all over things like
Agilent and Tek scopes, network/spectrum/logic/etc. analyzers, etc. these
days, right? As soon as the marketing guys say, "This has to have a web
interface that can completely control the interface and display its screen
remotely!" while one certainly has many choices besides Java or .Net, at that
point someone who'd suggest, "Let's do it in straight C or assembly!" is the
one who ought to be fired. :-)



Nah, fire the one who suggested building scopes with BordelloVision or
whatever they call all that crap. I own one Windows scope, and I've
been wishing I didn't....nice scope otherwise.

Cheers,

Phil Hobbs

[Joerg]

Phil Hobbs wrote:
Joel Koltner wrote:
"Joerg" wrote in message
...
As soon as anybody doing an embedded system says "let's use Java",
fire them.

John
Agreed ;-)

Same goes for .NET.

You guys realize that that sort of "technology" is all over things
like Agilent and Tek scopes, network/spectrum/logic/etc. analyzers,
etc. these days, right? As soon as the marketing guys say, "This has
to have a web interface that can completely control the interface and
display its screen remotely!" while one certainly has many choices
besides Java or .Net, at that point someone who'd suggest, "Let's do
it in straight C or assembly!" is the one who ought to be fired. :-)



Nah, fire the one who suggested building scopes with BordelloVision or
whatever they call all that crap. I own one Windows scope, and I've
been wishing I didn't....nice scope otherwise.


I've used one. Once. That cured me. Those things can be awfully slow,
like Windows in general.

For really hot stuff most DSOs can't compete either, ain't nothing like
ye olde 2465. Unfortunately we'll be scraping the bottom of the barrel
on EBay pretty soon.

--
Regards, Joerg

http://www.analogconsultants.com/

[John Larkin]

On Tue, 23 Oct 2007 09:34:07 -0400, Phil Hobbs
wrote:

Joel Koltner wrote:
"Joerg" wrote in message
...
As soon as anybody doing an embedded system says "let's use Java",
fire them.

John
Agreed ;-)

Same goes for .NET.

You guys realize that that sort of "technology" is all over things like
Agilent and Tek scopes, network/spectrum/logic/etc. analyzers, etc. these
days, right? As soon as the marketing guys say, "This has to have a web
interface that can completely control the interface and display its screen
remotely!" while one certainly has many choices besides Java or .Net, at that
point someone who'd suggest, "Let's do it in straight C or assembly!" is the
one who ought to be fired. :-)



Nah, fire the one who suggested building scopes with BordelloVision or
whatever they call all that crap. I own one Windows scope, and I've
been wishing I didn't....nice scope otherwise.

Cheers,

Phil Hobbs

I'd worry about what happens a few years from now, when a hard (or
flash) drive fails, or the file structure gets corrupt, and you're
faced with doing a full re-install. Did your scope come with a
zero-based full-reinstall CD or equivalent? Do you know where it is?

John

[Joel Koltner]

"Joerg" wrote in message
et...
I guess those can't be re-flashed, or can they?

The 35s, no -- it's a mask ROM (basically the non-graphing calculators are
masked ROMs and the graphing machines are flash these days). However,
historically HP has been willing to exchange the entire calculator if you ran
into significant bugs; this is what happened 35 years ago when the original HP
35 came out (from http://www.hpmuseum.org/hp35.htm):

---

The HP-35 had numerical algorithms that exceeded the precision of most
mainframe computers at the time. During development, Dave Cochran, who was in
charge of the algorithms, tried to use a Burroughs B5500 to validate the
results of the HP-35 but instead found too little precision in the former to
continue. IBM mainframes also didn't measure up. This forced time-consuming
manual comparisons of results to mathematical tables. A few bugs got through
this process. For example: 2.02 ln ex resulted in 2 rather than 2.02. When the
bug was discovered, HP had already sold 25,000 units which was a huge volume
for the company. In a meeting, Dave Packard asked what they were going to do
about the units already in the field and someone in the crowd said "Don't
tell?" At this Packard's pencil snapped and he said: "Who said that? We're
going to tell everyone and offer them, a replacement. It would be better to
never make a dime of profit than to have a product out there with a problem".
It turns out that less than a quarter of the units were returned. Most people
preferred to keep their buggy calculator and the notice from HP offering the
replacement.

---

We'll see how the "new HP" responds...

---Joel

[Jim Thompson]

On Tue, 23 Oct 2007 09:42:05 -0700, "Joel Koltner"
wrote:

"Joerg" wrote in message
. net...
I guess those can't be re-flashed, or can they?

The 35s, no -- it's a mask ROM (basically the non-graphing calculators are
masked ROMs and the graphing machines are flash these days). However,
historically HP has been willing to exchange the entire calculator if you ran
into significant bugs; this is what happened 35 years ago when the original HP
35 came out (from http://www.hpmuseum.org/hp35.htm):

---

The HP-35 had numerical algorithms that exceeded the precision of most
mainframe computers at the time. During development, Dave Cochran, who was in
charge of the algorithms, tried to use a Burroughs B5500 to validate the
results of the HP-35 but instead found too little precision in the former to
continue. IBM mainframes also didn't measure up. This forced time-consuming
manual comparisons of results to mathematical tables. A few bugs got through
this process. For example: 2.02 ln ex resulted in 2 rather than 2.02. When the
bug was discovered, HP had already sold 25,000 units which was a huge volume
for the company. In a meeting, Dave Packard asked what they were going to do
about the units already in the field and someone in the crowd said "Don't
tell?" At this Packard's pencil snapped and he said: "Who said that? We're
going to tell everyone and offer them, a replacement. It would be better to
never make a dime of profit than to have a product out there with a problem".
It turns out that less than a quarter of the units were returned. Most people
preferred to keep their buggy calculator and the notice from HP offering the
replacement.

---

We'll see how the "new HP" responds...

---Joel


Yep. Isn't it a shame :-(

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

America: Land of the Free, Because of the Brave

[John Larkin]

On Tue, 23 Oct 2007 09:42:05 -0700, "Joel Koltner"
wrote:

"Joerg" wrote in message
. net...
I guess those can't be re-flashed, or can they?

The 35s, no -- it's a mask ROM (basically the non-graphing calculators are
masked ROMs and the graphing machines are flash these days). However,
historically HP has been willing to exchange the entire calculator if you ran
into significant bugs; this is what happened 35 years ago when the original HP
35 came out (from http://www.hpmuseum.org/hp35.htm):

---

The HP-35 had numerical algorithms that exceeded the precision of most
mainframe computers at the time. During development, Dave Cochran, who was in
charge of the algorithms, tried to use a Burroughs B5500 to validate the
results of the HP-35 but instead found too little precision in the former to
continue. IBM mainframes also didn't measure up. This forced time-consuming
manual comparisons of results to mathematical tables. A few bugs got through
this process. For example: 2.02 ln ex resulted in 2 rather than 2.02. When the
bug was discovered, HP had already sold 25,000 units which was a huge volume
for the company. In a meeting, Dave Packard asked what they were going to do
about the units already in the field and someone in the crowd said "Don't
tell?" At this Packard's pencil snapped and he said: "Who said that? We're
going to tell everyone and offer them, a replacement. It would be better to
never make a dime of profit than to have a product out there with a problem".
It turns out that less than a quarter of the units were returned. Most people
preferred to keep their buggy calculator and the notice from HP offering the
replacement.


Just tried it; got 2.02, so mine must be fixed.

We do that too: if any product has a bug that's our fault, we email
the users, and we'll fix it, or take it back, forever.

Is David still, around? I'd like to contact anybody from the
calculators group, HP9100 schematics.

John

[John Larkin]

On Mon, 22 Oct 2007 17:48:37 -0700, "Joel Koltner"
wrote:

"John Larkin" wrote in message
.. .
Well, I'd have preferred "quick and clean." We did one box that was
flash based, field upgradable, and it added a lot of hassle, both in
the design and in walking customers through upgrades.

What was the hardware interface?

RS-232 and optionally Ethernet. We wrote a flash upgrade program for
Windows. But our customers may be running Windows, RT Linux, an RTOS,
or a PLC with ladder logic. A physical eprom is easy to explain.

http://www.highlandtechnology.com/DSS/T560DS.html




P.S. -- Remember that discussion we were having about HP-35S calculators? I
found a pretty nasty bug in how it evalutes equations sometimes... for
particular program sequences it evaluates...

-R*X/(X*Q-R)

as

-R*X/([completely different variable than X]*Q-R)

It's probably programmed in Java.

John

[Joel Koltner]

"John Larkin" wrote in message
...
Is David still, around? I'd like to contact anybody from the
calculators group, HP9100 schematics.

He is -- there's an interview with him here --
http://www.viddler.com/explore/sleibson/videos/2/ ...that was done relatively
recently (this past summer?). If you post a message on the hpmuseum.org forum
there's a good chance someone might be able to put you in contact with him.

---Joel

[Joel Koltner]

"John Larkin" wrote in message
...
RS-232 and optionally Ethernet. We wrote a flash upgrade program for
Windows. But our customers may be running Windows, RT Linux, an RTOS,
or a PLC with ladder logic.

Can't all of those run Java?

(Ducking... :-) )

It's probably programmed in Java.

It's actually a 6502-type CPU running code that *emulates* the old 4-bit
Saturn CPUs originally developed for the HP-41 series!

The higher-end (graphing) calculators use ARMs emulating those old CPUs with
varying amounts of native ARM code added for the sake of performance or when
new code had to be written anyway for, e.g., accessing SD cards.

---Joel

[Joel Koltner]

"John Larkin" wrote in message
...
RS-232 and optionally Ethernet. We wrote a flash upgrade program for
Windows. But our customers may be running Windows, RT Linux, an RTOS,
or a PLC with ladder logic. A physical eprom is easy to explain.

More seriously... perhaps a good approach would be to keep a socketed flash
ROM inside? That way people with "easy" connectivity back to your boxes could
re-flash them from firmware upgrades downloaded from your web site, whereas
there's still the option to physically replace the ROM if that's not
desirable.

Do you not have customers asking for field-upgradeability (without opening the
box)? If not I suppose this is all rather moot...

[Joerg]

John Larkin wrote:
On Tue, 23 Oct 2007 09:42:05 -0700, "Joel Koltner"
wrote:

"Joerg" wrote in message
et...
I guess those can't be re-flashed, or can they?
The 35s, no -- it's a mask ROM (basically the non-graphing calculators are
masked ROMs and the graphing machines are flash these days). However,
historically HP has been willing to exchange the entire calculator if you ran
into significant bugs; this is what happened 35 years ago when the original HP
35 came out (from http://www.hpmuseum.org/hp35.htm):

---

The HP-35 had numerical algorithms that exceeded the precision of most
mainframe computers at the time. During development, Dave Cochran, who was in
charge of the algorithms, tried to use a Burroughs B5500 to validate the
results of the HP-35 but instead found too little precision in the former to
continue. IBM mainframes also didn't measure up. This forced time-consuming
manual comparisons of results to mathematical tables. A few bugs got through
this process. For example: 2.02 ln ex resulted in 2 rather than 2.02. When the
bug was discovered, HP had already sold 25,000 units which was a huge volume
for the company. In a meeting, Dave Packard asked what they were going to do
about the units already in the field and someone in the crowd said "Don't
tell?" At this Packard's pencil snapped and he said: "Who said that? We're
going to tell everyone and offer them, a replacement. It would be better to
never make a dime of profit than to have a product out there with a problem".
It turns out that less than a quarter of the units were returned. Most people
preferred to keep their buggy calculator and the notice from HP offering the
replacement.


Just tried it; got 2.02, so mine must be fixed.

We do that too: if any product has a bug that's our fault, we email
the users, and we'll fix it, or take it back, forever.

Is David still, around? I'd like to contact anybody from the
calculators group, HP9100 schematics.


AFAIK David Packard passed away in 1996 :-(

--
Regards, Joerg

http://www.analogconsultants.com/

[Tom Del Rosso]

"Joerg" wrote in message


The quality of all those programming environments has IMHO seriously
tanked lately. Problem is, us analog guys can't completely escape it.

They know how to write software but they don't know how to program
computers. (I think I invented a new aphorism there.)


--

Reply in group, but if emailing add another
zero, and remove the last word.

[Joerg]

Tom Del Rosso wrote:
"Joerg" wrote in message

The quality of all those programming environments has IMHO seriously
tanked lately. Problem is, us analog guys can't completely escape it.

They know how to write software but they don't know how to program
computers. (I think I invented a new aphorism there.)


I think you've touched the root cause here. Many programmers no longer
have the foggiest idea about what the hardware does or even what the
typical hardware looks like. For example, they assume that because the
HD capacities per Dollar have grown 1000-fold from 1987 to 2007 that
it'll be ok if their stuff is bloated by a factor of 1000. Seriously,
I've met guys who said that! Unfortunately the seek times and head
movement did not keep up because it's impossible to accelerate stuff
that fast. Ok, the defense guys could do it. Once.

--
Regards, Joerg

http://www.analogconsultants.com/

[John Larkin]

On Tue, 23 Oct 2007 12:19:11 -0700, "Joel Koltner"
wrote:

"John Larkin" wrote in message
.. .
RS-232 and optionally Ethernet. We wrote a flash upgrade program for
Windows. But our customers may be running Windows, RT Linux, an RTOS,
or a PLC with ladder logic. A physical eprom is easy to explain.

More seriously... perhaps a good approach would be to keep a socketed flash
ROM inside? That way people with "easy" connectivity back to your boxes could
re-flash them from firmware upgrades downloaded from your web site, whereas
there's still the option to physically replace the ROM if that's not
desirable.

Do you not have customers asking for field-upgradeability (without opening the
box)? If not I suppose this is all rather moot...


We've had a few instances where a customer wanted a feature added, and
waved around the prospect of purchase orders if we did it. So far,
mailing them eprom chips has made them happy.

Most of our products are VME modules, so there's no box!

John

[Spehro Pefhany]

On Sun, 21 Oct 2007 11:37:39 -0700, the renowned John Larkin
wrote:

On Sun, 21 Oct 2007 07:15:54 -0500, Spehro Pefhany
wrote:

On Sat, 20 Oct 2007 20:36:10 -0700, the renowned John Larkin
wrote:

On Sat, 20 Oct 2007 18:36:04 -0700, ChairmanOfTheBored
wrote:

On Sat, 20 Oct 2007 14:04:48 -0700, John Larkin
wrote:


I noticed a few process indicators to mention to your PCB maker's QA
folks. Not the contract makers the assembled the unit (or you guys if it
was your folks), the PCB itself.

The stains under the dip package location are indicative of mask
delamination or poor adhesion of it. A condition known as "haloing".

I think that's just the lighting. The board looks OK to me.



Change the resistor packs to the next form factor size up perhaps.

Yeah, we should stop using these things.

There are two edge forms, one is a bit more expensive and solders a
bit better IME. My most recent tiny board (1.75 x 2.9") has 10 of them
(0603x4) which is a lot nicer than 38 discrete 0603 or 0402 resistors.


Got any part numbers or links? It would be worth switching.

Sure. Check out page 1713 of the Digikey catalog, cp. TC164 vs. YC164.
I've had better results with the latter style.

And the US8's seem to be getting worse. ROHS plating maybe?
John




Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com