2

I graduated with a degree in electrical engineering, but a) I've been doing mostly project management since, b) I didn't get my ADHD diagnosed until after I graduated, and c) I feel like inappropriate emphases were placed on basically every subject during my schooling (treating subjects that are not nearly equal in importance as though they are).

I have a project that I want to realize that will require assembling electric and electronic componentry and a fair amount of programming. I have some general ideas of how I want to proceed, but as for turning those ideas into a reality...I'm at a loss. How do I power my components? How do I detect when they're plugged in? What microcontroller should I be using? Should I be using a dev board? Should I be using an FPGA? How much power am I going to need. I recognize that these are all questions that need to be answered, and I have some idea of how I'm going to answer some of them, but I'm somewhat at a loss as to determining the "best" approaches to doing things.

I'm certainly not asking anyone to answer those questions for me; they're all dependent on what I'm trying to do, etc. What I'm asking is how does one figure out the answers to those questions? How do I know what "things" already exist as components, and what are some ways to evaluate those components in terms of suitability? How do I know the best way to develop the software needed for my project?

John Doe
  • 196
  • 2
  • 20
  • 3
    Generally people spend a few years learning all these things. You say you graduated with a degree in EE. Did you not do any PCB layout, microcontroller programming, power electronics etc? What I’m asking is what do you know? – user110971 Feb 10 '20 at 22:03
  • 1
    Well, one solution is the "research -> prototype -> repeat" track. Pick one section, find some parts you think will work, test them, figure out what worked well and what didn't, and repeat until that section is working how you want it. Then move onto another section. Build it from the power supply upwards, like [Mazlow's Hierarchy](https://duckduckgo.com/?q=maslow%27s+hierarchy+of+needs) but with the power supply on the bottom. – rdtsc Feb 10 '20 at 22:19
  • 1
    Generally you want to start learning one thing, get reasonably good at it and then learn another. If you try to do too many even moderately difficult things at once you will fail. Use what you know works and add a bit to it, copy what you know works and modify it, use building blocks you know work and assemble them to make a new function, and so on. You wouldn't start building your own house if you didn't know a thing about tools, materials, soil conditions, grades, structural engineering, building codes, and lacked virtually every skill (save perhaps one) required to finish the task. – Spehro Pefhany Feb 10 '20 at 22:20
  • 1
    You also need to consider cost and schedule constraints, and which is more important. Are you building a few, or thousands? Do you need the design to be finished quickly? Are you willing to have a more costly product if you can finish the design quicker? – Mattman944 Feb 10 '20 at 22:26
  • 1
    One of the things not mentioned directly so far, which is often an actual difficulty for some (many?) people, is the ability to organize problems into appropriate layers. Some have difficulty here, thinking too abstractly about one thing and too concretely about another and believing that all of these are "at the same level of abstraction" when they most decidedly ARE NOT! Learning the skills needed to properly put things at the same abstraction level together isn't always easy to gain and it results in not being able to really pull together a design because of the confusion from mixing ideas. – jonk Feb 10 '20 at 23:06
  • @user110971 PCB layout, no; microcontroller programming, there was one lab (not even a lecture, just a lab) that was attached to a lecture class that was about x86 and history of computing, which....it's dumb to tie the two of those together AND it was done poorly; power electronics, no. I know C, Verilog, VHDL, some logic design, and some transistor design and theory of operation, aside from Ohm's Law, Kirchoff's, etc. There may be some general topics I'm missing, but that's about the gist. – John Doe Feb 10 '20 at 23:08
  • @rdtsc That seems like a good place to start; do I just make guesses for how much power I'll need? – John Doe Feb 10 '20 at 23:08
  • Even if you can do a proper job of evening up the abstraction layers well, you also need to be able to swim like a fish from one to another, moving almost unconsciously and effortlessly between layers as you consider various problem tests against your layered design concepts to find flaws and adjust to accommodate them. Facility with switching between abstraction domains is also important. But only after you can form them in the first place. – jonk Feb 10 '20 at 23:09
  • @jonk Yes, those things. Also those. – John Doe Feb 10 '20 at 23:10
  • @Mattman944 My idea is to build a working prototype that I can...do...something with. This is something I want to parlay into financial gain, but I have no idea if I want to put in the footwork myself or if I want to try and sell the design to someone else. – John Doe Feb 10 '20 at 23:12
  • Given each subsystem has been done before but overall, you may have a unique interface, write down a list of all Must-Haves for input-functions-outputs and Nice-to-Haves. Then rank and rate your priorities, time, cost, quality, fun, and impact if not met, then research best--in-practise solutions for each to save wasted-time on reinventing the wheel. The best tools are the ones you learn and know how to use. Specs and tolerances are key to defining a perfect design – Tony Stewart EE75 Feb 10 '20 at 23:14
  • @JohnDoe What about digital signal processing, filters (both analog and digital), transmission lines, communication theory (both analog and digital modulation, e.g. FM and BPSK), error detection and error correction coding, impedance matching? Surely you’ve done the Fourier transform? – user110971 Feb 10 '20 at 23:16
  • @user110971 Signal processing, I was focusing on my senior design project and just tried to do the bare minimum, so that one is definitely on me; transmission lines, there was a guy that was in my senior design group that was brilliant, and that *one* class was the reason he didn't have a 4.0 and why he switched disciplines, it was a travesty, and also the class that covered impedance matching; comm. theory, same class as the signal processing, as well as error detection and correction coding. I have done a Fourier transform, but it has been a while. – John Doe Feb 10 '20 at 23:28
  • You didn't have a capstone project? – DKNguyen Feb 11 '20 at 04:01
  • Delegate what you can and investigate what others have gone and done before you, they have found solutions that work and you can improve on them or copy them as is. – KalleMP Feb 11 '20 at 07:20
  • @DKNguyen I did, and I did the PCB design for that as well as programmed a lot of the user interface portions of the design. – John Doe Feb 11 '20 at 17:43
  • @KalleMP Delegate to who? – John Doe Feb 11 '20 at 17:43
  • @JohnDoe To those on your project team that you are managing who have more experience or time for research. If there are none more experienced or you are a team of one you may have the option of outside consultation or the tender charity of electronic club or HackLab members. The shoulders of those who have gone before you are the cheapest source of design information. Patents, service manuals, Open-Source projects, Instructables, blogs and much more. If you have design questions you can even lean on SE if you formulate clear questions. – KalleMP Feb 11 '20 at 18:01
  • @JohnDoe So it sounds more like you just aren't familiar with component selection and equipment, and general circuits to do things. That's pretty normal if you haven't built or researched into a lot of different things (i.e. as work or hobby). – DKNguyen Feb 11 '20 at 18:01
  • @DKNguyen Correct; I understand that there's a bunch of different types of microcontrollers, but I have no idea why I'd choose one over another. I know that there's more than one communication protocol, but I don't know more than, like, two, and I don't know how to decide between the different options. – John Doe Feb 11 '20 at 20:55
  • @JohnDoe Best way is probably just to pick something you want to build and then build it. Even thinking up conceptual designs and picking out parts and roughing out a schematic without actually building it helps you familiarize with what is out there. – DKNguyen Feb 11 '20 at 20:56
  • @JohnDoe I can't stress this enough, as a junior EE R&D engineer my self with 1 year in the field .. Look and read application notes ! And create a good solid product specification. Before you start hacking away.. Draw your architecture and do it nicely !!! And as we say in R&D .. Fail fast! This means prototyping as quickly as possible, and either refine or discard the idea. But don't just hack away, have a plan! – Sorenp Feb 13 '20 at 12:39

4 Answers4

2

How do I know what "things" already exist as components,

Most online electronic component dealers have search engines that will let you browse for components with specs matching your requirements, that is if you don't already know what components to use from years of experience.

and what are some ways to evaluate those components in terms of suitability?

Depends completely on the components and application in question. Actually I would say that knowing how to choose the right design and the right components, and to know what factor are important to your design, and so on, is the main part of what being an EE is, and I would have thought you should have learned a lot of that through your education.

How do I know the best way to develop the software needed for my project?

If you had a degree in Software Engineering you would/should have known that, but I would also have thought that you had learned some of that during your degree. If not then you need to study how to develop the software you need, and then you have to work through it, blood sweat and tears, until you get there.

But what really worries me, is that during your degree you didn't learn how to acquire the knowledge you need to solve problems you haven't solved before.

Vinzent
  • 2,233
  • 5
  • 18
  • RE: right design/right components...yep, me too. Instead it was theory and learning about operation of transistors, each of which being important, of course, but the one class (and I mean *one* class) where the lab consisted of building prototype...stuff was a joke AND it was combined with x86/history of computing. RE: acquiring knowledge to solve problems I haven't solved before, that's literally something I've struggled with my entire life. Perhaps if the ADHD had been diagnosed earlier, it wouldn't've been so crippling. – John Doe Feb 10 '20 at 23:03
  • I promise I'm not trying to make it sound like none of this is my fault, far from it. I could've made more of an effort in a lot of different places. But not know what I needed to know until I got to the end is...frustrating. – John Doe Feb 10 '20 at 23:04
  • Combine that was the fact that, as I said, I've been doing sample preparation and project management instead of any sort of engineering for almost three years, and the stuff that I *did* know has started to leak out. – John Doe Feb 10 '20 at 23:15
  • @John Doe I'm not faulting you for anything, I think many people can relate to how you are feeling, as many universities don't put enough emphasis on the practical applications of the things they teach. People tend to learn how to apply the things they learned during their first employment(s).. "Instead it was theory and learning about operation of transistors" right, but then you should also have learned what things are important when designing a transistor circuit, and what parameters apply to transistors, ie. you should know for example how to choose a transistor for a power application.. – Vinzent Feb 11 '20 at 11:24
  • ..vs. how to select a transistor for an RF application to give an example.. But the best advice I can give you is to just try, try and try again, until you succeed, I can guarantie you that every good EE out there has build dusins of circuits that didn't work before he build something that worked the first time around. And I would also advice you to start with simple projects and to learn everything there is to learn about those before moving on to something more complicated. Start for example by just building some resistor networks, calculate the voltages and currents, and measure them. – Vinzent Feb 11 '20 at 11:28
  • @JohnDoe Btw I can highly recommend "The Signal Path" on youtube, he's a Phd in RF ASIC Design, who works for bell labs, and he does really great, detailed, in depth teardowns and reviews of electronics, a great place to learn some stuff you didn't know already. Also EEVblog on youtube is also good, if you can stand his voice (I can't). – Vinzent Feb 11 '20 at 16:09
  • I'll check that guy out, thanks! Yeah, how to choose transistors for which purposes wasn't exactly covered. I had a class on how to design operational amplifiers, so I have some idea of what 4 different types of op-amps are good for and what they're not good for. – John Doe Feb 11 '20 at 17:45
1

What you are asking about goes by the term “Requirements Decomposition”, or “Requirements Flowdown” and typically falls under the auspices of the Systems Engineering (SE) organization. They have the responsibility for taking a high level systems requirements document (the “shalls”), along with supporting documents such as a Statement of Work (SOW) and turning those requirements into lower level requirements for hardware and software.

Most Systems Engineers that perform this function come up through the ranks of hardware design (power systems, digital, analog, RF, etc) or software and morph over time from being an implementer (CCA or FPGA designer, for instance) to being a specifier – someone who determines the requirements for the power supply or FPGA. Hence most Systems Engineers, or those who operate as such tend to be more senior engineers with 10, 20, or more years under their belts and have the experience base, both good and bad, to be able to decompose and flow down top-level requirements to sub-units.

The current program I am associated with had half a dozen or so people performing this requirements decomposition & flow down function. We had 1 person for the power system, 1 or 2 for the RF potion, 1 for the digital/software, 1 for the mechanical part, 1 reliability engineer, and a couple of other to handle things like EMC compliance and the like.

Because of their background and experience, the SE’s described above are able to come up with a set of implementable requirements for sub-unit designers to use. This is NOT something you could reasonable expect someone fresh out of school with no experience to be able to accomplish.

SteveSh
  • 9,672
  • 2
  • 14
  • 31
  • That actually does make me feel a little better. Because I'm not doing engineering in my day-to-day job, it's difficult to know how much I don't know. – John Doe Feb 11 '20 at 17:57
1

Lets get you started, and build some confidence. Here is a bipolar amplifier, 4 stages, that self-biases (assuming the transistors are "good"), and because there is lots of gain, the final stage will produce lots of random noise you can see on a scope.

The stages are identical. The input to first stage floats, nothing connected, thus will be very susceptible to electric interference from you bringing your hand nearby. Sound like fun? Also a black_brick power supply will provide evil-looking spikes.

Each stage uses 3 resistors and 2 capacitors. And some NPN bipolar transistor. 2N3904?

Use TWO 470Kohm resistors in series from collector to base. Use 10Kohm from collector to +9 volts (or +15 or +6 or +3).

Use the 2 capacitors in 2 ways. One cap from midpoint of 470Ks to ground. And the other cap from base to the prior stage's collector..

The first stage has no input, so one end of its input_cap is floating in the air; this lets you detect electric fields.

If you ground that input, you'll see Boltzman random noise on the output.

====================================

what to expect?

at +9 volts, and assuming the transistor beta is 100, and the transistor leakage is <<< 100 microamps, your collector_ground voltage should be ~~ +4.5 volts.

This circuit is so reliable, you can insert leaky germaniums (PNPs) and you should still have a success --- you'll need to reverse the power voltage.

An isolated stage will have max gain of VDD/0.026 X. Biasing at vdd/2, this becomes vdd/0.052 X because the collector current drops 2:1, and the amps_out/volts_in also drops by 2:1.

At 0.45milliAmp collector current, the Rin will be 0.026/0.45 * beta, or about 5,000 ohms.

thus the inter-stage interaction will be dominated by Rin of the next stage.

Gain will be [10,000 ohms || 5,000 ohms ] * (0.026 amp/volt * 0.45) for each loaded stage. Ignoring Vearly of each device , that appears as an additional resistor in parallel; if Vearly is 20 volts, at 0.45mA, the Rearly will be 40,000 ohms, so you can ignore it.

You should have a gain >>> 1 Milliom, given your 4 stages, and the entire circuit should oscillate because of feedback in the shared VDD.

To stop the oscillation, disconnect one or two of the stages.

Enjoy the random noise.

analogsystemsrf
  • 33,703
  • 2
  • 18
  • 46
1

I would like to see how I would put the requirements into perspective and reach the target. Everything below is hypothetical. It hasn't happened in real life.

Product needed: A board with a LED, a Switch and an UART port to transmit the counts of number of presses.

As a product owner I would gather below information after talking to the customer.

Product Requirement engineering

  1. A small box if size not more than 50 mm x 50 mm x 30 mm.
  2. Should be able to update the software later in the field.
  3. LED color should be Red.
  4. Switch should be ergonomic.
  5. Product should be light weight and meant to be for indoor use
  6. Should run on AA batteries.
  7. Price to be less than 10€.

As a hardware engineer I derived the following requirements (derived requirements, some will be implicit, some will be non functional requirements as well).

Hardware requirement engineering

  1. PCB size not more than 45mm x 45 mm
  2. LED color to be red.
  3. LED Brightness unknown - will be updated after feedback from A sample
  4. Switch type will be momentary type.
  5. will use a low power microcontroller with sleep modes supported.
  6. Two AA batteries - energy assumed is about 800 mAh.
  7. Microcontroller should have atleast one UART port for serial data communication.
  8. I will use a boost regulator to support uniform brightness of LED over battery life.
  9. Will choose enough internal memory so that I can have a backup code and also space for code update in the field.
  10. Microcontroller should have one GPIO to drive the LED
  11. Microcontroller should have second Switch to interface to the switch.
  12. Reverse voltage protection circuit will be placed.
  13. EEPROM with I2C to be selected

As a software engineer, I gathered below basic requirements.

Software requirement engineering

  1. UART required baud rate is 9600.
  2. The LED should be ON for 200 ms.
  3. The UART transmission should happen before the LED is turned off.
  4. The count should be sent as ASCII
  5. The start and stop bits are 1, even parity must be enabled.
  6. The switch is by default open. When it is closed, MCU should detect a low. Hence, internal pull-up is enabled.
  7. Required, internal flash memory and RAM will be estimated soon. Target is 32kB and 2kB.
  8. Target MCU decided is ATMEL after discussing with hardware team.
  9. Software denouncing is enabled.
  10. EEPROM is needed to store the counts.
  11. I2C interface will be used for EEPROM.

As a mechanical engineer, I collected basic information as Requirements below.

Mechanical requirement engineering

  1. Box dimension - 50 mm x 50 mm x 30 mm

  2. LED position is at the centre on the top

  3. Diffuser is needed.
  4. Switch will be placed at the side.
  5. Material of the box will be ABS.
  6. Once closed, the box needed not be opened. Hence, snap fit is chosen.

A Simple design.

Hardware designer will come up with a MCU and also a draft wiring diagram. After review, they go for rapid prototyping and handover the hardware to software team. Software developer will work on the already available dev. Kit and come up with the software and memory usage. They will also test the newly developed hardware and gives feedback to hardware team. Hardware team will also test the timing and DC levels and prepare a basic test report. Mechanical team will prepare a 3D printed board. Everything will be assembled. The A sample will be presented to review Team for feedback.

It will be a collaborative action and even a simple task like this needs a team work. The project cycle experience will come slowly over many such projects. decisions, strategies, contingency plans... Everything will come with real projects.

User323693
  • 9,151
  • 4
  • 21
  • 50
  • 1
    You have inadvertently highlighted several problems with writing good requirements. In the 7 statements you made for a product's requirments, none of them as worded constitute a good requirement. "Should" is more like a desire than a hard and fast requirement. For item 1), a better requirement would be "The box shall not be larger than 50 mm x 50 mm x 30 mm". Item 5) should read more like "The product's weight shall be less than 10 kg." Aso with item 5), you want to avoid having multiple requirements in a single statement, and the term "meant to be for indoor use" is ambigous. – SteveSh Feb 11 '20 at 18:50
  • 1
    Item 4) "Switch should be ergonomic". I don't know how I would verify that. What's ergonomic for me might not be for someone else. – SteveSh Feb 11 '20 at 18:53