How to design good schematics and PCBs?

[4a4ik]

Hello, where I can find good examples of schematics and PCBs ?
There are some hints around the web like:
http://michaelhleonard.com/how-to-design-the-perfect-pcb-part2/
http://electronics.stackexchange.com/questions/28251/rules-and-guidelines-for-drawing-good-schematics

But, where i can find projects examples ? Where I can find open source projects ?
Are there any books you would recommend ?

[tautech]

Other than studying threads in the PCB section
https://www.eevblog.com/forum/eda/

There's quite a bit more in Daves Wiki pages
http://www.eevblog.com/wiki/index.php?title=Main_Page

And more
http://www.eevblog.com/wiki/index.php?title=Online_Electronics_Tutorials_and_Books

Check out the one on PCB layout.


But get some trash PCB's, study them, identify power and signal rails and why things are put where they are.

Start off with simple layouts and post them up for pointers, there's many that can give you good advice. 

[uncle_bob]

Hi

A *lot* depends on what sort of PCB's or designs you are looking at doing. The schematic is a representation of a design. It is a representation in the same way sheet music is a representation of a song. The information is there, what you do to implement it is still very important. The PCB is *part* of the design. The same training and skills that let you do the design, let you do the PCB layout. The real answer to how do do this is to learn how do do designs. While picking up books and just doing a lot of reading is one way, it is likely to be difficult outside an academic (college) environment. In a "basement lab" environment, a cycle of try it and see followed by a bit of research is generally much more useful.

Start out with some demo boards and get them going. Look at what they did and how they did it. Read up on this or that. Try some ideas. See how they work (or not). Once you have gotten past that, try some simple designs on plug in breadboards or perf board. No PCB's no real cost. See how it works. You will learn a lot from that. You will also learn a bit about reading a schematic you wrote down a few weeks ago. That's by far the best way to work out how to do it right

It's all part of a process, study it as a whole, not as a single isolated skill.

Bob

[Chris Mr]

I've always been keen on drawing schematics so they convey the most information about the design as possible.

When you test the design and find things out its a good idea to put those notes on the schematic if it's going to be useful to the reader.  It could be you reading it in a few years time!

Things like representing what you need to do when designing the PCB, from the schematic, can be helpful to others in the future.  For example, if you find you need an extra decoupling capacitor close to the pins of an IC then draw it on the schematic really close to the IC, even using diagonal lines if it makes it more obvious (keeping the physical distance short on the schematic as well as the PCB) so it stands out - because its important.

Like a lot of things, practice is king.  Do a schematic, come back to it in a while and you see things you would do differently now - to make it easier,

[CatalinaWOW]

While it is noble to attempt to make the schematic contain all information about a design, it is a hopeless task.
 
A truly complete description of the design would include a description of the intended function, the performance requirements and a description of the electrical and physical environment it must operate in.  Also included would be the cost goals and expected manufacturing quantities.  These factors would then lead to a description of the design philosophy, that is the description of why the functionality was implemented the way it was.  Next would be the schematic which describes the functional design of the circuit.  In complicated cases this might be done on multiple layers of abstraction.   Then would come descriptions of the physical implementation of the schematic which would include proximity requirements, signal integrity requirements and so on, along with material selections and a specific bill of materials which might also include limitations on the manufacturers used.  But wait, there is more.  The description of factory test requirements and documentation of maintenance, calibration and repair procedures.  This long paragraph is a brief and incomplete description.

Each specialist will look at this list through their own set of blinders and visualize a "complete" schematic meeting their needs.  For simple or non-critical applications one of these incomplete descriptions may even be adequate for most needs.  But a brief look through this forum will show the limitations of these cases.  If complete documentation were available many of the questions would only come from those who couldn't or didn't ROTFM.

[uncle_bob]

While it is noble to attempt to make the schematic contain all information about a design, it is a hopeless task.
 
A truly complete description of the design would include a description of the intended function, the performance requirements and a description of the electrical and physical environment it must operate in.  Also included would be the cost goals and expected manufacturing quantities.  These factors would then lead to a description of the design philosophy, that is the description of why the functionality was implemented the way it was.  Next would be the schematic which describes the functional design of the circuit.  In complicated cases this might be done on multiple layers of abstraction.   Then would come descriptions of the physical implementation of the schematic which would include proximity requirements, signal integrity requirements and so on, along with material selections and a specific bill of materials which might also include limitations on the manufacturers used.  But wait, there is more.  The description of factory test requirements and documentation of maintenance, calibration and repair procedures.  This long paragraph is a brief and incomplete description.

Each specialist will look at this list through their own set of blinders and visualize a "complete" schematic meeting their needs.  For simple or non-critical applications one of these incomplete descriptions may even be adequate for most needs.  But a brief look through this forum will show the limitations of these cases.  If complete documentation were available many of the questions would only come from those who couldn't or didn't ROTFM.

Hi

Well, you nasty engineer.... you have left out all the manufacturing details. Stuff like parts marking, how they are packaged, how they should be inspected to meet the requirements of the part. You also somehow left out the purchasing stuff. Which distributors can each part be bought from. Which manufacturer's part will substitute at each location. Which distributor is the "lead" for each manufacturer. Are the parts purchased directly from the manufacturer. What is the expected lead time on each part .....

Lots of *very* important stuff !!!!

=======

Indeed, there are a *lot* of documents that describe a part. These days, the schematic is generally a non-issue. Nobody looks at it, nobody does anything with it. Once the pcb layout is done, it's archived. Somebody might look at it when writing the test software, then again they might not. In the case that you do the schematic *and* the layout, they get done one after the other. There is very little delay and not a lot of time to forget things. You then validate the process with other tools.

Keep the schematic simple and easy for *you* to read.


Bob

[CatalinaWOW]

I agree, I made only a one word description of that part of manufacturing.  And left things like qualification requirements and design certification and a myriad of other things out.  In the industry I worked the product weighed between 50 lbs up through a couple of tons depending on the model, and the documentation far outweighed the product.  Just a document describing the documentation can run to hundreds of pages.

I agree that the schematic is almost completely a non-issue in the manufacturing phase of a product.  It remains an important part of communicating ideas, in troubleshooting, and in many cases repair. 

[Chris Mr]

It would be beneficial if the OP was answered instead of adding things like product folders, documentation trees, production notes and so on to the schematic level.

A schematic is there as an abstract level to enable the function to be better / more easily understood.

You don't get a world atlas with train timetables on it!