-
Notifications
You must be signed in to change notification settings - Fork 4
Lessons in PCB from previous projects
This is a compilation of PCB design lessons/pitfalls/stuff TDT4295 groups of old have written down in their reports.
Altium project structure
Festina Lente (2011)
- Used multiple schematic sheets. (FL, pg 49)
- What do they mean by this?
- Allowed them to work in parallel.
- Altium issued a lot of warnings due to all appearances of the central components (PSU and such apparently) having the same unique identifier. They disabled the warnings for this transgression.
256SoG (2012)
- Used one monolithic altium sheet.
- Only one person could work on the altium schematic at a time. Other group members made footprints, verified the design and looked up parts in the design sheet (256SoG, pg 36).
Buses/wirelabels, from 256SoG pg 37
We initially worked from the assumption that all pins should be connected to a bus, and then that bus should be connected to the pins in the other end. This gave us some issues with duplicate naming. After digging through quite a bit of Altium documentation, we became assured that simply wire-labeling the pins would create the necessary connections. This is because any pin/wire with the same name as any other pin/wire will be connected by definition in Altium. This arguably made for a less readable schematic, as the bus-connected solution was quite a lot easier to follow when tracing. However, as our schematic still is logically grouped, it is not very hard to find the correct connections even without the buses drawn in. We are quite sure that given a logical overview of which components are directly connected to each other, finding the various pins that perform this connection should be trivial even without the buses/wires drawn in.
Routing and design rules.
From 256SoG, pg 37
Our plan was to start with a big PCB document to be able to easily place all the components. We placed the components and started routing. A lot of the routing was done by the auto route feature of Altium. At first, we did not set any Design Rules. We found that the default rules did not comply with capabilities listed on Elprint’s web page.4. After fixing this, we shrank the board size. The main reason was to reduce production cost, but Tufte also told us that having the board too big could cause short circuits between the power planes.
From 256SoG, pg 40
An example of such a mistake was that we did not set the correct Design Rules before auto-routing, until a few days into the week. This naturally did not give us the routing that we wanted, and gave us a few headaches. Other reasons might be the fact that we did not experiment enough with different routing strategies, and the fact the other group had to route only 1 memory chip, where we had 5. This naturally made the routing much more complex.
Tl;dr: Set the Design Rules to comply with whatever standard/requirements the manufacturer uses (e.g. Elprint)
Also on pg 38 they mention that they perhaps should have used the "Via Mixer" strategy when routing rather than the default routing in Altium.
Soldering
From 256SoG, pg 39
[...] soldering proved to be a bit more difficult than originally anticipated. First, we tested whether there were any short circuits in the board itself. We used the multimeter to test that there was no current passing from one layer to another. Then, we started to solder the power supply, one power plane at time, testing the board for short circuit after each iteration.
[...] we started soldering the AVR and FPGA, as they were the hardest components to solder on the first board. After soldering each side on the AVR and FPGA, we tested the board for short circuits. As no short circuits were found, we moved on to soldering the power supply, as well as the Joint Test Action Groups (JTAGs), FLASH and LEDs. In order to check that the PCB was working, the AVR and FPGA groups tested the PCB without the capacitors
Macaos for the creation of production files
Both FF & 256SoG had their boards printed at Elprint, which uses Macaos.
Development board schematics
From aMac (2010), pg 59
The schematics for the development board [name of old board] has been one of the most important resources for the design of the PCB
So wait what microcontroller are we using? EFM32GG395F1024, apparently. Documentation is available here
Don't mirror the ports. That is, don't use a female footprint and a male mapping or vice versa. See Festina Lente, pg49.
256SoG, pg 40.