I’m writing a long-form blog about the basics physics of electronics engineering at RoyalCircuits.com/blog and this time yesterday, I had a problem that needed solving.  An image I created for an article didn’t convey a compelling message to readers.

In my blog, I attempt to explain the concept of “fields” to readers, using the Earth’s gravitational field as an example.  And for that problem, the first graphic I threw together was the one below.  Arrows are spread randomly over the region and the colors are assigned randomly – to give the idea that fields exist at every point.

It works to some extent, but I think we can all agree that isn’t exactly inspiring.  As fate would have it, I had a few uninterrupted hours in the early morning with nothing to do and no one to talk to, so it was a perfect time to tackle the problem and give me the opportunity to make better graphics.  The result of 2 hours and 15 minutes of coding produced the image below with 1600 points.

The arrows are a rainbow of colors that reflect the relative magnitude of the vertical acceleration of gravity at each given point.  Red arrows are -0.25% below mean and purple arrows are +0.25% above mean acceleration.

So I’d like to use this blog post to discuss the path I took to get from the initial image to the final one as well as some of the important “engineering” decisions I made along the way, both good and bad since I feel they apply to the broader field of engineering.  If you’d like to skip the story and jump straight to the lessons, click here.

The Problem

I want to create a 3-dimensional vector field map that shows the gravitational acceleration vectors at various points around the Earth’s surface.  I also want the reader to know the sphere represents Earth.

Manageable Chunks

With the end goal in mind, I have several problems to solve.

1. Source the latitude and longitude coordinates for borders of countries (or continents)
2. Create functions that convert from latitude and longitude to cartesian coordinates
3. Select ~200 evenly spaced points around the Earth’s surface.
4. Source the gravitational field model for the magnitude of acceleration around the Earth’s surface
5. Create functions for arrows that point towards the center of the Earth
6. Generate the 3D image

Getting Started

Not all problems are created equal.  Some problems are easy to solve, and some are impossible.  Figure out which category your problems fall in, prioritize them, and tackle them in a logical order.  For example, if I cannot source the latitude and longitude coordinates for country borders, I have to find another way to solve the problem.  That means there is no reason to write a function that converts latitude and longitude to cartesian coordinates, even though the functions are trivial to write.

Some problems aren’t just difficult to solve, they are impossible.  For example, finding equally placed points around a sphere for the arrows is particularly challenging.  You can’t just generate a table of latitudes and longitudes that ranges from {-90,-180} to {90,180} since the lines of longitude come together at the poles.  That means points placed with 10° spacing at 80° North will be physically closer together than points placed with 10° spacing at 10° North.  I can visualize 2, 3, and 4 evenly placed points on the sphere, but not 5 points.  6 points, perhaps, 8 points certainly, but not 7 points.  I’m not sure about 9-19, but 20 points (Icosahedron) makes sense.  That means there’s a good chance I can’t place an arbitrary number of points on a sphere – I might have to go on the hunt for special numbers or get close enough to even spacing that no one will really notice.

I have a bit of background information in the back of my brain from playing GPS receivers that reminds me the Earth isn’t round – it’s an oblate spheroid (squished sphere), and Vincenty’s formula is superior to Haversine for calculating the distance between two latitude/longitude pairs.  So should I go to the extra work of making the model Earth ellipsoidal?  I’m not sure.

I find the data for both the country border coordinates and the geogravity magnitude without much difficulty and used a spherical transformation.  As a sanity check, I plotted the country borders with randomly selected colors.

Everything seemed fine, so I moved on to write functions that started the arrows that would represent the magnitude of acceleration at an arbitrary height above the surface of the Earth and then end on the surface.  And after all of that that worked, I went on to modify the code to create the ellipsoid model Earth.  You’ll note there’s no appreciable distortion from a circle on the image below.  But there it is, done!  And I have every reason to believe the data is accurately graphed.

Lesson 1:  Write Down the Goals

If you can’t define the problem you’re trying to solve on paper in simple terms, you’ll never get to a specific solution, since any solution will do.  It’s the difference between “going for a drive” and “going to drive to the store.”  In the first case, you’ll waste a lot of gas and perhaps even go in circles.  In the second case, you know where you’re going and know generally how to get there.  Sure you might blow a tire, or encounter a detour – but the end goal is always in mind.

Lesson 2: Make Sure all Goals Are Achievable

When you start your electronics designs, how do you approach them?  A shotgun approach where you tackle problems haphazardly or an orderly system where you start where you can trace a clear path from the beginning to the end?  In my example, if I couldn’t locate the coordinates that defined country borders, my approach wouldn’t work.  I needed that obstacle removed before I could proceed.

Lesson 3: Sleep on It

Engineering is problem-solving, not memorization.  You can’t force the neurons in your brain to make new connections on a deadline.  You have to give them time to work.  I knew the points on a sphere problem would be difficult, if not impossible, for someone of my mathematical ability.  When I took a break in the middle of the night to go back to sleep, I fell asleep thinking about how I’d tackle the problem when I woke up.

Your mind can work on problems even when you’re not consciously thinking about them.  Take advantage of that.  You should think about the hard parts of a problem as soon as possible, even if you don’t have immediate solutions.

Lesson 4: Research

There are a lot of people on Earth and it is difficult to be original.  If you have a problem, chances are someone before you has had that same problem.  When I woke up this morning to solve the n-equidistant points-on-a-sphere problem google quickly confirmed my suspicions and linked me to a youtube video of someone who solved the problem with a bespoke algorithm that solved my problem perfectly.  There were also plenty of resources on StackExchange and elsewhere on the web.

Lesson 5: Perform Sanity Checks

When you see a finished product, such as a bit of code, or a complete circuit board, it is easy to become overwhelmed by the final product.  There are so many details, intricacies, and interwoven ideas that you often wonder how a human is capable of such a feat.  But they didn’t start out in a finished form.  Engineers start with blank slates, and they add part by part, function by function.  It’s necessary to periodically check the product to see if that small part performs the way you intended for it to perform.