Tag Archives: troubleshooting

Episode 88 — Reddit Questions 2

questionsignWith Brian away on vacation, Adam, Carmen, and Jeff address issues and questions found on the “Engineering,” “Ask Engineers,” and “Ask Electronics” sub-Reddits.

  • Carmen is off on an immediate rant about finding brown M&Ms in his trailer this week, which is apparently a violation of his appearance rider.
  • We discuss needing custom-printed M&Ms for the podcast staff.
  • Since are lacking for an opening question, we turn to the Engineering sub-Reddit for source material.
  • Adam is predicting that humans are ruled by Robot Overlords in the year 2100.
  • A five-minute video about PID control caught Carmen’s attention (Reddit post).
  • Adam has been experiencing integral windup with the water heating unit he has constructed for producing home-brewed beer.
  • An overview of PID control, authored by Bob Pease, is mentioned by Carmen.
  • Carmen also cites a Bob Pease article about fuzzy control.
  • An article about licensing engineers in the state of Indiana is mentioned by Jeff (Reddit post).
  • Adam addresses a Reddit query about what engineering students should bring to college.
  • Jeff prefers the Staedtler Mars-Plastic eraser for correcting his work, while Carmen and Adam are fans of the eraser included in the Twist-Erase III mechanical pencil from Pentel.
  • If you’re going to be using a lot of engineering pad for recording your computations, Adam recommends buying a box (or splitting a case with others) as a Freshman.
  • A good backpack is an important investment for the college student, says Carmen. He recommends the Dakine Campus or Terminal backpacks.
  • Jeff notes that iconic brand McDonald’s is struggling financially, and that Amazon has surpassed Walmart in market capitalization.
  • A troubleshooting saga, concerning a simple room door could mysteriously influence a TV’s reception, entertained Carmen.
  • Do you hate your engineering job? Jeff addresses a Reddit post in which the author is dissatisfied with his engineering career.
  • Carmen mentions that he has recently taken up rock climbing.
  • When it comes to reference books, Jeff’s favorite is Machinery’s Handbook, while Adam prefers the Manual on Uniform Traffic Control Devices. Carmen likes to spread his reading time across a variety of application notes.
  • We discuss a Reddit post asking why some engineers seem to take pride in their lack of spelling and grammar skills.

Thanks to Colin Kinner for the photo titled “Question mark sign.” Podcast theme music by Paul Stevenson.

Episode 74 — Ideas Without Words

lightbulbElectrical engineer Bob Schmidt joins the discussion of how engineers convey important concepts without using words.

  • Beyond writing down a few words to remind him of key details, Brian likes to dive straight into analysis or development when he has a new design idea.
  • Brian often uses LTSpice to analyze electrical circuits.
  • A debate ensues about the importance of being “neat” while making design sketches, and how the purpose of such drawings differs between mechanical and electrical engineers.
  • Our guest for this episode is Bob Schmidt, who previously joined us to talk about “Troubleshooting in Episode 48.” Bob is the author of “An Engineer’s Guide to Solving Problems.”
  • We mull over Chris Gammell’s recent comment (at 9:39 mark) that the NPR radio show “Car Talk” was never specifically about cars, but rather about the process of troubleshooting automotive problems.
  • Jeff shares a troubleshooting story related to replacing a water spigot on the outside of his house.
  • Carmen, Brian, Adam, and Bob take turns telling their own horror stories about plumbing.
  • The importance of eye protection is emphasized by some misadventures endured by Brian and Carmen.
  • Jeff shares a quote by Heather Martin about the relationship between drawing and thinking.
  • Our guest argues that “Ideas with Fewer Words” would be a more accurate description of how engineers use figures and diagrams.
  • Bob is especially irritated by engineers who fail to include units on their graphs.
  • Block diagrams can be useful in organizing thoughts about system inputs and outputs.
  • Jeff shares his experience of trying to implement IDEF0 for documenting manufacturing processes.
  • While whiteboards are good for gathering group input, Bob emphasizes the need to quickly save the results before the whiteboard can be erased, causing critical notes to be permanently lost.
  • Jeff and Bob lament the difficulty of keeping track of one’s ideas over the years.
  • Describing a figure as it is drawn on the whiteboard can help promote a common understanding of the figure’s meaning, claims Jeff.
  • Mind maps can help organize seemingly unrelated ideas and thoughts.
  • Bob creates lists in Excel to capture his ideas.
  • Dan Roam’s book, “The Back of the Napkin: Solving Problems and Selling Ideas with Pictures,” is mentioned by Jeff.
  • Bob and Jeff talk about drawing on paper napkins; is it just an “engineering” thing?
  • Our guest shares his success in using “annotated photographs” to share information with colleagues.
  • Forward looking infrared (FLIR) images have proven useful for Brian in his professional work.
  • Bob notes the growing interdependence of all the engineering fields.
  • Coming out of college, Jeff interviewed with Cray Computer, and was disappointed to learn that they mostly needed help with thermal issues.
  • Jeff shares another troubleshooting story, this time related to his problems establishing good TV reception.

Thanks to Ramunas Geciauska for use of the photo titled “Idea Bulb.” Podcast theme music by Paul Stevenson.

Episode 48 — Troubleshooting

troubleshooting

We talk with electrical engineer Bob Schmidt about troubleshooting in this episode of The Engineering Commons podcast.

  • Please help us improve the podcast by filling out our 2014 Listener Survey!
  • Adam, Brian and Jeff agree that troubleshooting computer software problems can be a frustrating process.
  • Our guest for this episode is Bob Schmidt, an electrical engineer with 40+ years of experience dealing with software, hardware, and system design.
  • Bob obtained an FCC first-class radiotelephone operator license at the age of eighteen.
  • A Motorola 6800 microprocessor provided the computational power for Bob’s first computer, which had 512 bytes of memory.
  • Bob got interested in troubleshooting when he realized he was being specifically paid to deal with problems.
  • We often learn useful lessons through “parables of problem solving.”
  • The Dog Barks When the Phone Rings: An Engineer’s Guide to Solving Problems” is Bob’s new book about troubleshooting. Look for the second edition of the book, which will be published any day now!
  • Another troubleshooting reference is David Agans’ book, “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.”
  • Bob Pease’s book, “Troubleshooting Analog Circuits,” is a problem-solving guide related specifically to electronics.
  • The “five questions” approach that Bob advocates for problem-solving involves asking:
    1. What do you know?
    2. What are the rules?
    3. What don’t you know?
    4. How can you find out the stuff you don’t know?
    5. How do you know when you are ready to solve; or have you already solved the problem?
  • It’s important to write down what you know when beginning to troubleshoot a problem.
  • Our guest feels that clear communication is an important element of the problem-solving process.
  • Carmen references one of Bob’s blog posts, “What Customers Don’t Understand.”
  • We must be attentive to the constraints of people, time, money and results when addressing the customer’s problems.
  • Henry Petroski’s book, “To Engineer Is Human: The Role of Failure in Successful Design,” discusses what can go wrong in engineering projects.
  • In a 2010 presentation for the National Book Festival, Dr. Petroski talked about how the sciences and engineering are treated when successes and failures occur.
  • Our guest feels that studying the designs of other engineers is a great way to get an intuitive feel for potential problems.
  • Carmen references a Jim Williams tale about design titled “The Zoo Circuit: History, Mistakes, and Some Monkeys Design a Circuit.” This case study is told as a chapter in the book “Analog Circuit Design: Art, Science and Personalities.”
  • Not all information on the internet is reliable, as Bob discussed in his recent blog post, “The C.R.A.P. Test.”
  • It makes sense to ask experts for help in problem-solving, but one has to be cognizant of other demands on the expert’s time and attention.
  • An engineer’s physical senses can be quite useful in troubleshooting problems.
  • “Debug by division,” or “divide and conquer,” is a useful methodology for solving problems.
  • Adam discusses how the debug process is applied in road building.
  • Watching others apply the “debug by division” process is useful means for learning the methodology.
  • Bob’s book offers a few “warnings” that should be heeded if you think you’ve successfully solved a problem:
    1. Correlation is not causation.
    2. Your theory of causation had better show good correlation in your experiments.
    3. There might be more than one correct answer.
    4. Undo your fix and check to see if the problem returns.
    5. There can be multiple paths to good solutions. Your way is not the only way.
    6. Never allow a defect or problem report to go by without documenting and fixing that problem.
  • Additional “challenge” questions that one might ask about a possible solution include:
    1. How did other people solve problems similar to this problem in the past?
    2. Good writers of design are good readers of other people’s designs. Are you a good reader?
    3. Could it ever have worked that way?
    4. Does it work that way now?
    5. Are you suffering from optimism bias?
    6. How complete are your checklists?
    7. Are you doing big debug or little debug?
  • Our guest feels that engineering schools should emphasize troubleshooting as an integral element of the design process.
  • Bob can be found on the web at PrettyGoodProblemSolver.com.

Thanks to C├ęsar Astudillo for the photograph titled “Troubleshooting.” Podcast theme music provided by Paul Stevenson.