[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

[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

[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

[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

[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:
"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/

[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

[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
...
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...

[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

[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

[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.