Three photos showed up in my “On This Day” feed. They were taken within an hour of each other and from pretty much the same vantage point. They all tell a different story, each with a unique flavor. It got me thinking about perspective, perception, and prejudice. In day-to-day engineering, as in life, viewpoint, perception, and bias can slow down progress.
San Franciso at sunset
Well, you could say it’s San Francisco at sunset. We see the Salesforce Tower dominating the skyline even though it’s only 1/3rd of the height of The Glass Tower, which graced the SF skyline in 1974 until it burnt down. See the docu-drama The Towering Inferno for details. Joking aside, that really is San Francisco; the Trans Atlantic Pyramid and Coit Tower are now lost among newer structures. The lights on The Oakland Bay Bridge are pale compared to the dockside floodlights at the new ferry maintenance facility, which, from my vantage point on Encinal Beach, float in front of the USS Hornet. The photo could be entitled “Alameda at Sunset” or “The Explorers Return.”
The first place on Earth
So, shortly before that sunset, we can see many more details. This clearly is a photo of the USS Hornet, a famed Cold War vintage aircraft carrier, berthed in Alameda Point and operated as a museum. Maybe the picture is too busy; The Hornet and The City have a comparable share of the image space. It’s almost like looking at a gatefold album cover or a book’s dust jacket, a nearly 2:1 layout, with the ship on the front cover and the city on the back. That sky over SOMA and Dogpatch could be used for the track listing or teaser paragraph.
The shift in focus between the two images is not in the framing, though the daylight image is a little wider FOV (field of view). The change in perspective comes only from the lighting.
So, “First Place on Earth” or “The Explorers Return”? That’s where prejudice or opinion based on pre-knowledge comes into it. The USS Hornet was attached to the Apollo missions. This vessel recovered Armstrong, Aldrin, and Collins from the Pacific Ocean. There is a reasonable-sized exhibit on board about those missions. From the photos alone, you could not know this; all you will see is a man-o-war, a military ship associated with battle, conflict, or peacekeeping.
Fishing
Herons are interesting birds; they have grace and elegance. They are also efficient hunters. There are so many fantastic bird photos; why do we need more? I actually had a co-worker complain about some of my best bird photos. I’m a very opportunistic photographer; I shoot what I see. Sure, I elect where to be, and sometimes I have a mission, but photo opportunities happen. I have two rules of photography.
- Get Lucky
- Have a camera with you
It used to be longer, involving film, extra SD cards, and batteries.
Anyway, by chance, I often come across birds within easy reach of my 200mm lens, and with the sun and clouds as my co-conspirators, photo magic happens! My buddy was a keen amateur ornithologist. He would try to find birds and take their photo. Some of my lucky shots got actions that he never managed. But I digress…
So, what is the purpose of a photo of a heron in front of The Hornet? One fascination I have is nature’s intrusion into the most industrial landscapes. The urban decay of the base is fascinating. California poppies bloom in cracks between concrete slabs. The least terns nest along the old flight line where Mythbuster and The Matrix were filmed. There’s a pontoon where seals bask and doze just a few hundred feet from the shore where this photo was taken.
Peaceful sunset over The Bay, Cold War/Space Race/Aviation history, intersection of nature and industry. All three things are seen from the same place by the same observer, but each reframing by time or composition brings fresh interpretation.
But what about the firmware?
This has been a fun essay so far, but how does this relate to embedded software? I said earlier, perspective, perception, and prejudice. We all approach embedded systems with our own biases. It’s only natural; that’s how we approach life in general.
I’m a British ex-pat living in California. I used to see life here as bizarre. So many things that were just a given in the UK were not even a thing here. I had culture shock moving from Chester to Manchester, so imagine moving from Manchester to The Bay Area.
I studied Computer Science with Applicable Mathematics for my BSc. I started industry writing RISC assembly for an Acorn A5000, then got pulled into writing Mac System 7 GUI code and Motorola assembler for embedded systems. The first time I saw a schematic was at work (okay, first “real schematic”; I did have two Ladybird books, “Build your own Crystal Radio” and “Simple Electronics” in the 70s). I later transitioned into a fabless semiconductor company, working in ASIC Design Verification as well as writing drivers, boot code, and building test fixtures.
In all this flux and evolution, I learnt how to think like and talk with hardware and software engineers, customers, mechanical engineers, RF engineers, ASIC designers, and architects. I see how they all look at things differently. I can anticipate how they will look at a problem, as it naturally fits their discipline.
Most of us frame a problem in terms we are familiar with. If you don’t know something exists, how can you even factor that in as a potential symptom, cause, or cure? So, we use what tools we have. Our point of view and our knowledge will bias our perception of how we see things.
Domain-specific knowledge is great for fixing a specific problem. A depth of knowledge in your specialty brings great value. Narrow fields of knowledge can be broadened and are transferrable to adjacent subjects. Knowing one procedural language allows you to easily tackle another. Being familiar with analog electronics is a gateway to understanding routing issues with a circuit board’s traces or a side step from RF (radio frequency) or audio. Knowing how to code in Python does not naturally lead to turning steel on a lathe.
A broad spread of knowledge will help work in cross-discipline domains. We embedded, especially firmware engineers, have good software knowledge, but not your high-speed search and sort algorithms, database access, or HTML or SQL world. We have excellent knowledge of digital electronics, moving ones and zeros around boards, configuring peripheral devices, and meeting timing budgets. Move us into analog electronics, and we get a bit more lost. We know how to transform discrete digital samples back into curves and waves. Do we know about termination resistors and reflections on high-speed data lines?
So what’s the lesson?
The photos were taken on the same day but with a change of parameters. Maybe any design, implementation, or debugging issue we tackle could use analogous perspective shifts.
Circling back later. If you think I stood on the beach for forty-five minutes waiting for the sun to set, you obviously don’t know how fidgety I can be. I forget what I did, but I will typically cruise around Alameda Point, seeing what construction is going on as the old base takes on its new civilian life. Sometimes, it’s just a matter of moving away from the problem; you come back with a fresh mind. Sometimes, like in the photo, things have changed. A slow memory leak will finally crash the system. You might have an event that is missed one hundred times, and a FIFO is slowly backing up, or the sample read is getting relatively late. As the sun moves, your system’s state changes.
Changing your point of view. No matter how carefully you checked your device configuration and code, you still can’t turn on that external peripheral? Take a look at the board. Yesterday, I moved some C code into a C++ library, testing it in my receiver software running on my primary debug board. When I came to validate the same library integrated into my transmitter software, I ran it on my secondary board. It failed! Since the code had been reworked, I spent considerable time looking for a code issue; that was my prejudice.
I turned it into a HW/SW debug after a few minutes. To confirm my code, I scoped the traces. The signal I saw was familiar but unexpected. Instead of the external oscillator divided down (XOSC/192 output from TI CC1101 if you are curious), I saw what looked like (width and interval) CS#. I checked, and that was it! There was a solder bridge between two pins on the radio chip (CS# and GDO0 for those playing along at home). I had been running that test on only my primary board previously and not my secondary one.
Conclusion
You don’t have to think outside the box, but you should think inside someone else’s box occasionally. Don’t get hung up on an idea; you might be at the wrong starting point. Is your lack of data because of software, board level, cabling, or antenna issues?
Come back to it later; it may look different somehow. System loading, ambient temperature, board temperature, sunspot activity, and atmospheric conditions will mess with things. Your problem may be permanent, only visible after three days of operation, or when a board warms up, like when an “intermittent open” breaks a circuit.
More about the photos and location
I live near Alameda Naval Air Station. It is currently undergoing urban renewal. It is a place of high technology, home to Saildrone and Kairos, and a one-time home to Google-X. It is a place of leisure, with several distilleries, wineries, breweries, and a malting house, all with tasting rooms. You’ve seen it on TV and in films, Star Trek IV, Mythbusters, The Matrix, and others. It is a place for history, with two museums. This airfield was the base of operation for the Pacific Clippers and later the Doolittle Raiders. There is plenty for a photographer to explore, with collapsing buildings, civic art installations, glass-paneled hangar doors, art deco structures, old ships, and planes. I’ve blogged about it on my old blogspot personal and photo blogs.
My Amoeba Sized Bit Of The Web
Glorified Plumbing 