Seeking advice: Getting into entry-level embedded engineering

On Saturday, November 8, 2014 10:05:27 PM UTC-8, robert...@yahoo.com wrote:
> On Sat, 8 Nov 2014 13:52:44 -0800 (PST), edward.ming.lee@gmail.com
> wrote:
> 
> >On Saturday, November 8, 2014 8:30:53 AM UTC-8, robert...@yahoo.com wrote:
> >> On Sat, 8 Nov 2014 07:43:52 -0800 (PST), edward.ming.lee@gmail.com
> >> wrote:
> >> 
> >> >On Tuesday, November 4, 2014 3:32:37 PM UTC-8, Alex wrote:
> >> >> hi Paul
> >> >> > That is a wonderful environment for embedded control systems of all kinds. Thanks for the encouragement! I hope I can make full use of it. I didnt know there was a 6800. 
> >> >
> >> >Then you probably also missed the 6809 and the great 68 vs. 86 debates.  Nowaday, it's ARM vs. x86 or Android vs. iPhone.
> >> >
> >> >Which bring me to my main complaint, things are too complicated.  My mom wants a mobile phone, but she is smart phone challenged.  She cannot even get through the standby click and swipe action.  She can make use of some pre-programmed features, but not a full feature Android.  What we need is a single function dumb phone with hard on-off switch, perhaps like a phone cradle or something with on/off hock.
> >> >
> >> >This would be a good project for someone to learn and tackle the issues.
> >> 
> >> 
> >> There are several phones out there targeting the senior market. Jitterbug appears to be one advertising pretty much just that set of features (big numbers on the screen, big buttons, simple, etc.).  I've never used one, but they do seem to target just that audience.
> >
> >Most of them have micro USB charging, which is another problem on it's own.  Yes, the connector is supposed to go in one way.  But people found way to jam it in the other way.  I have seen physically damaged plug and port to confirm it.  What we need is 4 pins coaxial usb plug that can't go wrong.  
> 
> 
> Probably impossible to make small enough.  And people will figure out a way to break that too.
> 
> >Or big contact pads like cordless phones.
> 
> If we're going to require special hardware, why not go wireless?

Yes, possible.

> Besides, then we have the charger connection standards (you're going to have trouble selling something with a non-micro-USB charging port in Europe, for example).

The cradle itself can still be micro USB, but never disconnected.
 
> >> Amusing anecdote: A few years ago I sent my mom to Europe to visit her family.  Since she was going to be traveling alone, I rented her a phone that would work there, but didn't buy here any minutes.  Just emergency usage, like her cell phone here.  Anyway, she gets there, and calls me that she's arrived.  The call goes to voicemail, which is fine, she can leave a message.  Unfortunately, after the message, she just turns the phone over on the kitchen table.  So the call continues until my voicemail system times out the message after 15 minutes, or so.  Yes, at 95 cents a minute, I have 15 minutes of kitchen noises on my voice mail.  Even better, half an hour later she calls again, again voicemail, again 15 minutes of kitchen noises.
> >
> >Your mom has a good point.  Why can the phone be smart enough to turn itself off when facing down on the table?  A simple photo sensor can do the trick.
> 
> 
> More than a few smartphones can do that, but a photocell would likely be rather difficult to make even semi-reliable - exactly what would it be looking for?

If it's too dark to even see the reflective light from the LCD, then it's likely to be facing down.

> The usual smartphone technique is to use the accelerometers to detect the phone being turned over, and then being left stationary for some time.

Most device detect only H & V position, and get confused about level position.  I don't think they can detect being facing down.
 
> And most cordless phones need you to hit the "end" button too.

But placing them back on the cradle is automatic off (on hook).

edward.ming.lee@gmail.com writes:

> What we need is 4 pins coaxial usb plug that can't go wrong.  Or big
> contact pads like cordless phones.

Already done in the USB 3.1 spec. Maybe in a few years the new USB
connectors will be in phones and other products.

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:6jvt5a9ut94hkhmfdmuukbjldd70snq6sr@4ax.com...

>>Most of them have micro USB charging, which is another problem on it's
>>own.  Yes, the connector is supposed to go in one way.  But people found
>>way to jam it in the other way.  I have seen physically damaged plug and
>>port to confirm it.  What we need is 4 pins coaxial usb plug that can't go
>>wrong.
>
>
> Probably impossible to make small enough.  And people will figure out
> a way to break that too.

I have a tablet with broken micro USB charger socket. The lead gets pulled
sideways if used while charging (this is for kids to use), and eventually it
broke. (The socket twisted, the tiny pins at the back snapped, and it was
too small  to resolder. I only got it charged by soldering Gnd/5V flying
leads nearby, leading out of the case.)

I've seen other people having problems with them too.

But, why does it have to be that small? And since it's only for charging,
why can't the cable terminate in something more reliable, and harder to
insert wrongly, like a co-axial jack?

(I suspect that being able to sell replacement charger boards at &#4294967295;20 a time,
or provide a repair service at &#4294967295;40 a time, or because some people simply
decide to buy a new unit, might have been a good reason for manufacturers to
prefer the delicate micro USB socket.)

-- 
Bartc
 

Hi Alex,

[snips throughout]

On 10/29/2014 5:20 PM, Alex wrote:
> Hi all, I'm looking for advice about being an embedded engineer. I have a BS
> and MS in electrical engineering, an MBA and a certificate in embedded
> systems engineering.

> Since the last year or two I had been trying to get an entry-level embedded
> job and I got a handful of interviews but no offers. Most positions require
> experience. I am passionate about automotive electronics so recently I have
> gotten a test technician job in an automotive audio equipment manufacturing
> facility. They make audio amplifiers and car stereos with navigation
> screens, audio etc.

[These *tend* to be "custom hardware" -- though the hardware may be farmed out
to another firm, etc.  This is significant as many embedded systems jobs
rely on deploying COTS hardware and "writing code" to make it work -- a
very different sort of job than developing the specification for and
design of the hardware that will host your "application"!]

> I am not 100% sure about what I want to do with my
> career and I'm over-qualified for my new job but at least I am closer to
> where I want to be: electronics and probably automotive electronics. I think
> I want to be involved with cars or green energy in some way.

The two have some overlap -- but, can be wildly different!  E.g., residential
photovoltaic systems count as "green" (we'll table that argument, here  :> )
yet have nothing to do with cars.

Note, also, the sorts of markets and the types of "players" that you will
likely encounter in those markets.  E.g., designing car stereos tends to
be a higher volume, more cost conscious market than, for example,
designing MRI scanners.  Or, devices to track cattle on *a* (single!)
rancher's grazing lands (which might be a big job -- but one that only
sees ONE deployment!!)

> I want to be creative, participate in the development process
> and work directly with software and hardware/electronics. The new company
> has another facility in another state that has these types of jobs but like
> for any new type of job I would need to significantly improve my resume.

> Since I don't have actual work experience in embedded engineering, what can
> I do at home? I could do projects but what kinds?

Your best bet (from my personal value system) is to do something that
addresses a need that *you* see.  Ideally, something *for* you!  This
keeps your motivation/interest high/focused (it's not "just a job")
and may push you to come up with more creative solutions -- especially
as they will have to fit within your "means" (financial, skillset,
etc.).

They also show a potential employer that you were willing to invest your
time and talent in something with no direct monetary benefit.  I.e., you
weren't doing it "because it was your job" but, rather, because it was
of interest to you, personally.  You *know* why there was a need -- because
*you* felt the need.  You know what the constraints placed on the solution
were -- because *you* placed them there!  ("Gee, I can't afford to spend
thousands of dollars for a custom circuit board to do this.  Maybe I can
repurpose something that I can easily acquire -- that still meets the
OTHER design constraints that I have imposed?")

And, if it addresses one of YOUR needs, then *you* are far more likely to
actually *use* the "finished design" -- and, be in a good position to
CRITICIZE what you have done right/wrong.  Perhaps even opting to go
back and tweek the implementation or even start over as your experience
with it exposes shortcomings or unanticipated needs!

[Being able to identify the wins and losses in a design is a key part of
the process.  That's how you *learn* and adjust your skillset to new
challenges.]

Your "design/solution" needn't reflect how a *business* would approach
the problem, either!  *YOU* don't have the resources that a business
does so pursuing a similar solution would be foolhardy.  E.g., I like
to track gas mileage on our vehicles as an early indicator that
something may be awry ("Gee, why has my fuel economy fallen so suddenly?")

A car manufacturer (or, a car appliance manufacturer!) might integrate
this into their engine management package and automatically track the
data for you (along with other maintenance activities -- especially
for folks who rely on car dealerships for these services!)  Maybe a
"screen" that lets the user/driver indicate when certain actions
have been performed (that the vehicle can't detect for itself...
maybe it prompts you for the amount of fuel you have dispensed INTO
the tank each time you open the fuel access door?).

My simple solution was to keep a PDA in the glovebox and manually
enter odometer mileage, fuel cost and fuel unit price (lets me
track fuel price variations as well as determine *accurate* fuel
quantity!).  Likewise, all maintenance and repair activities.

And, I can SneakerNet this information to any of the computers
in my house without having to have created a "communication app"
that ran *in* the vehicle!

[Of course, you could do something similar with a smart phone]

Tackling something like this (even this trivial) gives you the
opportunity to speculate about how you would do it "with other
resource constraints -- or lack thereof".  Because, you would
see how you ACTUALLY used the "device" (or, if it was just too
tedious because of its current implementation -- then, why was
it tedious??)

The distinction that I alluded to above (COTS vs. custom) is pertinent
because it refines the markets that you are interested in as well as the
sorts of skillsets that you may want -- or NEED -- to acquire.

E.g., if you are more interested in "programming", then a COTS "module"
that provides the hardware that you need (for a project) -- coupled with
a prebuilt library of routines to access that hardware -- lets you free
yourself of the details associated with the hardware and concentrate
on the software aspects.

OTOH, if you are more interested in programming on bare iron *or*
developing your own hardware, then a COTS approach (and, any market
that will likely follow that development model) will be useless to
you.

> I do have a few ideas for
> my present job to create products that could be helpful for everyone. The
> automotive plant uses a lot of wire harnesses to test amplifiers. The
> harnesses have multiple wires between various connector types. I could make
> a micro-controller based harness continuity checker that connects to a PC
> via USB and tells us which of the wires are broken and need replacement. The
> existing procedure is to use a multi-meter to check individual wires
> manually and a few of them have specific resistances between the connection
> points. The new tool I would make isn't a huge necessity for them but it
> will be a nice exercise for me and it may improve my job prospects later. It
> could be a big project depending on how complex I want to make it. I am
> excited about it and it should be pretty cool when its completed.

Make sure you think this through completely!  By tackling it, you will
(potentially) increase your visibility.  You will be chagrined if you
fail to accommodate some *possible* case that eventually turns up
(e.g., if you assume each conductor has two ends -- and never *three*
or *four*!).

Similarly, if you are expected to actually *implement* the design, your
choice of components becomes critical.  The harnesses that your firm is
probably using are undoubtedly not expected to endure many mating cycles
(how often do people uninstall and then reinstall their car stereo??).
So, the connectors chosen for the harnesses *and* the kit (stereos, etc.)
have probably been selected for that sort of use -- DOZENS of mating cycles?

The natural inclination, when tasked with building your tester, will be
to fetch some spare mating connectors from the stock room and use those
to build the tester!  (i.e., you KNOW they will mate successfully with
the harnesses you are making).

Then, a month or two down the road, you start "detecting" an unusually
high number of "faulty harnesses".  When the harnesses are examined closely,
they discover that the harnesses are PERFECT -- but, the mating connectors
on your tester are now fatigued and your *tester* is the problem!

Ooops!

How is it likely to fail?  (What happens if something is connected to
one branch of a harness that you hadn't expected -- like a power supply
that is ON??)  Can you do things differently to make that less likely to
happen?  Can you design/fabricate it so it can be repaired quickly
and economically?  What if your boss decides he wants/needs a second
one so two different harnesses can be in production at the same time?
Can your "template library" be shared?  Or, does it have to be duplicated??
How do you ensure that "both" copies remain in sync with each other??
And, with the Engineering department's idea of what the harness *should*
be?

You should also consider how the device could *ideally* be used.  E.g.,
should it accept "schematic drawings" (netlists) from the Engineering
department and use that information to drive the tester's configuration
(for this particular wire harness)?  Or, should <someone> be responsible
for typing in some configuration information (a netlist)?  Or, should it
be able to LEARN the current cable harness's configuration (from a sample
template) and possibly feed that information *back* to Engineering (to
create the "drawing" *for* them?)

Should it have the capability of examining a "harness under test" and
telling the operator WHICH harness it is?  (by comparing the results
from its probe() of the sample harness against a library of harness
data that it maintains)?

How should it indicate discrepancies to users?  "Connection X<->Y
is missing"?  "Connection Z<->Q not expected"?  Or, should it do
this graphically (perhaps just highlighting a "missing net" in a
pseudo-schematic)?  I.e., how would this information be most useful
to the folks charged with *fixing* the harness??

Having designed The World's Best Harness Tester, have you *documented*
it?  Or, are you the only one who can use it?  Reproduce it?  Repair it?
etc.

Each of these questions represents an opportunity for you to add value to
your design/implementation.  And, it shows your understanding of The
Organization's (YOUR CUSTOMER) needs and usage criteria.  You didn't
just build a fancy "continuity tester"!

> Another
> idea is creating a special testing unit that looks like the car stereo unit
> and tests the test probes to make sure they are making good contact. I will
> keep thinking about what else I can do. I told my boss about these projects
> to make sure he was OK with them and he was so I'm glad to have his
> approval.
>
> Besides doing projects at home I can also take online training from India
> such as programming in Linux, writing device drivers etc. I will look at job
> descriptions and other resumes to see what I can do to learn those skills.
> Every little bit can help and I am willing to spend any required time or
> money doing these things. I can also buy embedded kits some of which I
> already have left over from the certificate I did.

Don't spread yourself too thin.  Then it looks like you aren't serious
about your real goal but, rather, are doing "anything you can" just to
"get a job".  Find something that you will enjoy and for which you think
a real need exists.

Lastly, think *hard* about your choice of industry:  will you want to be
dealing with car stereos 10 years from now??  (many people get stuck in
specific application domains -- especially if their employer thinks they
are "good" in that role.)  I know many (very well-paid!) people who dread
going to work and are "stuck" due to money, family obligations, lack of
different opportunities, etc.

> I can elaborate more on various things but I wanted to be as short as
> possible to save people's time.
>
> Thanks in advance for any feedback or advice!

Good luck, regardless of the life path you choose/end up with!

On Sun, 9 Nov 2014 07:48:37 -0800 (PST), edward.ming.lee@gmail.com
wrote:

>On Saturday, November 8, 2014 10:05:27 PM UTC-8, robert...@yahoo.com wrote:
>> On Sat, 8 Nov 2014 13:52:44 -0800 (PST), edward.ming.lee@gmail.com
>> wrote:
>> 
>> >On Saturday, November 8, 2014 8:30:53 AM UTC-8, robert...@yahoo.com wrote:
>> >> On Sat, 8 Nov 2014 07:43:52 -0800 (PST), edward.ming.lee@gmail.com
>> >> wrote:
>> >> 
>> >> >On Tuesday, November 4, 2014 3:32:37 PM UTC-8, Alex wrote:
>> >> >> hi Paul
>> >> >> > That is a wonderful environment for embedded control systems of all kinds. Thanks for the encouragement! I hope I can make full use of it. I didnt know there was a 6800. 
>> >> >
>> >> >Then you probably also missed the 6809 and the great 68 vs. 86 debates.  Nowaday, it's ARM vs. x86 or Android vs. iPhone.
>> >> >
>> >> >Which bring me to my main complaint, things are too complicated.  My mom wants a mobile phone, but she is smart phone challenged.  She cannot even get through the standby click and swipe action.  She can make use of some pre-programmed features, but not a full feature Android.  What we need is a single function dumb phone with hard on-off switch, perhaps like a phone cradle or something with on/off hock.
>> >> >
>> >> >This would be a good project for someone to learn and tackle the issues.
>> >> 
>> >> 
>> >> There are several phones out there targeting the senior market. Jitterbug appears to be one advertising pretty much just that set of features (big numbers on the screen, big buttons, simple, etc.).  I've never used one, but they do seem to target just that audience.
>> >
>> >Most of them have micro USB charging, which is another problem on it's own.  Yes, the connector is supposed to go in one way.  But people found way to jam it in the other way.  I have seen physically damaged plug and port to confirm it.  What we need is 4 pins coaxial usb plug that can't go wrong.  
>> 
>> 
>> Probably impossible to make small enough.  And people will figure out a way to break that too.
>> 
>> >Or big contact pads like cordless phones.
>> 
>> If we're going to require special hardware, why not go wireless?
>
>Yes, possible.
>
>> Besides, then we have the charger connection standards (you're going to have trouble selling something with a non-micro-USB charging port in Europe, for example).
>
>The cradle itself can still be micro USB, but never disconnected.


That rather violates the spirit of the charger standard, unless you
make the wireless charging pad itself the new standard, so it's not
tied to a specific device.

 
>> >> Amusing anecdote: A few years ago I sent my mom to Europe to visit her family.  Since she was going to be traveling alone, I rented her a phone that would work there, but didn't buy here any minutes.  Just emergency usage, like her cell phone here.  Anyway, she gets there, and calls me that she's arrived.  The call goes to voicemail, which is fine, she can leave a message.  Unfortunately, after the message, she just turns the phone over on the kitchen table.  So the call continues until my voicemail system times out the message after 15 minutes, or so.  Yes, at 95 cents a minute, I have 15 minutes of kitchen noises on my voice mail.  Even better, half an hour later she calls again, again voicemail, again 15 minutes of kitchen noises.
>> >
>> >Your mom has a good point.  Why can the phone be smart enough to turn itself off when facing down on the table?  A simple photo sensor can do the trick.
>> 
>> 
>> More than a few smartphones can do that, but a photocell would likely be rather difficult to make even semi-reliable - exactly what would it be looking for?
>
>If it's too dark to even see the reflective light from the LCD, then it's likely to be facing down.


So long as you don't take your phone outside on a dark (moonless and
starless) night, and keep it pointed away from anything nearby.


>> The usual smartphone technique is to use the accelerometers to detect the phone being turned over, and then being left stationary for some time.
>
>Most device detect only H & V position, and get confused about level position.  I don't think they can detect being facing down.


My old Galaxy S2 did it (not that I used it, I was just playing with
the features, there was a "turn over phone to hang up" setting
someplace.  I haven't paid too close attention otherwise, so I may be
incorrectly assuming that 3D accelerometers are more commonly
implemented than they are.

On 11/11/2014 12:04 PM, Robert Wessel wrote:
>>> The usual smartphone technique is to use the accelerometers to detect
>>> the phone being turned over, and then being left stationary for some
>>> time.
>>
>> Most device detect only H & V position, and get confused about level
>> position.  I don't think they can detect being facing down.
>
> My old Galaxy S2 did it (not that I used it, I was just playing with the
> features, there was a "turn over phone to hang up" setting someplace.  I
> haven't paid too close attention otherwise, so I may be incorrectly assuming
> that 3D accelerometers are more commonly implemented than they are.

"Turn over to hang up" is a convenience feature.  Saves you the trouble of
pushing a button, swiping the screen, etc.  (because that is *so* tedious :> )

If you want to guard against "unterminated calls", you could just
"listen for <a_very_long> silence" on the local end (you've already got
the transducer to detect sound *and* the horsepower to encode/analyze
it digitally)

Sure, picking a time constant would be a "research opportunity".  But,
not impossible.  And, not likely to be of major consequences if the
phone opts to hang up because you were "away from it" for too long.

[Sort of like motion sensing light switches that sometimes turn off the
lights while you are still in the room -- but motionless!]

On Wed, 12 Nov 2014 13:19:55 -0700, Don Y <this@is.not.me.com> wrote:

>On 11/11/2014 12:04 PM, Robert Wessel wrote:
>>>> The usual smartphone technique is to use the accelerometers to detect
>>>> the phone being turned over, and then being left stationary for some
>>>> time.
>>>
>>> Most device detect only H & V position, and get confused about level
>>> position.  I don't think they can detect being facing down.
>>
>> My old Galaxy S2 did it (not that I used it, I was just playing with the
>> features, there was a "turn over phone to hang up" setting someplace.  I
>> haven't paid too close attention otherwise, so I may be incorrectly assuming
>> that 3D accelerometers are more commonly implemented than they are.
>
>"Turn over to hang up" is a convenience feature.  Saves you the trouble of
>pushing a button, swiping the screen, etc.  (because that is *so* tedious :> )
>
>If you want to guard against "unterminated calls", you could just
>"listen for <a_very_long> silence" on the local end (you've already got
>the transducer to detect sound *and* the horsepower to encode/analyze
>it digitally)
>
>Sure, picking a time constant would be a "research opportunity".  But,
>not impossible.  And, not likely to be of major consequences if the
>phone opts to hang up because you were "away from it" for too long.
>
>[Sort of like motion sensing light switches that sometimes turn off the
>lights while you are still in the room -- but motionless!]


I apparently spend more time in listen-only mode on conference calls
than you do.  In any event, in the case in question, I got a voice
mail (two, actually) with 15 minutes of kitchen noises, so not
silence.