Error correction in short packet....

[David Eather]

On 19/05/2022 1:54 am, Clive Arthur wrote:

Hi all

I have serial data in 14 byte packets on which I\'d like to detect and
correct errors.  Two bit errors would be nice.  I can put 2 extra EDC
bytes on the end to make a 16 byte packet.

I don\'t have the resources for Reed-Solomon.  I could use a 16 bit CRC,
these are easy to generate with a small/moderate LUT.

In the past, I\'ve used a CRC16 for single bit error detection and
correction on a longer packet, but I didn\'t do the error detection part.
 Errors were very rare, time was not critical, and I understand that
this was simply done by changing each message bit in turn then
recalculating the CRC till it all worked out.  That\'s far to slow for my
current needs.

If I\'m lucky, a 16 bit CRC might be able to detect and correct 2 bit
errors in 14 bytes (112 * 111 possibilities?), but is there a way of
quickly finding out which bits are wrong?

Or maybe a completely different approach? This has to be done on the
fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the
question.

this one shouldn\'t be thousands of compute cycles and only a small look
up table or maybe even none.

This one is out of the box: take the 14 bytes and append to bytes of a
known pattern 0x00 or 0xFF will work as well as anything else. Use a
128-bit (16 bytes) encryption algorithm and send that. On the receiving
end, decrypt. If the last two bytes are the same as the two you added
then all good.

if not then you have to brute force the data. All possible single bit
errors, all 2 bit errors etc until you get the answer or run out of
time. The good news is that this will pick up multiple bit errors

99.8% of all possible 1 bit errors - 128 in total
87.6% of all possible 2 bit errors - 8128 in total

each and every bit error has a ((2^16)-1)/2^16 chance to be detected.
that is a 99.999% chance.

Since you are not using the encryption algorithm as a cryptographic
device but just a randomizing device you can probably chop it length
down in half to double its speed.

 

[Phil Hobbs]

jlarkin@highlandsniptechnology.com wrote:

On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:

On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'.

Some people, especially ones with grey hair, immediately find fault
with ideas instead of riffing on them. That intimidates some
contributors, especially young ones. Sometimes they have sufficient
gravity that they kill a promising discussion.

Swift fault analysis isn\'t hostility, it is effective argument.

It is hostility and it kills ideas in their infancy. \"Argument\" says
it all. Right and wrong is a zero-sum game, or usually less than zero.

There\'s a bit of a semantic thicket here. I don\'t expect to agree with
w3 about much of anything, but here\'s a possibly-useful point:
unfortunately, popular discourse has lost the distinction between an
argument and a quarrel.

Properly speaking, an argument is a connected line of reasoning, by
intention valid, that attempts to establish some proposition.

It has to be able to withstand challenges to its validity and its
premises, delivered without animosity.

Arguing in that sense is great fun and leads to improved understanding
on everybody\'s part--maybe you get convinced, or maybe you don\'t, but in
any case it challenges you to clarify your ideas and articulate them
better. It\'s a win either way, and oh, by the way, it\'s terrific fun
when done well.

Quarrelling, on the other hand, is a lose--it convinces no one, it
isn\'t fun, it hardens attitudes, and it leaves bad feelings.

W3 overlooks the key idea-generating process ahead of the rational
arguments, but the eventual winnowing-out process does need to occur at
some point.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[marty]

On 20/5/22 07:10, Phil Hobbs wrote:

Martin Brown wrote:
On 19/05/2022 16:14, Jeroen Belleman wrote:
On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
keegan...@hotmail.com> wrote:

Clive Arthur <cl...@nowaytoday.co.uk> wrote:
On 19/05/2022 04:27, Sylvia Else wrote:

Is your channel really that noisy that you cannot just discard bad
packets?

I don\'t have control over the transmission path, it may be
noisy, it
may not - it\'s not a fixed installation. [snip...] I can\'t
request a
resend, and sending multiple copies restricts bandwidth too much.

Hmm, 17 messages in to the thread, and the group finally is told
some
of the critical unstated requirements that *should* have been
part of
the initial message, and would have avoided about 14 \"can\'t you
resend\"
or \"can\'t you send multiple\" messages.

Don\'t you think this above should have been in your initial post so
that the rest of us, who can\'t read your mind to divine unstated
limitations, were appraised of some rather critical limitations?


It\'s normal here to get underspecified problems. Details usually
emerge, but some people do refuse to explain their top-secret
projects.

https://xyproblem.info/

Underspecified problems do encourage lots of lateral/goofy thinking.

Almost all of which is completely wasted. Your proposal of send it
three times and vote best out of three being amongst them.

There is just about enough space to do what the OP wants but whether
or not they have the mathematical sophistication and programming
skills to implement it quickly enough to be useful is still an open
question.

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

You have that *EXACTLY* backwards.

If you cannot adequately describe the exact problem that you are
trying to solve then you will spend vast amounts of effort solving the
wrong problem(s) again and again. I have seen it happen many times.

Goofy ideas aren\'t really welcome if they upset a sizable fraction
of effort already invested. Ideas are cheap. Realizing them is costly.
You\'ll want to be selective.

+1

Half the battle is specifying the problem and any hard constraints so
that proposed solutions will actually stand a chance of working on the
available hardware and quickly enough to be useful.


I\'m way more in JL\'s camp, although not 100%.  (I do more math than he
does.)

Of course you don\'t want to take the first thing that comes into your
head and build that--nobody\'s advocating that here AFAICT.  I\'ve seen it
a lot in the wild, though.  In fact, one outfit I had to deal with (a CE
in Orange County CA) kept ignoring advice that was backed up with
detailed mathematical analysis and a _working_prototype_ of what they
were supposed to build. (That transcutaneous blood glucose thing again.)

They just trying things randomly until they ran through the client\'s
money and then quit.  One time when I pinged them about it, a bright lad
smiled and said, \"That\'s engineering!\"

Riiighhhtt.

But a lot, a lot of people seem to have very little emotional tolerance
for being in a state of uncertainty.  I can\'t prove that, but over and
over I\'ve seen folks spend far too little time turning the problem over
in their minds, talking at the white board, and so on, and just charging
in and doing the first thing that seemed plausible.

That\'s super dumb. At the beginning of the process, you have to
cultivate offbeat ideas, because (at least in the sort of gizmos I
build) there\'s usually some way to do the task much better and/or
cheaper than what\'s out there.

In general you should spend something like 10% of the time figuring out
what you should build, and the rest designing and building it.  Skimping
on the one very often leads to poor results on the other.

Cheers

Phil Hobbs

archived

--
Marty

 

[server]

On Sun, 22 May 2022 15:35:05 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

jlarkin@highlandsniptechnology.com wrote:
On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com
wrote:

On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:

On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'.

Some people, especially ones with grey hair, immediately find fault
with ideas instead of riffing on them. That intimidates some
contributors, especially young ones. Sometimes they have sufficient
gravity that they kill a promising discussion.

Swift fault analysis isn\'t hostility, it is effective argument.

It is hostility and it kills ideas in their infancy. \"Argument\" says
it all. Right and wrong is a zero-sum game, or usually less than zero.

There\'s a bit of a semantic thicket here. I don\'t expect to agree with
w3 about much of anything, but here\'s a possibly-useful point:
unfortunately, popular discourse has lost the distinction between an
argument and a quarrel.

Properly speaking, an argument is a connected line of reasoning, by
intention valid, that attempts to establish some proposition.

It has to be able to withstand challenges to its validity and its
premises, delivered without animosity.

Arguing in that sense is great fun and leads to improved understanding
on everybody\'s part--maybe you get convinced, or maybe you don\'t, but in
any case it challenges you to clarify your ideas and articulate them
better. It\'s a win either way, and oh, by the way, it\'s terrific fun
when done well.

Quarrelling, on the other hand, is a lose--it convinces no one, it
isn\'t fun, it hardens attitudes, and it leaves bad feelings.

W3 overlooks the key idea-generating process ahead of the rational
arguments, but the eventual winnowing-out process does need to occur at
some point.

Cheers

Phil Hobbs

Arguing, to me, implies a classic debate style, where the objective of
every player is to be right and to prove their opponents wrong. It\'s
not quarreling but is still emotional competition... the goal being to
win.

Brainstorming is a team-less sport played for fun, where the objective
is to invent ideas together.

Later on, when a few cool ideas have evolved, is the time for
winnowing and serious engineering design.

Not many people are comfortable or competant doing both.



--

Anybody can count to one.

- Robert Widlar

 

[Jasen Betts]

On 2022-05-20, Jasen Betts <usenet@revmaps.no-ip.org> wrote:

On 2022-05-18, Clive Arthur <clive@nowaytoday.co.uk> wrote:
Hi all

I have serial data in 14 byte packets on which I\'d like to detect and
correct errors. Two bit errors would be nice. I can put 2 extra EDC
bytes on the end to make a 16 byte packet.

I don\'t have the resources for Reed-Solomon. I could use a 16 bit CRC,
these are easy to generate with a small/moderate LUT.

In the past, I\'ve used a CRC16 for single bit error detection and
correction on a longer packet, but I didn\'t do the error detection part.
Errors were very rare, time was not critical, and I understand that
this was simply done by changing each message bit in turn then
recalculating the CRC till it all worked out. That\'s far to slow for my
current needs.

If I\'m lucky, a 16 bit CRC might be able to detect and correct 2 bit
errors in 14 bytes (112 * 111 possibilities?), but is there a way of
quickly finding out which bits are wrong?

Actually no there\'s 128 bits so there\'s 128 single bit errors and
127*128/2 two bit errors, and one zero-bit error possibility that all
need to be dealt with.

total 8257 cases

> a look-up table. how much resources do you have?

You say in another message less than several kilobytes.

create a CRC to single-bit error table (use a hash table, because it\'s
O(1) for lookups)

Now you can explit the fact that CRC is a linear code, so the CRC for
bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
of bit n wrong, (the CRC for all bits correct is of course zero after
feeding the data and CRC into the CRC algorithm.)

If you get a non-zero CRC on a packet look it up in the table

If you don\'t find a match speculativly xor it with the first CRC in
the table then look up the result, if it\'s not found, try xoring the
next instead.

CRC might not be the best hash to use for this task, you want
something that gives distinct codes for all 1 and 2 bit errors, I
haven\'t checked if CRC-16 has that property.

there\'s 341376 three bit errors, so it\'s probably not going to be
possible to even detect them using CRC-16.

Using a 15 bit CRC code (or other linear hash code) in combination
with a parity bit should make 3 bit errors detectable however.

This should be do-able in 4000 or so instuction steps - not vastly worse
than the CRC computation itself - especially if you can get perfect
hashing in your LUT.

--
Jasen.

 

[Clive Arthur]

On 20/05/2022 12:10, Jasen Betts wrote:

<snip>

Actually no there\'s 128 bits so there\'s 128 single bit errors and
127*128/2 two bit errors, and one zero-bit error possibility that all
need to be dealt with.

total 8257 cases

a look-up table. how much resources do you have?

You say in another message less than several kilobytes.

create a CRC to single-bit error table (use a hash table, because it\'s
O(1) for lookups)

Now you can explit the fact that CRC is a linear code, so the CRC for
bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
of bit n wrong, (the CRC for all bits correct is of course zero after
feeding the data and CRC into the CRC algorithm.)

If you get a non-zero CRC on a packet look it up in the table

If you don\'t find a match speculativly xor it with the first CRC in
the table then look up the result, if it\'s not found, try xoring the
next instead.

CRC might not be the best hash to use for this task, you want
something that gives distinct codes for all 1 and 2 bit errors, I
haven\'t checked if CRC-16 has that property.

there\'s 341376 three bit errors, so it\'s probably not going to be
possible to even detect them using CRC-16.

Using a 15 bit CRC code (or other linear hash code) in combination
with a parity bit should make 3 bit errors detectable however.

This should be do-able in 4000 or so instuction steps - not vastly worse
than the CRC computation itself - especially if you can get perfect
hashing in your LUT.

Thank you, that\'s very useful. Just one point - my CRC calculation uses
a 512 byte LUT and is done on-the-fly taking only a few instructions for
each byte.

--
Cheers
Clive

 

[server]

On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whit3rd@gmail.com>
wrote:

On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


Of course, some people are hostile to ideas.

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'.

Some people, especially ones with grey hair, immediately find fault
with ideas instead of riffing on them. That intimidates some
contributors, especially young ones. Sometimes they have sufficient
gravity that they kill a promising discussion.

I have to be careful that my status doesn\'t make people assume that
I\'m right; I don\'t want to be the poison.

I have grey hair, but cannot recall ever meeting
>someone who was \'hostile to ideas\' in general.

Sounds like you haven\'t brainstormed a lot.




--

Anybody can count to one.

- Robert Widlar

 

[Phil Hobbs]

whit3rd wrote:

On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


Of course, some people are hostile to ideas.

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'. I have grey hair, but cannot recall ever meeting
someone who was \'hostile to ideas\' in general.

You\'ve lived a sheltered life. Back in my early days at IBM Research, I
was in the Manufacturing Research department. It was pretty much a
gizmo-builder\'s paradise--an apparently endless series of hard,
interesting, and economically important problems that needed custom
instruments to solve, pleasant and very smart colleagues, smart and
patient management, and very few budget constraints. A pal of mine from
back then, the estimable Clayton Williams (now flourishing at BYU)
needed a new lock-in amplifier. He was thinking out loud one day, \"It\'s
stupid to buy just one. I probably don\'t need five, so let\'s order
two.\" Two shiny new lock-ins arrived in a few days. If he had needed
five, five would have come instead.

We were entirely self-governed--our budget came out of a big pot at
Corporate, so the folks we were nominally serving couldn\'t really tell
us what to do. Not that doing stuff randomly was encouraged, you
understand, but we didn\'t have the product divisions cracking any whips
that we had to care about. As I said, a great place to build gizmos.

While the customers couldn\'t tell us what to do, there was a certain
contingent of folks who seemed to resent this--apparently they were
happier being able to make vendors dance to their tune. Thus they chose
to throw rocks and tell the folks trying to do stuff that it would never
work, that progress was unacceptable, that the instrument concept was
all wrong, and so on and so forth. Those folks, you absolutely had to
keep out of the planning stage of the project, or they\'d trash you to
their management and often succeed in killing the effort.

There were also folks who wanted to swoop in once the project was on
rails and steal the credit. There was even a select demographic that
habitually did both.

When IBM had its near-death experience in 1992, all those folks were
gone, which was great, but so of course were the lush budgets, which
wasn\'t that great. My time at IBM was like the perfect 21-year
vacation--I was excited to start and excited to leave (as well as scared).

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[whit3rd]

On Sunday, May 22, 2022 at 4:49:27 PM UTC-7, jla...@highlandsniptechnology.com wrote:

Arguing, to me, implies a classic debate style, where the objective of
every player is to be right and to prove their opponents wrong. It\'s
not quarreling but is still emotional competition... the goal being to
win.

The Plato-era \'classic\' works on argument call that \'gotta-win\' variant
sophistry, and refuted the validity of sophistical arguments while supporting
logical arguments. Debate is contrivance, a game lawyers play in
their effort to become better advocates; it isn\'t a productive
exercise, nor does it attempt truth-seeking.

Brainstorming is a team-less sport played for fun, where the objective
is to invent ideas together.

The psychology faculty taught me otherwise; the domination of group thinking by
loud voices was hurting productivity, and they built, and tested,
formal rules for brainstorming as a technical fix for that flaw.

<https://en.wikipedia.org/wiki/Brainstorming>

 

[server]

On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

whit3rd wrote:
On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


Of course, some people are hostile to ideas.

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'. I have grey hair, but cannot recall ever meeting
someone who was \'hostile to ideas\' in general.


You\'ve lived a sheltered life. Back in my early days at IBM Research, I
was in the Manufacturing Research department. It was pretty much a
gizmo-builder\'s paradise--an apparently endless series of hard,
interesting, and economically important problems that needed custom
instruments to solve, pleasant and very smart colleagues, smart and
patient management, and very few budget constraints. A pal of mine from
back then, the estimable Clayton Williams (now flourishing at BYU)
needed a new lock-in amplifier. He was thinking out loud one day, \"It\'s
stupid to buy just one. I probably don\'t need five, so let\'s order
two.\" Two shiny new lock-ins arrived in a few days. If he had needed
five, five would have come instead.

We were entirely self-governed--our budget came out of a big pot at
Corporate, so the folks we were nominally serving couldn\'t really tell
us what to do. Not that doing stuff randomly was encouraged, you
understand, but we didn\'t have the product divisions cracking any whips
that we had to care about. As I said, a great place to build gizmos.

While the customers couldn\'t tell us what to do, there was a certain
contingent of folks who seemed to resent this--apparently they were
happier being able to make vendors dance to their tune. Thus they chose
to throw rocks and tell the folks trying to do stuff that it would never
work, that progress was unacceptable, that the instrument concept was
all wrong, and so on and so forth. Those folks, you absolutely had to
keep out of the planning stage of the project, or they\'d trash you to
their management and often succeed in killing the effort.

There were also folks who wanted to swoop in once the project was on
rails and steal the credit. There was even a select demographic that
habitually did both.

When IBM had its near-death experience in 1992, all those folks were
gone, which was great, but so of course were the lush budgets, which
wasn\'t that great. My time at IBM was like the perfect 21-year
vacation--I was excited to start and excited to leave (as well as scared).

Cheers

Phil Hobbs

It\'s interesting that none of the giant tube companies were long-term
successful in semiconductors. Garage shops killed GE, RCA, Motorola,
Sylvania, and many others.

Efinix will be interesting to watch, against Xilinx and Altera.



--

Anybody can count to one.

- Robert Widlar

 

[whit3rd]

On Thursday, May 19, 2022 at 3:31:23 PM UTC-7, John Larkin wrote:

Yes, I work more by instinct and simulation. But my world is largely
nonlinear, where the math is basically impossible.

Identifying a problem as nonlinear IS math; it\'s obviously useful info,
and the only deficiency is in the non-utility of common approximations.
The math is not impossible, just... more difficult.

 

[Don Y]

On 5/19/2022 12:24 PM, whit3rd wrote:

On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

Again with the goofy personality theories! Everyone is hostile to ideas
for a few minutes in the evening, when it\'s time to sleep.

That\'s normal, and has nothing to do with a career path.

That\'s *cranky*. I have little patience for distractions (of any kind)
when I\'m over tired (and focused on getting things in order so I can
*rest*) or \"overloaded\" -- and need to get things off my plate so I can
concentrate on something \"new\".

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

People aren\'t hostile to ideas (JL sees *everything* as some aspect of
hostility; an entirely passive-aggressive outlook on life).

But, people can be resistant to the *consequences* of ideas. Direct or
otherwise.

NIH figures big in engineering. Folks always want to think their PAST
accomplishment is somehow the epitome of thinking on that subject.
This is likely some reflection on their own ego as well as a
manifestation of \"laziness\" -- they aren\'t really interested in solving
a problem again, even if *better*!

And, engineering is a field where one is quickly obsolete. Especially
if too narrow a focus in your endeavors.

I had a stick-in-the-mud fight tooth-and-nail against replacing
HIS decade-old analog control system with a digital one. Despite
the fact that customers weren\'t buying it anymore AND sales of
the \"controlled equipment\" (7 figures) were being lost because of
this \"antiquated offering\".

Another old-timer fought to preserve a part numbering system that,
ages ago (when fewer parts were in inventory) would allow him to
fabricate a \"close approximation\" to a desired part number
using a paper cheat sheet he kept in his wallet. (\"And what do we
do when you\'re on vacation? Or, RETIRE??!\")

Another *principal* argued that developers should use octal
notation to specify *opcodes* (!) using a similar \"pocket assembler\".
(\"Um, you know, there are tools that eliminate the need for doing
this sort of thing. Just like there are tools that allow us to
travel great distances without wearing out our SHOES!\")

Or, clinging to old ideas because they were patent worthy -- ten
years ago! <rolls eyes> Despite the fact that your competitors have
all found BETTER ways to do the same thing!

All examples of the \"that\'s how we USED to do it\" mindset.
(\"I *built* this company using that technique!\" \"Yeah,
and it hasn\'t *grown* in years!\")

All examples of people keeping their companies tied to the
past and closing off opportunities to advance.

I find email to be the single most effective tool in the design
process:
- It is self-documenting.
- It supports participants at widely different locations/timezones
- It allows the recipients time to digest the material presented.
- It allows them time to formulate and revise their response.
I know many folks who are lousy \"thinking on their feet\".
But, given time, have tremendously valuable insights.
- It is non-confrontational. Face to face *meetings* (not a
one-on-one by the water cooler) have undercurrents, especially
in small companies where folks may have agendas or jockey
to get in the boss\'s good favor or risk \"bucking the system\".
- It inherently dampens any \"unbridled enthusiasm\" that may
be based in emotion and not reason.
- No \"voice\" can overpower a conversation.
- There\'s no \"audience\"; come as you are!
- There\'s no implied (polite society) need to respond to every
utterance. You can just let an idea die, \"gracefully\".
- There\'s no issue of \"face\"
- The Cc: list can change from one message to the next. To
bring someone into the conversation, you just have to add
their name to the Cc/Bcc line.
- Participants can drop out of the conversation at will
(imagine getting up and excusing yourself from a meeting
and NOT being noticed for doing so!)
- You can adjust your recipients to subsets of the group
without offending those not involved *or* distracting
from their ongoing conversations.
- You can cut-and-paste bits of the conversation into your
design specification/requirements document/manual using
words that others have already chosen

The biggest downside to email is a consequence of all of
these features: the elapsed time involved. But, if you
think you can \"create on demand\" or \"within a specific
timeframe\", you are likely going to get only incremental
changes to ideas. It takes time to stew on issues before
you can formulate GOOD solutions.

[I find the shower to be the best \"facilitator\"; no visual
or audible distractions, comfortable warmth, etc. I\'m
free to \"just imagine\" solutions without having to
deal with other people, pen&paper, etc.]

But, if you\'re just working on small/simple problems,
you can likely hammer out *a* solution in short order.

 

[whit3rd]

On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:

On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:

On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'.

Some people, especially ones with grey hair, immediately find fault
with ideas instead of riffing on them. That intimidates some
contributors, especially young ones. Sometimes they have sufficient
gravity that they kill a promising discussion.

Swift fault analysis isn\'t hostility, it is effective argument.
Brainstorming is a formal procedure that eliminates the scenario you describe;
there are no immediate judgments.

Competent individuals will foresee problems, and avoid them,
but that is NOT hostility in any sense of the word. Ideas aren\'t opponents.

 

[Lasse Langwadt Christensen]

fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:

On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

whit3rd wrote:
On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


Of course, some people are hostile to ideas.

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'. I have grey hair, but cannot recall ever meeting
someone who was \'hostile to ideas\' in general.


You\'ve lived a sheltered life. Back in my early days at IBM Research, I
was in the Manufacturing Research department. It was pretty much a
gizmo-builder\'s paradise--an apparently endless series of hard,
interesting, and economically important problems that needed custom
instruments to solve, pleasant and very smart colleagues, smart and
patient management, and very few budget constraints. A pal of mine from
back then, the estimable Clayton Williams (now flourishing at BYU)
needed a new lock-in amplifier. He was thinking out loud one day, \"It\'s
stupid to buy just one. I probably don\'t need five, so let\'s order
two.\" Two shiny new lock-ins arrived in a few days. If he had needed
five, five would have come instead.

We were entirely self-governed--our budget came out of a big pot at
Corporate, so the folks we were nominally serving couldn\'t really tell
us what to do. Not that doing stuff randomly was encouraged, you
understand, but we didn\'t have the product divisions cracking any whips
that we had to care about. As I said, a great place to build gizmos.

While the customers couldn\'t tell us what to do, there was a certain
contingent of folks who seemed to resent this--apparently they were
happier being able to make vendors dance to their tune. Thus they chose
to throw rocks and tell the folks trying to do stuff that it would never
work, that progress was unacceptable, that the instrument concept was
all wrong, and so on and so forth. Those folks, you absolutely had to
keep out of the planning stage of the project, or they\'d trash you to
their management and often succeed in killing the effort.

There were also folks who wanted to swoop in once the project was on
rails and steal the credit. There was even a select demographic that
habitually did both.

When IBM had its near-death experience in 1992, all those folks were
gone, which was great, but so of course were the lush budgets, which
wasn\'t that great. My time at IBM was like the perfect 21-year
vacation--I was excited to start and excited to leave (as well as scared).

Cheers

Phil Hobbs
It\'s interesting that none of the giant tube companies were long-term
successful in semiconductors. Garage shops killed GE, RCA, Motorola,
Sylvania, and many others.

the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...

 

[server]

On Sun, 22 May 2022 19:28:39 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 5/19/2022 12:24 PM, whit3rd wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

Again with the goofy personality theories! Everyone is hostile to ideas
for a few minutes in the evening, when it\'s time to sleep.

That\'s normal, and has nothing to do with a career path.

That\'s *cranky*. I have little patience for distractions (of any kind)
when I\'m over tired (and focused on getting things in order so I can
*rest*) or \"overloaded\" -- and need to get things off my plate so I can
concentrate on something \"new\".

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

People aren\'t hostile to ideas (JL sees *everything* as some aspect of
hostility; an entirely passive-aggressive outlook on life).

Not at all. I\'m cheerful and helpful. But there are a lot of nasty
people here who don\'t design electronics.



--

Anybody can count to one.

- Robert Widlar

 

[boB]

On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com
wrote:

On Sun, 22 May 2022 19:28:39 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

On 5/19/2022 12:24 PM, whit3rd wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

Again with the goofy personality theories! Everyone is hostile to ideas
for a few minutes in the evening, when it\'s time to sleep.

That\'s normal, and has nothing to do with a career path.

That\'s *cranky*. I have little patience for distractions (of any kind)
when I\'m over tired (and focused on getting things in order so I can
*rest*) or \"overloaded\" -- and need to get things off my plate so I can
concentrate on something \"new\".

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

People aren\'t hostile to ideas (JL sees *everything* as some aspect of
hostility; an entirely passive-aggressive outlook on life).

Not at all. I\'m cheerful and helpful. But there are a lot of nasty
people here who don\'t design electronics.

You sure got that right !

boB

 

[server]

On Sun, 22 May 2022 22:54:04 -0700, boB <boB@K7IQ.com> wrote:

On Sun, 22 May 2022 20:49:08 -0700, jlarkin@highlandsniptechnology.com
wrote:

On Sun, 22 May 2022 19:28:39 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

On 5/19/2022 12:24 PM, whit3rd wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

Again with the goofy personality theories! Everyone is hostile to ideas
for a few minutes in the evening, when it\'s time to sleep.

That\'s normal, and has nothing to do with a career path.

That\'s *cranky*. I have little patience for distractions (of any kind)
when I\'m over tired (and focused on getting things in order so I can
*rest*) or \"overloaded\" -- and need to get things off my plate so I can
concentrate on something \"new\".

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

People aren\'t hostile to ideas (JL sees *everything* as some aspect of
hostility; an entirely passive-aggressive outlook on life).

Not at all. I\'m cheerful and helpful. But there are a lot of nasty
people here who don\'t design electronics.

You sure got that right !

boB

Playing with circuits is fun. Endless ritual squabbling is boring and
bad for you. So why do they do it here?



--

Anybody can count to one.

- Robert Widlar

 

[John Larkin]

On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

John Larkin wrote:
On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

John Larkin wrote:
On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Martin Brown wrote:
On 19/05/2022 16:14, Jeroen Belleman wrote:
On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
keegan...@hotmail.com> wrote:

Clive Arthur <cl...@nowaytoday.co.uk> wrote:
On 19/05/2022 04:27, Sylvia Else wrote:

Is your channel really that noisy that you cannot just discard bad
packets?

I don\'t have control over the transmission path, it may be noisy, it
may not - it\'s not a fixed installation. [snip...] I can\'t request a
resend, and sending multiple copies restricts bandwidth too much.

Hmm, 17 messages in to the thread, and the group finally is told some
of the critical unstated requirements that *should* have been part of
the initial message, and would have avoided about 14 \"can\'t you
resend\"
or \"can\'t you send multiple\" messages.

Don\'t you think this above should have been in your initial post so
that the rest of us, who can\'t read your mind to divine unstated
limitations, were appraised of some rather critical limitations?


It\'s normal here to get underspecified problems. Details usually
emerge, but some people do refuse to explain their top-secret
projects.

https://xyproblem.info/

Underspecified problems do encourage lots of lateral/goofy thinking.

Almost all of which is completely wasted. Your proposal of send it three
times and vote best out of three being amongst them.

There is just about enough space to do what the OP wants but whether or
not they have the mathematical sophistication and programming skills to
implement it quickly enough to be useful is still an open question.

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

You have that *EXACTLY* backwards.

If you cannot adequately describe the exact problem that you are trying
to solve then you will spend vast amounts of effort solving the wrong
problem(s) again and again. I have seen it happen many times.

Goofy ideas aren\'t really welcome if they upset a sizable fraction
of effort already invested. Ideas are cheap. Realizing them is costly.
You\'ll want to be selective.

+1

Half the battle is specifying the problem and any hard constraints so
that proposed solutions will actually stand a chance of working on the
available hardware and quickly enough to be useful.


I\'m way more in JL\'s camp, although not 100%. (I do more math than he
does.)

Yes, I work more by instinct and simulation. But my world is largely
nonlinear, where the math is basically impossible.


Of course you don\'t want to take the first thing that comes into your
head and build that--nobody\'s advocating that here AFAICT. I\'ve seen it
a lot in the wild, though. In fact, one outfit I had to deal with (a CE
in Orange County CA) kept ignoring advice that was backed up with
detailed mathematical analysis and a _working_prototype_ of what they
were supposed to build. (That transcutaneous blood glucose thing again.)

They just trying things randomly until they ran through the client\'s
money and then quit. One time when I pinged them about it, a bright lad
smiled and said, \"That\'s engineering!\"

Riiighhhtt.

But a lot, a lot of people seem to have very little emotional tolerance
for being in a state of uncertainty. I can\'t prove that, but over and
over I\'ve seen folks spend far too little time turning the problem over
in their minds, talking at the white board, and so on, and just charging
in and doing the first thing that seemed plausible.

Yes. Uncertainty makes many people uncomfortable, so they lock down an
architecture as soon as they can. I\'ve seen horrors.


That\'s super dumb. At the beginning of the process, you have to
cultivate offbeat ideas, because (at least in the sort of gizmos I
build) there\'s usually some way to do the task much better and/or
cheaper than what\'s out there.

In general you should spend something like 10% of the time figuring out
what you should build, and the rest designing and building it. Skimping
on the one very often leads to poor results on the other.

Brainstorming and a period of confusion can often greatly simplify the
design, or add nifty features. It\'s well worth the tradeoff.

Design is a partly emotional process, which lots of engineers don\'t
want to admit either.


One time long ago, I was in a two-day class for OS/2 Presentation
Manager programming. (I did say it was long ago.)

At one point, the presenter (who was actually very good) asked us two
questions: Is design an art or a science? What about debugging?

Just about everyone said that design was a science and debugging was an
art. That\'s backwards.

A design is done when the designer says it\'s done, generally including a
good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
ad nauseam. There are nearly always a ridiculously large number of
different ways to do the job, if you count all the combinations. That
makes it an art.

On the other hand, troubleshooting is definitely a science. There\'s a
problem someplace, because this item doesn\'t behave like the N previous
ones that worked. You find it by applying critical tests and reasoning
about them, and when the problem is found and fixed, everyone can agree
that it\'s gone.

Debugging first articles is a bit of both, because you often find design
screwups (hopefully minor). In my world that often includes
layout-dependent stuff such as how high a current can you run through
your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
Swapping out jumpers for beads, tweaking current sources, that sort of
stuff.

In rare instances it\'s something really stupid such as upside-down power
supplies on an op amp, but normally the first articles are shippable
with maybe a roach wire or two.

After some years, we have evolved procedures that mostly prevent
getting V+ and V- swapped on opamps.


We have had the occasional disaster, such as a small module with three
SMPSes on it to make several rails from a +24V wall wart. The negative
rails were made by an AOZ1282 async buck running off the output of an
LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

The A-O part is generally super well behaved, but the two together
produced a _ridiculous_ selection of high harmonics of the LMR23630\'s
2.15 MHz switching frequency. It was the stuff of nightmares--measuring
one node produced a big peak at 182 MHz, and another one nearby had
another peak at 121 MHz, selected by various incidental resonances.

With that one, we just cut our losses. ;(


We recently had an LTM8078 \"Silent Switcher\" screaming at us in 400
MHz bursts at 2.5 MHz. The embarassing part was that the customer
discovered it. Oops.

A nice ancient National 50 KHz Simple Switcher fixed that, with a
board spin of course. And gigantic inductors.

https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

I\'ve had good luck with the 150 kHz ones too, with Schottky catch diodes
to prevent current spikes from PN diode recovery. They do tend to need
chunky inductors to handle all those voltseconds.

Cheers

Phil Hobbs

When people make mosfet substrate diodes, they tend to make them
step-recovery diodes. There must be some semi fab reason for that.

Adding an external schottky catch diode to a spikey synchronous
switcher doesn\'t seem to help.

This is textbook:

https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1

Bottom fet turns off, reverse conducts, and then snaps.



--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

 

[Phil Hobbs]

John Larkin wrote:

On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

John Larkin wrote:
On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

John Larkin wrote:
On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Martin Brown wrote:
On 19/05/2022 16:14, Jeroen Belleman wrote:
On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
jla...@highlandsniptechnology.com:
On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
keegan...@hotmail.com> wrote:

Clive Arthur <cl...@nowaytoday.co.uk> wrote:
On 19/05/2022 04:27, Sylvia Else wrote:

Is your channel really that noisy that you cannot just discard bad
packets?

I don\'t have control over the transmission path, it may be noisy, it
may not - it\'s not a fixed installation. [snip...] I can\'t request a
resend, and sending multiple copies restricts bandwidth too much.

Hmm, 17 messages in to the thread, and the group finally is told some
of the critical unstated requirements that *should* have been part of
the initial message, and would have avoided about 14 \"can\'t you
resend\"
or \"can\'t you send multiple\" messages.

Don\'t you think this above should have been in your initial post so
that the rest of us, who can\'t read your mind to divine unstated
limitations, were appraised of some rather critical limitations?


It\'s normal here to get underspecified problems. Details usually
emerge, but some people do refuse to explain their top-secret
projects.

https://xyproblem.info/

Underspecified problems do encourage lots of lateral/goofy thinking.

Almost all of which is completely wasted. Your proposal of send it three
times and vote best out of three being amongst them.

There is just about enough space to do what the OP wants but whether or
not they have the mathematical sophistication and programming skills to
implement it quickly enough to be useful is still an open question.

Of course, some people are hostile to ideas. Their career path is more
McDonalds than electronic design.

You have that *EXACTLY* backwards.

If you cannot adequately describe the exact problem that you are trying
to solve then you will spend vast amounts of effort solving the wrong
problem(s) again and again. I have seen it happen many times.

Goofy ideas aren\'t really welcome if they upset a sizable fraction
of effort already invested. Ideas are cheap. Realizing them is costly.
You\'ll want to be selective.

+1

Half the battle is specifying the problem and any hard constraints so
that proposed solutions will actually stand a chance of working on the
available hardware and quickly enough to be useful.


I\'m way more in JL\'s camp, although not 100%. (I do more math than he
does.)

Yes, I work more by instinct and simulation. But my world is largely
nonlinear, where the math is basically impossible.


Of course you don\'t want to take the first thing that comes into your
head and build that--nobody\'s advocating that here AFAICT. I\'ve seen it
a lot in the wild, though. In fact, one outfit I had to deal with (a CE
in Orange County CA) kept ignoring advice that was backed up with
detailed mathematical analysis and a _working_prototype_ of what they
were supposed to build. (That transcutaneous blood glucose thing again.)

They just trying things randomly until they ran through the client\'s
money and then quit. One time when I pinged them about it, a bright lad
smiled and said, \"That\'s engineering!\"

Riiighhhtt.

But a lot, a lot of people seem to have very little emotional tolerance
for being in a state of uncertainty. I can\'t prove that, but over and
over I\'ve seen folks spend far too little time turning the problem over
in their minds, talking at the white board, and so on, and just charging
in and doing the first thing that seemed plausible.

Yes. Uncertainty makes many people uncomfortable, so they lock down an
architecture as soon as they can. I\'ve seen horrors.


That\'s super dumb. At the beginning of the process, you have to
cultivate offbeat ideas, because (at least in the sort of gizmos I
build) there\'s usually some way to do the task much better and/or
cheaper than what\'s out there.

In general you should spend something like 10% of the time figuring out
what you should build, and the rest designing and building it. Skimping
on the one very often leads to poor results on the other.

Brainstorming and a period of confusion can often greatly simplify the
design, or add nifty features. It\'s well worth the tradeoff.

Design is a partly emotional process, which lots of engineers don\'t
want to admit either.


One time long ago, I was in a two-day class for OS/2 Presentation
Manager programming. (I did say it was long ago.)

At one point, the presenter (who was actually very good) asked us two
questions: Is design an art or a science? What about debugging?

Just about everyone said that design was a science and debugging was an
art. That\'s backwards.

A design is done when the designer says it\'s done, generally including a
good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
ad nauseam. There are nearly always a ridiculously large number of
different ways to do the job, if you count all the combinations. That
makes it an art.

On the other hand, troubleshooting is definitely a science. There\'s a
problem someplace, because this item doesn\'t behave like the N previous
ones that worked. You find it by applying critical tests and reasoning
about them, and when the problem is found and fixed, everyone can agree
that it\'s gone.

Debugging first articles is a bit of both, because you often find design
screwups (hopefully minor). In my world that often includes
layout-dependent stuff such as how high a current can you run through
your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
Swapping out jumpers for beads, tweaking current sources, that sort of
stuff.

In rare instances it\'s something really stupid such as upside-down power
supplies on an op amp, but normally the first articles are shippable
with maybe a roach wire or two.

After some years, we have evolved procedures that mostly prevent
getting V+ and V- swapped on opamps.


We have had the occasional disaster, such as a small module with three
SMPSes on it to make several rails from a +24V wall wart. The negative
rails were made by an AOZ1282 async buck running off the output of an
LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).

The A-O part is generally super well behaved, but the two together
produced a _ridiculous_ selection of high harmonics of the LMR23630\'s
2.15 MHz switching frequency. It was the stuff of nightmares--measuring
one node produced a big peak at 182 MHz, and another one nearby had
another peak at 121 MHz, selected by various incidental resonances.

With that one, we just cut our losses. ;(


We recently had an LTM8078 \"Silent Switcher\" screaming at us in 400
MHz bursts at 2.5 MHz. The embarassing part was that the customer
discovered it. Oops.

A nice ancient National 50 KHz Simple Switcher fixed that, with a
board spin of course. And gigantic inductors.

https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

I\'ve had good luck with the 150 kHz ones too, with Schottky catch diodes
to prevent current spikes from PN diode recovery. They do tend to need
chunky inductors to handle all those voltseconds.

Cheers

Phil Hobbs

When people make mosfet substrate diodes, they tend to make them
step-recovery diodes. There must be some semi fab reason for that.

Adding an external schottky catch diode to a spikey synchronous
switcher doesn\'t seem to help.

The extra 5 nH in series with it isn\'t a bad RF choke when you\'ve got
subpicosecond edges. It might be interesting to try a small amount of
inductance in the ground lead (returning all the voltage dividers and
sync pins and so on to that point so as not to dump spikies into the
chip). With the output reservoir cap and catch diode returned to real
ground, one might be able to give the diode time to work.

This is textbook:

https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1

Bottom fet turns off, reverse conducts, and then snaps.

Yeah, the LMR23630 has, like, 600 ps edges. It didn\'t cause problems
until I ran the +13 -> -12 inverting buck off its output. (Going
straight from +24 to -12 is asking a lot of a cute little SOT23
integrated buck switcher.)

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[server]

On Fri, 20 May 2022 11:41:10 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:
On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

whit3rd wrote:
On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote:
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote:


Of course, some people are hostile to ideas.

No sane conscious mind is \'hostile to ideas\' in any more general sense; that
would be pathological, like being hostile to one\'s own body parts.

Oh, lots of people are reflexively hostile to new or unconventional
ideas. Those personalities poison brainstorming sessions.

For those of us who haven\'t experienced poisoned brainstorming sessions,
describe the \'hostility\'. I have grey hair, but cannot recall ever meeting
someone who was \'hostile to ideas\' in general.


You\'ve lived a sheltered life. Back in my early days at IBM Research, I
was in the Manufacturing Research department. It was pretty much a
gizmo-builder\'s paradise--an apparently endless series of hard,
interesting, and economically important problems that needed custom
instruments to solve, pleasant and very smart colleagues, smart and
patient management, and very few budget constraints. A pal of mine from
back then, the estimable Clayton Williams (now flourishing at BYU)
needed a new lock-in amplifier. He was thinking out loud one day, \"It\'s
stupid to buy just one. I probably don\'t need five, so let\'s order
two.\" Two shiny new lock-ins arrived in a few days. If he had needed
five, five would have come instead.

We were entirely self-governed--our budget came out of a big pot at
Corporate, so the folks we were nominally serving couldn\'t really tell
us what to do. Not that doing stuff randomly was encouraged, you
understand, but we didn\'t have the product divisions cracking any whips
that we had to care about. As I said, a great place to build gizmos.

While the customers couldn\'t tell us what to do, there was a certain
contingent of folks who seemed to resent this--apparently they were
happier being able to make vendors dance to their tune. Thus they chose
to throw rocks and tell the folks trying to do stuff that it would never
work, that progress was unacceptable, that the instrument concept was
all wrong, and so on and so forth. Those folks, you absolutely had to
keep out of the planning stage of the project, or they\'d trash you to
their management and often succeed in killing the effort.

There were also folks who wanted to swoop in once the project was on
rails and steal the credit. There was even a select demographic that
habitually did both.

When IBM had its near-death experience in 1992, all those folks were
gone, which was great, but so of course were the lush budgets, which
wasn\'t that great. My time at IBM was like the perfect 21-year
vacation--I was excited to start and excited to leave (as well as scared).

Cheers

Phil Hobbs
It\'s interesting that none of the giant tube companies were long-term
successful in semiconductors. Garage shops killed GE, RCA, Motorola,
Sylvania, and many others.

the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...

Sort of like HP spinning off Agilent spinning off Keysight. Management
couldn\'t keep too many things in their heads at once.



--

Anybody can count to one.

- Robert Widlar