This episode of The Engineering Commons finds the guys discussing the technologies, toys, and tribulations associated with wiring one’s home to the internet.
Carmen is holding off on constructing his own JARVIS (Just A Rather Very Intelligent System) personal assistant until he can construct it using nothing but solder and transistor-transistor logic (TTL).
Neutrino oscillation is a quantum mechanical phenomenon in which a neutrino’s flavor (electron, muon or tau) varies as the neutrino moves through space.
Home automation underwent a sea change when the Nest thermostat was introduced, according to Brian.
Pushing the buttons on early TV remotes (specifically the Zenith Space Commander models) caused aluminum rods to be mechanically struck, thereby producing ultrasonic tones the television tuner could detect. (YouTube video)
We discover why VHF band TV channels go from 2 to 13; and thus why we no longer find Channel 1 on our television sets.
Carmen seems to recall a “documentary” called The Flintstones chronicling the use of dinosaurs to remotely change TV channels.
A sound-activated switch, called The Clapper, first appeared on the market in 1986. TV ads for the device included a “catchy” jingle.
Brian remembers Clapper ads running in series with TV ads for Life Alert, a service that would contact emergency services on behalf of it’s (usually elderly) clients.
Based on the recommendation of a friend, and not having any other reference to guide his decision, Brian started his home automation efforts using the Insteon ecosystem.
One early home networking protocol still in use is X10, which transmits information across power lines.
Split-phase electric power systems, common in the US, cause potential communication difficulties for X10 networks, as signals may not propagate between the two live legs emerging from the transformer secondary (output).
Self-driving cars may have a disruptive effect on the auto insurance industry.
Our guest for this episode is Adam, a traffic engineer who works for a Midwestern state’s Department of Transportation. In addition to being a licensed professional engineer, our guest also co-hosts a popular engineering podcast.
Adam views traffic engineering as having two parts: (a) handling issues related to the design, installation, and maintenance of road signage, signals, and lighting; and (b) being a advocate for drivers as roads are planned and developed.
Pneumatic tubes, laid across the roadway, are but one means for estimating traffic volume.
Economic impact studies can help justify roadway expenditures, as governmental agencies typically receive no additional revenue as a result of improved traffic flows or increased safety.
In this episode of The Engineering Commons, we discuss the lessons we learned during our first two or three years of working as engineering professionals.
Adam considers himself a fast learner, although he finds that pain occasionally increases the rapidity of his learning.
In this episode, Adam, Brian, Carmen, and Jeff discuss lessons learned early in their engineering careers. (The raspy voice belongs to Carmen!)
Carmen learned that organizational change comes slowly, and requires a consistent and concerted effort to alter behaviors and attitudes.
It was news to Jeff that technical issues of great concern to him individually could be of such little concern to his employing organization.
Although Jeff felt he was given a great deal of technical autonomy early in his career, Adam found that his activities were a bit more tightly controlled until he acquired his professional engineering license.
Carmen discovered his job is largely troubleshooting and experimenting, as he is expected to sort out unexpected system behaviors.
Jeff recalls learning that upper-level managers have to make semi-educated guesses about critical business issues such as market size, customer demand, and resource availability.
Survivorship bias can cause us to overlook conditions and situations that may lead to organizational failure.
Brian was a fan of the Zune media player, despite its lack of market success.
One of the best ways to learn quickly, Brian reports, is to chat with others who have substantial experience dealing the technical issues you are trying to understand.
Jeff discovered that vendors are willing to supply technical information, but they expect reciprocity when purchasing decisions are being made.
There can be multiple distributors for a particular product in a given region, and Jeff has irritated a few salespeople by buying goods from the “wrong” distributor.
When meeting with someone who is typically pressed for time, it’s good practice to ask about their availability as soon as your “brief” conversation looks like it might drag out longer than you originally anticipated.
Be cautious about sharing technical problems, Brian notes, as rumor and fear can quickly spread if technical concerns are evaluated outside of their intended context.
Whether you like it or not, says Adam, you have to be aware of (and frequently participate in) the political games of your employing organization.
Jeff notes that answers are rarely found at one’s desk; if you want to learn about a problem, go to the manufacturing floor, or the machine shop, or a customer’s site.
Brian suggests that, whenever possible, engineers should avoid sending emails. On the other hand, Adam finds email a useful tool for documenting agreements with others.
Adam finds meetings to be a particularly effective means for arriving at a decision when multiple people need to participate in the process.
Jeff recommends that young engineers not promise too much, as the desire to please must be balanced by an ability to deliver.
Loading tests on the Boeing 777 wings illustrate delivering exactly what was promised, says Brian.
Brian and Adam mention the “rule of pi” for estimating the time and cost of first-time projects, as discussed in this podcast’s very first episode.
Thanks to Pete for the photo titled “Project 366 #233: 200812 A Sense Of Direction.” Podcast theme music by Paul Stevenson.