You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Patents - A Good Idea?
• The Illusion of Improving Productivity
• A Cheap High-Frequency Probe
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Before inspections there are 4.5 errors per 100 lines of code. After an inspection, expect 0.82 errors per 100 lines of code. Freedman, Weinberg.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

C17 is coming. What's useful in it for embedded work? Here's a summary.

Have uncommitted GPIOs? Here's a "free" ADC you can implement.

Do you have an amazing idea, something that could be The Next Big Thing? Should you rush to the patent office? Here's a great take about the process.

And yet...

Patents are expensive to obtain; figure on $15k to $20k. There are recurring costs. In the USA, the patent office charges $980 after 3.5 years, $2,480 after 7.5 years and $4,110 after 11 years.

There's a bigger question: are you willing to defend that patent when another party attempts to infringe it? Patent litigation is insanely expensive and time consuming. Peter Roberts accused Sears of infringing his socket wrench invention. He spent over 20 years fighting the giant retailer.

If you don't go after the infringer, they can profit handsomely while you get nothing. Unsurprisingly, in this industry patent disputes are common, as companies seek to protect their IP and others infringe purposely or accidentally. The stories are legion. Intel ordered to pay nearly $1B. Intel wins a dispute. Intel loses a battle. The very invention of the microprocessor was mired in suits and countersuits for years.

I've testified in a number of patent suits. Sometimes the claims made by a party are so absurd the court throws the case out. That's great for the patent owner, right? Alas, "thrown out" comes after a lengthly and expensive legal process which involves hiring lawyers ($500 to $2000 per hour) expert witnesses ($300 to $800 per hour), staff, and more. Documents are produced and reviewed and, after months, at least, the court issues its ruling.

But many, perhaps most, don't get tossed and are litigated until either the court or jury makes a decision, or the parties settle. Years go by. Bills come due, payable each month. In one case in which I was involved, each side spent $50 million on legal fees.

The money seems crazy, but companies are incentivized to pursue these cases. They expect to win, and after winning, will generally sue the other side for legal expenses. So, in their minds, there are no costs. Like gamblers who can't imagine not breaking the house, that sure-fire (!) win means their costs are covered.

Unless they are not. In the case I just mentioned, the patent owners lost. A jury, comprised of non-technical people, never understood the pretty deep arguments and made a determination that, to us on the losing side, seemed bizarre.

Sometimes there will be torturous battles over the meaning of a single word. In a process called "claims construction" the parties argue (expensively) over meanings of words or phrases in the patent's claims. Eventually the court assigns definitions. Then, well, the lawyers will sometimes construct new arguments over the words the court has construed.

All while the clock is ticking and bills mounting.

The America Invents Act of 2012 tried to cut costs by introducing the inter partes review, an expedited way to determine if a patent is valid. But "expedited" is a relative term; don't fool yourself into thinking this is cheap.

None of this is to discourage patenting your next big inspiration. A lot of people have made gobs of money from parlaying a patented idea into a marketable product.

But be sure to understand the gritty realities.

What is the secret to increased productivity? Everyone wants to know. Can we boost engineering throughput by 10%? 20%?

Usually, this is a dumb question. We always seem to start without any quantitative productivity metrics, so it’s impossible to know if the team is getting better or worse. In my travels I find few firmware groups that measure anything related to performance. Or quality. There are lots of vague statements about "improving productivity/quality," and it’s not unusual to hear a dictate from on-high  to build a "best-in-class" development team. But those statements are meaningless without metrics that establish both where the group is now, and the desired outcome.

Some teams will make a change, perhaps adopting a new agile approach, and then loudly broadcast their successes. But without numbers I’m skeptical. Is the result real? Measurable? Is it a momentary Hawthorne blip?

Developers will sometimes report a strong feeling that "things are better"” That’s swell. But it’s not engineering. Engineering is the use of science, technology, skilled people, process, a body of knowledge - and measurements - to solve a problem.

Engineers use metrics to gauge a parameter. The meter reads 2.5k ohms when nominal is 2k.  That signal's rise time is twice what we designed for. The ISR runs in 83 usec, yet the interrupt comes every 70. We promised to deliver the product for $23 in quantities of 100k, and so have to engineer two bucks out of the cost of goods.

Some groups get it right. I was accosted at the ESC by a VP who experienced a 40% schedule improvement by the use of code inspections and standards. He had baseline data to compare against. That’s real engineering. When a developer or team lead reports a "sense" or a "feeling" that things are better, that’s  not an engineering assessment. It’s religion.

Metrics are tricky. People are smart and will do what is needed to maximize their return. I remember instituting productivity goals in an electronics manufacturing facility. The workers started cranking out more gear, but quality slumped. Adding a metric for that caused inventory to skyrocket as the techs just tossed broken boards in a pile, rather than repair them.

Metrics are even more difficult in software engineering. Like an impressionistic painting they yield a fuzzy view.

But data with error bands is far superior to no data at all.

How good is your scope probe when looking at fast signals, or those with fast risetimes? Turns out, a decent (think over $300) 10 pF 10X probe at 100 MHz looks like a 160 ohm load! That’s 14 mA at 2.3V, which is more than many gates (not to mention CPUs) can drive. In other words, putting a probe on a perfectly good circuit may cause the system to stop functioning.

But it gets worse as the frequency goes up. In the following graph probe impedance in ohms is shown on the vertical axis and frequency along the horizontal. Impedances are shown for three different probes. Note that 10 pF is pretty common for decent probes; better ones, like Tektronix’s very nice 5 pF TPP1000 approach a thousand dollars. In the following graph, impedance in ohms is on the vertical axis, and frequency in MHz on the horizontal:

Some oscilloscopes will handle signals in the many tens of GHz. I want one of those! But how do you probe a signal that fast? A 5 pF probe will look like a one ohm load at that speed. That’s over 2 amps at 2.3 volts. The answer, of course, is to buy special probes, which run about $30k a pop. A set of four will buy a house in the Midwest.

For those of us working at more modest frequencies, say 50 to a few hundred MHz, one can steal an idea from High-Speed Digital Design by Howard Johnson and Martin Graham.

The probe is simplicity itself. Note that a typical ¼ watt resistor has about 0.5 pF of capacitance. Get a meter of RG-58/U coax. On one end install a decent BNC connector (or, just buy cable with a preinstalled BNC) and solder the resistor (with short leads) to the inner conductor at the far end. Then solder the other end of the resistor to the node being probed, and solder the braid (very short) to a ground near the node. The result looks like this:

(Note the SOT-23 package I’m probing is so small you can’t really see it in this picture, or in real life if you have the slightest myopia).

It’s very important to set your scope's input impedance to 50 ohms, since most scopes default to 1 MΏ or so. If your scope doesn't have a selectable impedance buy a 50 Ώ attenuator (Keysight's N5442A or Test Products International’s 120082, which is $66 from Digi-key).

Now you have a 0.5 pF probe which divides the input by a factor of 21 (i.e., this is a 21X probe). And its performance, shown in the red line, is pretty stunning:

The downside is that this probe isn't as easy to use as one from a vendor. After all, you will have to solder it in place every time it’s moved. An alternative is a commercial low-capacitance probe, which will set you back about five grand each.

Probably the most important take-away here is to understand that everything is part of your circuit. Even humidity can affect sensitive analog designs. And your test equipment is part of the circuit. No scope, logic analyzer or any other device is perfect; they will all interact in lesser or larger ways with your board. Always do an engineering analysis to understand how things will behave.

From Neil Peers who writes: I set myself up as a Hardware Design Contractor approx. 6 weeks ago. Today I looked at the “Snapshot” of the business financials in my accounts package

He continues: Not one of my suppliers has complained about the 100 year payment terms yet which I think is very generous of them.

My negotiation skills are available to your readers for a modest sum.

Christopher Gates sent this:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

These jokes are archived here.

A year after almost failing his high school physics class, a boy told his older brother "You know, my physics teacher was right about the optical Doppler effect. You see those cars? The lights of the ones approaching us are white, but the lights of the ones moving away from us are red."

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.