Following are set of resources that I recommend for my students to gain good understanding of the fundamental concepts required in our research.

Circuit (or any system) design advice: I recommend the following approach for any system/circuit design: (Click to read)
  1. Who is the user and what is your product? Finalize what your system will look like, and who will use it. Your potential users will offer you the best feedback on defining your product. (Balsamiq, Xmind, Inkscape are useful softwares for this ideation phase.)
  2. Calculate the specifications required to meet the application requirements.
  3. Do not reinvent the wheel! Select components based on the specifications, and follow application notes and technical documentation to start building the system. Read through data sheets; you will learn a lot from a well written data sheet. (Print out datasheets and browse through the pages; it is more effective in teaching you something new as compared to Ctrl+F shortcut in a pdf file.)
  4. Design for test. While coming up with the design, ask yourself how you will test and verify performance and functionality. Add sufficient test points. Extra test points in the initial iterations never hurt anybody.
  5. Have a design review. Never start implementing the project without first reviewing the design on paper with colleagues and peers. Be prepared with back up calculations and supporting simulations and data. (Make an effective presentation, and do not be afraid to mention the flaws and concerns at this stage. It will save you much hardship later if you talk about and resolve any bugs at this stage. Draw neat circuit diagrams and block diagrams using Xcircuit, Ycircuit or Microsoft Visio.)
  6. Debug while you build. This is as true for hardware as it is for software. Keep testing and verifying individual blocks before you integrate them.
  7. Document while you build. This is perhaps the most important step in the process. If you do not document your project, it is as good as not having done one. Document the positives and negatives. Document all possible thoughts and observations. (Preferably use Latex, as it will make writing papers easier later.)
  8. Have a test review. Before you go for another iteration of the hardware, review your test data with peers and colleagues to identify what did not work and how you will fix it.
  9. Repeat! (Transitioning from proof of concept to prototype and then onwards to production requires a design for manufacturability approach. While this is not essential while you are working on proof of concept, it must definitely be taken into account when you are transitioning to prototyping.)

Resources available at IIT Bombay