Week 05 - ecad
group page // repo source files // objectives
Contents
- hero
- projects
- choose your weapon
- COB LED board - Altium
- xiao rp2040 breakout - KiCad
- comparing KiCad vs Altium
hero >
projects >
- cob led board/stamp (altium)
- xiao rp2040 (kicad)
- skeleton comBadge
- usb 2-in-1
- flash storage
- keyboard
- discrete keeb boards
- rng dice board
choose your weapon >
I’ve used Altium professionally for ~6 years, and the last time I regularly used KiCad was when it was ~5.0. It is now 7.0!
COB LED board - Altium >
Like many, I’ve always been fascinated with making things light up.
A part that has been on my mind for awhile that I haven’t gotten a chance to try out is the BXRH-40E0600-A-73, a COB (chip on board) LED, which can be more power-efficient than SMD LEDs and output a lot more light simultaneously.
This LED requires ~175mA, which I can supply in a controlled fashion using the BCR420, a nice LED driver IC that is cost-effective and only requires a single resistor to control current output.
I also wanted to bootstrap the efab process and get a board milled through mods and the JUNYEE desktop mill, so I did a quick layout and ran it through the machine. I used a trace calculator to verify that my trace widths (0.254mm) were sufficient for the current carried (max of 240mA, but ~175mA target); sure enough, more than sufficient (only need 0.0571mm width for external trace).
Based on the finished board, I think I need to beef up the traces; they came out a lot thinner than I expected.
I actually initially routed with pours to make thinking about trace width a non-issue, but from going through fabacademy, I’ve previously experienced clearance issues when pours aren’t configured properly for mods. This may no longer be an issue, but I have yet to experiment.
Missing the components at the moment, so will have to wait until they arrive to verify operation.
workflow >
Altium -> mods -> ugs -> Lunyee
ecad >
As I mentioned, my component libraries were completely corrupted. I used the IPC Batch Import Wizard for the first time. It’s surprisingly powerful; you just need to keep track of a spreadsheet filled with a list of values, which you can then easily import into the wizard which generates the rest. VCS for integrated binary libraries can be problematic at times, to say the least.
I then used the usual suspects (octopart, snapeda, manufacturing search, etc.) to find symbols and footprints for the COB led and driver.
- Screenshot_2023-10-08_164442
- Screenshot_2023-10-08_164835
- Screenshot_2023-10-08_170346
- Screenshot_2023-10-08_170429
Here is my finished route. I started with a pour for the ground, but based on previous issues milling w/ pours generated from Altium, I suppressed it and routed w/ just traces. I also changed the via stackup away from multilayer such that the top and bottom layers are distinct. There are probably better ways to do this, but it’s a quick and dirty way to mill through holes as a separate step in the mill process.
- Screenshot_2023-10-05_002523
- Screenshot_2023-10-05_004658
- Screenshot_2023-10-05_004703
- Screenshot_2023-10-05_004734
- Screenshot_2023-10-05_005510
- Screenshot_2023-10-05_010155
- Screenshot_2023-10-05_010626
Especially when dealing with higher currents, pcb trace calculators are necessary. We have some fun videos back at Molex showing what happens when you use really thin test cables to power an F-150 fan motor.
Using the calculator, I see that my 0.254mm wide traces are sufficient.
After finishing my route, I ran the drc (tdr
hotkey), and found that everything checked out. Typically, you never want to suppress your pour before running the drc, but in this case I did this because I opted not to run the pour-based design for the cnc fab process.
- Screenshot_2023-10-05_002305
- Screenshot_2023-10-05_002316
- Screenshot_2023-10-05_002322
- Screenshot_2023-10-05_002332
- Screenshot_2023-10-05_002451
A neat 3d built-in render. There’s a cool feature where you can exaggerate layers to see what’s going on in-between.
efab >
- mods
- machines -> g-code -> mill 2D PCB
to prep design files from Altium -> mods, there is a bit of a process that I haven’t yet automated:
- Altium
- validate design using DRC (
tdr
) - file -> fabrication outputs -> gerber files
- enable mechanical layers (specifically board outline, which I have as layer 99/board), then click apply
- note that my bottom layer is being used as a throughhole layer for TH header pins; this was an arbitrary but convenient decision for 1-layer boards
- for the following pairs of layers, export as bitmap set to 1000 DPI (
feb
) (we keep board on for all of them to make sure registration between layers is consistent)- top and board
- bottom and board
- board
- validate design using DRC (
- paint.net (or a script)
- for all files:
- resize canvas to add 10px margin to each side
- change DPI to 1000 pixels/in
- for top.bmp:
- invert colors
- apply a 25px wide black border on the canvas
- for th.bmp:
- apply a 25px wide white border on the canvas
- finally, for each of these files, export as .png into the same directory.
- for all files:
- mods
- with the mill 2D PCB workflow, run each file through the workflow. This will be the same order the CNC should be run in, approximately:
- th.png (tabs disabled)
- top.png (tabs disabled)
- board.png (tabs enabled)
- for this Junyee vacuum setup, tabs are necessary to avoid the boards from being sucked into the vacuum
- Neil made a mods module for this, though I found a bug with including the north south directions. proceed w/ caution for the time being and make sure to check the cut route before running
- with the mill 2D PCB workflow, run each file through the workflow. This will be the same order the CNC should be run in, approximately:
- ugs
- find a place on the stock that will likely fit your pattern
reset soft zero
to make sure CNC starts pattern in right place- install correct endmill (in this case, 1/32 for th.png and board.png, 1/64 for top.png)
- make sure to use tools to tighten; hand tightening only usually leads to disaster
- clip alligator to endmill
- (MAKE SURE TO CLIP ALLIGATOR)
- …and zero using Quentin’s macro
- install the foot brush thing
- load the first file (th.png in this case)
- press run
- listening to first ~5 seconds of milling
- turn on vacuum
- turn on/put on ear protection
- wait, rinse, repeat for each tool change/layer
xiao rp2040 breakout - KiCad >
made a really simple route in KiCad for the xiao rp2040. I really dig the new KiCad! they seem to have made installing themes really easy, which is something that was harder in the past (and something Altium still doesn’t support, as far as I can tell).
haven’t run through the mods workflow for KiCad yet, still need to play w/ exporting files there to see what works/doesn’t.
comparing KiCad vs Altium >
KiCad has the benefit of being open-source, source files are text-based, easy to vcs using git, etc. Digikey also officially supports their libraries, so many common components are easily found from the KiCad libraries. It also has a thriving plugin community! The power of open-source and being backed by CERN.
The ergonomics of navigating your project can be a little counter-intuitive at first (something like inverse controls in a fighter pilot game), but once you get the hang of it, it’s awesome! Very snappy and fast, with good keyboard hotkey support. Has python support for stuff like scripting component and track placement.
Altium has the power of the economy and industry support. Similar vibes to this video.
Once you’ve gotten used to KiCad, Altium can feel clunky sometimes, but that’s not the reason I use Altium…
Altium is chock-full of features (I’ll link to some of them, literally too many):
- comprehensive design rule checks for a variety of scenarios
- outjobs
- simulation
- powerful ecad-mcad integration
- support for multi-board design
- high-speed design
- multi-track routing
- bga fanout routing
- impedance matching
- flex-rigid pcb design support
- true 3d MID design support (might finally be out of beta, haven’t tried it yet)
- rooms
- also has hotkey support
- scripting (though it’s not as intuitive as python)
- bugs (so many bugs)
- …and more!
KiCad has some of these features, but definitely nowhere near as many or as comprehensive.
unfortunately found my component libraries totally corrupt recently :(.
The silverlining is that my libraries are overdue for a cleanup!
libraries >
a brief overview of the ECAD library ecosystems from an Altium and KiCad perspective.
libraries are the cornerstone of any circuit design work; unfortunately there are many components out there and as such, no single library is comprehensive for all the components you may need.
- kicad libraries; actually consists of 3 separate libraries that need to be downloaded. consistently receives updates from many users, good coverage, uniform styling.
- footprints,
- symbols, and
- 3d models
- snapeda, ultra librarian, component search engine covers whatever isn’t covered in the kicad libraries
- digikey itself sometimes includes component footprint and symbol downloads, but sporadically
- highly recommend octopart as a good component search aggregate which links to the above component library engines and aslo includes inventory graphs across vendors
- have not tried snapeda’s plugin for kicad yet
- ultimately, although components are pulled from various sources, it’s common to build your own part libraries
- this can be useful for consolidating personally useful components into a single source, which can then be controlled in a git repo
- there are multiple approaches towards organizing libraries, but kicad has a single approach towards library management:
- footprints and 3d models all exist as independent files. a directory of these files is considered a library of the appropriate type
- symbols follow a slightly different approach, where a single symbol.kicad_sym file contains many symbol definitions
on the otherhand, Altium also has a couple of big libraries, but the implementations come in a mixed bag.
- the pre-installed libraries in 23.9.2 (my current Altium version) are more organized than previous versions, but still setup in a way that creates friction in the workflow (this is a whole rant)
- one example: whereas KiCad keeps symbols abstract where possible, Altium’s default approach has been to hardcode each symbol with all the detail from a specific part
- in KiCad,
R
is a single symbol for a resistor that is very barebones and can have its details, like value, case size, be redefined easily on the fly - in Altium,
R
doesn’t actually exist; only something likeChip Resistor, 10 KOhm, +/- 1%, 01 W, -55 to 155 degC, 0603 (1608 Metric)
- in recent times, the Generic Components feature has begun making this paradigm easier to follow, but this wasn’t the standard approach for a very long time
- this is important because often, though there are elements of both top-down and bottom-up design in creating a circuit, a lot of the bottom-up is present in component selection. the less friction there is towards “changing your variables”, the easier design is.
- in KiCad,
- one example: whereas KiCad keeps symbols abstract where possible, Altium’s default approach has been to hardcode each symbol with all the detail from a specific part
- snapeda, ultra librarian, component search engine covers whatever isn’t covered in the kicad libraries
- manufacturer search is not bad. Performance feels snappier than in the past, all the benefits of online supply chain info. Still missing some things
- the celestial altiumlibrary boasts 180k components, but comes as a dblib. I’ve personally found finding parts somewhat laggy.
- SnapEDA plugin has been selectively useful and ended up being my goto choice towards the end of my Molex days, unfortunately there appears to be a bug where all of the font sizes are tiny
- again, the advantage of personal libraries is consolidating and controlling personally useful components
as I played around with online component libraries and the built-in component wizards to generate missing things, I learned that Altium has some nice features I’ve never used (and improved existing ones).
details:
- old
- I’m sticking to the somewhat outdated but familiar .schlib and .pcblib library paradigm (for now)
- new
- IPC component batch wizard feature is awesome; easier to vcs a spreadsheet for import for basic jellybean-type components
- symbol wizard has been very useful