Hardware Versus Software
The physical and political sciences of GNSS
Did I mention a great divide back there? Well, it wasn’t the Rocky Mountains I had in mind, nor the Alps. It was the Himalayas.
I am not going to take you on a walking tour of this issue’s table of contents.
Really, I’m not — though that’s what editors so often do when they run out of time or topics to write about. But I will mention some articles that got my thoughts running along this great divide between GNSS hardware and software:
• Mike Braasch’s early interest in software-defined radios described in our new Human Engineering feature this month.
• The matter of hosted versus dedicated processors discussed in a Working Papers column on the future of GNSS receivers.
• Factors affecting battery life for GNSS and multi-function devices addressed in the article by Mike Mathews and colleagues on “Testing the Limits of Power.”
All of these evoke, to a greater or lesser degree, a fundamental engineering question about creating GNSS functionality on silicon or in code — whether we process signals and write instruction sets in stone, so to speak, or on the wind. Well, not the wind, maybe, but at least on an Etch-a-Sketch.
So often dwelling inside the box, engineers might be inclined to — and should be forgiven for — thinking of these matters in purely technical terms, in the physics of hard and soft. The advantages and disadvantages. The trade-offs. The cost/benefits in energy, speed, accuracy, robustness, sensitivity.
Product managers and manufacturers, too, must look to the application, consider the operating environment, and, above all, respect the platform. Does our GNSS get wired into a car or plane or vessel on the high seas? Or is it footloose and battery free?
And always that fundamental question: Is GNSS singing solo or in a chorus? Occupying the driver’s seat or along for the ride? The host or the guest?
Inevitably the former demands obeisance from the latter. Like parents teaching their children not to interrupt when adults are talking, product designers have had to constrain GNSS positioning updates from breaking into the processing of the communications or information for which the platform is primarily intended. And that’s just a lesser example of GNSS sharing the spotlight and available resources.
So, anyway, hardware versus software.
I suppose I could as easily have said GNSS cosmology versus metaphysics. The tangible, concrete manifestation of function inherent in hardware versus the more ephemeral, flexible nature of software — the ghost in the machine, as it were.
But GNSS is not just physical science, but political science, too. The sound bite as much as the kilobyte. Economics as well as ergonomics. The nanometric microcosm, but also the macrocosm of nations and cultures.
How else do we explain the multibillion-dollar infrastructures, the 20-year concession contracts and investment cycles, the memos, programs, posturing, and policy directives?
And into this melee of the microscomic GNSS world writ large strides those national contenders for the future definition of how things will be: China and India.
China and India, right. Hardware and software, right.
To be big and clumsy and over-reaching in our parallels and distinctions: the manufacturing giant, the foundry to the world versus the ingenious, code-writing, tech-support center of centers, the offspring of the Indian Institute of Technology.
Did I mention a Great Divide back there? Well, it wasn’t the Rocky Mountains I had in mind, nor the Alps. It was the Himalayas.
Oh, yes, China has many, many applications software engineers, and India makes lots of electronic stuff, too. And the rest of the world does both.
But, consider this, Mr. Product Manager and Ms. Design Engineer, as you weigh the merits of GNSS hardware versus software: you may not be shaping merely the fortunes of companies but in some incremental way — like laying the cornerstones of the pyramids — influencing the fate of nations.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.