How to tackle your projects - Page 1
Forum section: electronics / beginners

author: QuantumKnight
author_rank: Newbie
timestamp: May 13, 2016, 02:38:09 pm
content: Good day everyone,When designing and implementing your electronics projects, how do you first approach your project? Whether it is simple or complex, is there a start template that anyone uses when working on your project? Do you start from the big picture and work your way down, or do you breakup your project, work on it in pieces and then put it together? I would love information from both engineering professionals and hobbyist. I am sure every has their specializations and not one approach with work for everything. If this is not the correct section or has already been asked, my apologies. Just a beginner looking to pick the brain of experts.Thank you and have a great day!!!

author: Fulcrum
author_rank: Regular Contributor
timestamp: May 13, 2016, 04:53:43 pm
content: Hi!When I start a new project, I go from the top down. I start by thinking about what my circuit will need and try to draw it all in block form. When I have a grasp of which specific parts or blocks my circuit will consist of, I go deeper into detail and figure out how exactly to implement it all. I start by deciding the specifications that will have the greatest impact on other parts of the circuit an then design the rest according to these specifications. I always try to compartmentalize the project and focus on single blocks at a time. This is of course easiest if there is a clear signal path or flow in your project, because then you just start at the first block and work your way up.

author: RandallMcRee
author_rank: Frequent Contributor
timestamp: May 13, 2016, 06:24:05 pm
content: Well, the biggest dissapointment is getting half-way through a big project and finding out that its either already been done, better, or done in some other way that you would have preferred.So to forego this type of "project remorse", a variant I suppose on buyer's remorse, I end up spending a lot of time researching ways to do whatever-it-is. This is always time well spent since the world is vast and us small. The amount of resources others have devoted to whatever-it-is is typically somewhat mind-boggling. So another thing that is important is to manage our expectations, because given our skill level we don't want to bite off more than we can chewBut again, here research is important to find, say, the simplest way to perform a task (especially those tasks that are just in the way of our more important goals--not the goal itself).Thanks for starting this thread, I did not contribute much, but would like to hear what others have to say.

author: sokoloff
author_rank: Super Contributor
timestamp: May 13, 2016, 11:34:56 pm
content: Quote from: RandallMcRee on May 13, 2016, 06:24:05 pm"Six months at the lab bench can save you an afternoon in [the engineering library]..." was a common refrain during my higher-level engineering coursework. Now with Google and the like, it's probably Google rather than the physical engineering library.

author: aurmer
author_rank: Regular Contributor
timestamp: May 14, 2016, 02:59:44 am
content: I have always been told to start with a revised and refined version of your desired specs AND test procedure/requirements. This creates very concrete targets for you to hit as you move through the design process, and every step along the way, you have a test suite in place to run your hardware and software against. And once you pass a test on your list... keep running that test on subsequent updates. You never know when it might break, and having a detailed log of "when it worked" and "when it stopped working" will reduce your time spent troubleshooting and guessing.

author: basinstreetdesign
author_rank: Frequent Contributor
timestamp: May 14, 2016, 06:17:26 am
content: I have always used the following philosophy during my career:I always start with a top-down approach. Even if I can't figure out how it should work at first, I'd sometimes start with a high level block diagram with only one block. Same when writing code too. The block may be labelled "Do Everything" with an arrow that came out the bottom of that block and went into the top of it.Anyway, I first crystallize the specs then start a circuit block diagram from the topmost level and then work to explode each block into several smaller functions as I figure out how it will work. It is during this phase that SW/HW partitioning decisions are usually made. Keep on exploding blocks until the final design becomes more or less obvious then start designing detail circuitry into each of the small blocks from the ground up.The SW guys used to argue this very point at length with adherents in both camps: top-down coding or bottom-up coding. The final answer seems to be top-down design then bottom up coding.Another thing: If there is some part of the design which you cannot figure out then break it off into a black box in your block diagram and turn it into an experiment or side research project on the bench in order to reduce its uncertainty. Do it as soon as you can since it may impact other parts of the overall project.This much is good enough to proceed with if you are the only stakeholder in the project. However if there are others such as a test department, CAD dept, SW writers, etc. then they all need to enter the fray with the usual kickoff/planning meetings to garner their input and to appraise them of what to expect when.Best of luck!