It's not just aircraft or cars that don't have an Earth ground--your latest battery-powered mobile "whatever" doesn't have one either. Like I said, "ground" is a very, very mis-used term and one that should not be used, even casually between EEs, unless you really do have an Earth connection. Sloppy terminology here will lead to sloppy thinking and subsequent problems.
I recall we had a similar discussion about the meaning of "ground" on eetimes.com a year or so ago. There are good arguments for using the name "common" or COM or some such thing, but historically most of us use "ground" and signal names like AGND, DGND, etc.
I would tell the student to forget about the whole notion of Earth ground, since it doesn't apply to most of the circuits he will be dealing with, and it really just confuses things. Even in the case where there is an Earth ground connection -- like the electric service panel outside your house -- currents still flow in loops, and the electrons don't just magically disappear into the Earth.
Hi Brian -- As I say, I remember when I was younger trying to find things out -- it amazed me the number of people who wouldn't even respond to an email by saying "Sorry" ... I always make a point of responding, even if the answer is "No, I can't design your final year project for you" :-)
Thanks for posting these Q&As. I really liked some of Bill Schweber's answers.
SNIP ==} Unless you have a connection to earth ground, you should call it “common”
Bill is correct. I usually use signal/node names like GND, AGND, DGND, etc. In the future, I think I'll start considering COM notations.
Regarding your future responses...
SNIP ==} "Ask me your top two questions"
I think in the future you should start off by saying "send me a P.O.". Then, let them send all the questions they want! :-)
Well, okay, maybe your answer is better for a student. :-)
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.