Tech Distortion

Engineering Technology Automation Software


Article Categories

The Spark Gap

I don’t often post about other podcasts that I like or that I listen to because I don’t think it’s that interesting a subject. However, every now and then I come across a podcast that I find amazing that I’m really drawn into.

I came across this when doing a vanity search on my own podcast. Thanks to the new Twitter advanced search I found a reference to The Engineering Commons, Pragmatic and something called “The Spark Gap.” The show is hosted by Karl Bowers and Corey Lange who are both Electrical and Electrial/Computer Engineers respectively, much like I am.

Love the name too. When I think of a Spark Gap I think of a radio transmitter and I think of Hertz and the early radio experiments of the late 1800s. Already a regular listener to TEC, I gave TSG a shot, and fell in love with it almost instantly.

I started on Episode 21 about PCB layout: a subject near and dear to my heart. I considered doing an episode of Pragmatic about it but I decided it was too niche and decided not to. Thankfully they have, so now I don’t have to…

Their discussion on decoupling capacitor placement had me fist-pumping the air in heated agreement. Not a discussion I’ve had in years and one that annoyed the crap out of me when I did layout in my early career.

One aspect of capacitor use that they didn’t reference that I came across when debugging one of the designs I worked on, was the use of the capacitor as a current tank. The idea is that certain ICs can have high current draw requirements and that draw spikes particularly at high frequencies. The issue is that power propagating across the power plane might not “travel” quickly enough (due to inherent inductance/capacitance between the tracks) to supply power to that supply pin causing the voltage to drop at the input of the IC momentarily. This can then affect the entire ICs performance, and in the cases I was troubleshooting, lead to data corruption on one of the data buses.

We initially used Tanatalums as current tanks due to their low inductance but eventually switched to low inductance ceramics due to reliability issues Tantalums have especially at high temperatures. That, and the fact that their failure mechanism was typcially quite impressive and destructive whereas the newer chip-ceramics were quite stable albeit physically larger. One of the things we tried hard to do in the dependability team was to drive Tantalums out of the boards.

Another issue they discussed was component layout: Single vs Double Sided and so on. At Nortel we restricted most boards to chip caps, resistors and inductors on the backside of the boards as we found the heavier QFPs moved around on the second pass through the reflow oven. That said, epoxy dots would usually keep the bigger components in place on the backside of the board it was still frowned upon as a general practice.

I digress: What they didn’t talk about was the component physical alignment. Cooling profiles and heat loading for ambient air surrounding the components is also a factor for vertically mounted PCBs and we found that with naturally cooled (not forced fan or ACU) had better long term reliability if the components allowed channelled airflow, similar in concept to tall buildings in the middle of a big city, such that air could flow easily between them and rise unimpeded.

There’s no doubt that this podcast is really in-depth, with the double-episode about PCBs delving into Net naming, power and ground planes, vias and stacks more (get it? Uh…never mind…) with so much really good PCB layout advice that those two episodes alone are a must listen for those that want to improve their PCB layout skills.

That said I realise it’s a niche podcast that may well not appeal to many people. For me though: I’m working my way through now from Episode 1. To Corey and Karl: Great stuff guys!


Tweaking Workflows

Only a few days ago Workflow launched and whilst I’ve never really bought into Editorial, Pythonista or Launch Center Pro (though I’m aware of their collective existences) after creating a simple script to tweak the output of Overcasts tweet URL scheme I decided to solve another problem that’s annoyed me for some time.

One of the problems with Pragmatic is that it takes a considerable amount of effort to research and collect all the links I want to use during the course of most episodes. In some cases I’ve had a page full of links that I traditionally saved using the Safari Bookmark sync.

During the dark period of non-synchronicity between the iOS8 Betas, Yosemite and iCloud Drive (I insanely participated in the Public Beta of Yosemite ignoring in-part my own advice not to) Safari bookmark sync worked intermittently. I resorted to saving links and messaging them to myself, or being stuck to bookmarking items from the desktop only. Whichever way I chose it was inevitable that I would have to export my bookmarks then convert them from HTML into Markdown.

Why Markdown? Well when you blog in tech circles of late, apparently you should use some kind of markup language that isn’t HTML because you know, HTML sucks for some reason and reading raw text in Markdown is easier on your eyes. Apparently. I use Statamic as my CMS which uses Markdown as an option and I decided, one in, all in and converted every last bit of text into Markdown on the whole website.

Tools to convert HTML into Markdown exist in the form of scripts but honestly I had trouble making them work on Mavericks at the time and never bothered to revisit them. Seemed like too much work for little return benefit at the time. I’d rather just start and end in Markdown if I can and never go HTML.

Hence I just shrugged and copied and pasted text and URLs back and forth between HTML and Markdown raw text files while I was listening back to the audio as I edited.

But it still bugged me.

Enter Workflow for iPhone and iPad

Then Workflow happened and after reading Federico Viticcis War and Peace on it I threw cash in the ring and tried it out. In so doing I saw something that caught my eye: “Append to Dropbox File”. I was already using DropBox as my backed-up local filestore for this website (amongst many other things) and figured I should try to append the links to a text file directly in Markdown rather than bother with the potentially problematic Safari bookmark sync. After not a great deal of work I came up with a very simple, single (iPhone 6+ screen sized) workflow to solve my highly specific use-case:


Sharing this with my iPad I now could easily add the URLs I needed in Markdown directly as text for use in the show Markdown file later. But what about the Mac?


Using the Sharesheets is out on the Mac unless there’s an app that already does what you need. Bookmarklets could probably work but an Automator workflow should be fine, and using AppleScript is something I’ve dabbled with before. A few searches around the place and I set up a simple Automator Service workflow that takes no input, is available in Safari and whose AppleScript looks like this:

on run {input, parameters}

    tell application "Safari" to set currentTabURL to URL of the front document
    tell application "Safari" to set currentTabTitle to name of the front document

    set theFile to (((path to home folder) as text) & "dropbox:links.txt") as alias
    set N to open for access theFile with write permission

    get eof N
    if result > 0 then
        set theText to read N
        set eof N to 0
        write theText & return & "- [" & currentTabTitle & "](" & currentTabURL & ")" to N
    end if

    close access N

    tell application "Play Sound"
        play(((path to desktop) as text) & "Laser")
    end tell

    return input
end run

Play Sound is an app that accepts a scripted play/stop/pause and a filename and just plays it. Just to prove the concept I threw a Laser sound effect on the Desktop but you know, use whatever sound, wherever you like. It’s a free filesystem. Even if it is HFS+.


Yes this assumes you use Dropbox to glue it all together but this set up now allows me to keep all the links in the one place for easy addition into the show notes with a single quick copy and paste and no more HTML->Markdown conversion scripts that frankly, seemed a bit inverted anyway.



Taking A Break From Live

In late August I started podcasting live as an experiment. At this time I’m putting Live shows on hold due to the additional overhead it creates and my ever reducing time constraints as I run up to Christmas. I’d rather spend that time on preparation for the episodes.

When time is tight you have to cut something and for the moment that’s the Live recording. To those fans of the show that tuned in live regularly, my apologies for the next few weeks however I do promise to revisit the live shows in early 2015 when the dust has settled.


Should You Choose To Accept It

Twitters recent commentary of their new mission statement (or Strategy Statement) has sparked a minor discussion/derision amongst tech followers that is worth a quick mention. The naming isn’t really that important, whilst some would argue that the vision or mission or strategy statement are all subtlely different documents, the way they are created isn’t and the average employee either can’t tell the difference or doesn’t appreciate whatever subtle differences exist. For these reasons, I’ll talk about “Mission” statements as a generic reference to all such company statements.

Full Disclosure Yes I’ve been involved with developing mission statements in the past and yes my eyes rolled constantly throughout the process each time and I had to close them to prevent them rolling out of my head.

Whether you should choose to accept it or not (Jim), Mission Statements, Vision Statements and the like are common-place in business. It is a widely held belief that they are necessary for a multitude of reasons but primarily to provide a high-level “guidance” to employees that need an employment compass of sorts. Beyond that there’s also the occasional back-room back-slapping between high-level management about how great each others mission statements are.

Mission Statements are developed, usually in long, drawn-out meetings by people wearing expensive suits and ties that are the “decision makers” and “change agents” of the organisation. Typically these people are far removed from the practical execution of day to day work and come from a variety of different backgrounds. Many have not executed practical work (being what the company actually produces as a product or a service) in many years and all of these elements conspire to drive most mission statements to sound the same.

John’s Rules Of Collaborative Fluff Making

Rule 1 More Minds More Dilution

“We absolutely need the VP in charge of XXX involved,” said the CEO, CFO, CIO, CTO etc when selecting who was invited to the corporation direction resolution meeting. Ultimately the balance between enough people and too many people goes well beyond this kind of exercise but with each additional participant, each adds their own ideas and their own take on the mission of the company. Each tries to comprehend or reword each others contributions into wording that “everyone” in the group can understand, diluting its original intent.

Whilst a strong chair can sometime reign this behaviour in and stay focussed more often than not the ideas get diluted down the more people you add. The more dilute the statement becomes, the less value it has.

Rule 2 Diverse Backgrounds Tend to Diverse Statements

Groups that create these statements can come from widly different backgrounds, technical, management and others. Some are engineers, others are project managers by profession, artitects, people with MBAs, marketers, salespeople and so on.

Diversity can be a good thing: giving the group different perspectives on problems. However when it comes to creating a concise, overall direction for a company, the diverse backgrounds drives mutiple diverse statements to accomodate each of their backgrounds and experiences. This drives the statements to be too verbose, too wide or far-reaching and less focussed.

Too often companies end up with a dot-point list with each sub-section given their own dot-point as a way of making sure every background is accounted for. The result is a broad, unfocused, and mostly inapplicable statement to any given employee.

Rule 3 As Distance from Producing Work in the Present Increases So Does Vaguness

Executives and upper management positions are far removed from producing the product or service the company makes and the specifics become lost on them. The counter-arguement is that a direction shouldn’t be too specific and that’s fine, however add in the requirement to think longer term and it’s easy to lose focus on the near term goals of the company.

Someday the company might want to branch out into other businesses and directions and this tends to drive the statement. In some cases that’s the point, but in most cases it creates vagueness and reduces the usefullness of the statement in the present.

Rule 4 Ignorance Corrupts Good Concepts

I’ve had direct, focussed, helpful additions to mission statements scrapped because they weren’t understood by others in the group. Their ignorance dragged the mission back to a “pared back” diluted version of the mission. If the vast majority of the company understands something measurable, like 4-9s availability for example, but several executives don’t, something tangible, measureable and an attainable goal is removed and “will strive to provide 4-9s availability” becomes “will strive to provide industry best practice”.

Some Bad Examples

These are examples of phrases that may have meaning at an executive level but no meaning to anyone else in the organisation, aren’t measurable or useful:

  • Increase shareholder value
  • Aligned around a strategy
  • Great working environment
  • Conduct business in a responsible and environmentally sustainable manner

I have no issue with the idea of a Mission Statement: providing a high-level guidance and setting a compass direction for an organisation is useful to prevent car companies from spontaneously opening gingerbread house confectionary stores even if those houses are somehow in the shape of the cars they make.

For Mission Statements to be useful they need to be specific, actionable and relevant. Unfortunately the way in which they are ordinarily produced in a committee and the people that tend to produce them seems to result in a statement that is watered down, generic and ultimately directionless dribble.


Four Quadrants

All designs consist of components. They can be broken down into smaller and smaller components/elements to the point at which they can be classified in two key aspects (all measures are relative to the overall project cost):

  • Straightforward (Small number of hours to implement and test)
  • Complex (A significant number of hours to implement and test)

Additionally design components and elements can be either:

  • Independent (Element is essentially standalone and does not impact/affect other design components)
  • Interdependent (Impacts one or more other design components)

Think of it like a matrix:

Four Quadrants

1st Quadrant Straightforward & Independent

This is where we the developer/design want to be: The “Yes” Quadrant. It won’t take long to implement it and it won’t really affect anything else we’re trying to achieve on the project.

2nd Quadrant Straightforward & Interdependent

It’s great these features are straight-forward to implement however we need to be mindful of the interactions with other system components before we jump in and start implementing otherwise the implementation could cause a ripple effect of additional retesting and modifications to other design aspects.

3rd Quadrant Complex & Independent

In this Quadrant it comes back to schedule, cost and prioritization issues. Ultimately if there’s enough time and money to implement these sorts of features at least they’re independent enough to not affect other aspects of the product.

4th Quadrant Complex & Interdependent

No matter how you slice it, the answer to these should be either A) we need more time and money to implement this or B) No. No - no - NO!

Key Points

  • Be clear who exactly your customer is
  • Be clear in your feature classifications
  • Be honest about how much effort is required to implement a feature
  • Be Brutal in saying no to the 4th quadrant activities

I also talk about this on Episode 45 of Pragmatic.