obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First Commit

Browse Source
This commit is contained in:
Claudio
2024-12-02 15:11:30 +01:00
commit 031f6004de
4688 changed files with 441558 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Electronics/Design Process/Development and Documentation Process.md Normal file
View File

@@ -0,0 +1,43 @@
I think the best development and documentation approach is the following:
- README: detailed documentation of everything, version controlled with iterations. We can also have multiple .md files instead of just one.
- requirements
- design decisions
- components search (IC comparison, connectors, etc.
- Bringup instructions
- soldering instructions
- debug instructions
- reference to design documents (e.g. from TI) in resource folder
- Software needed to use the pcb (maybe link to board software package repository)
- gitlab:
- track possible requirements for future iterations as issues tagged with `requirement`
- track issues during reviews --> also acts as discussion for design decisions --> when decision is taken, the issue should be referenced in the README
- confluence: We can also track this in gitlab as CONFLUENCE.md and then import it into confluence
- have a summary of the README that is focused solely on the usage of the pcb.
- should look like a datasheet:
- min max voltage, min max current, etc.
- minimum connections needed
- if needed instructions on how to flash software or use software to program correctly
- Should have a small troubleshooting guide that links to more detailed instructions in the README
- should have a dos and donts section: what not to do at all costs.
- Finally the google drive should be used solely for [[PCB Testing|test tracking]] and detailed test documentation with the templates that we have for development

46
99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Electronics/Design Process/PCB Review Process.md Normal file
View File

@@ -0,0 +1,46 @@
# Process
Generally speaking the review process happens twice, once the schematics are finished, before the design starts and then once the actual PCB-design is done.
## Schematics Review
1. Component selection: do all components fulfill their requirements?
## Board Layout Review
This review happens after the placement of the components is finalized and before routing. The step file of the pcb including all component 3D models should be integrated into the CAD of the device. Also include cables in the mechanical review.
This review should happen between the mechanical team, the assembly team and the electronics team.
1. Is the general shape correct
2. Does the mounting system work?
1. including accessibiliy to connectors or other interfaces when mounted?
2. including stack height when cables are connected
3. are the major subsystems at the correct location on the pcb?
1. Are connectors at the correct location to minimize cable length
4. Revisit component selection: does the component size make sense? Do connector sizes make sense?
Once this review passes make sure that all components are ordered and available.
## Design Review
This review happens after the PCB got routed and is ready for production.
1. Create a PCB Design Review Google Sheet from [this template](https://docs.google.com/spreadsheets/d/1-4jNAzJX_8TotVCinnkB4rk5VresIWIjQV7i3lEITDk/edit).
2. Open the 3D view in Kicad (alt + 3) and review the mechanical properties
1. mounting holes? Stacking height of connectors? Does it fit at the place where it is intended to fit?
2. overlapping components?
3. Does the Silkscreen look right? Is it clear what pad is what? and what connector is what? Polarity?
3. check main ICs first:
1. split PCB into several sections, one section per main IC.
2. double check datasheets and their design recommendations for every IC. and check if the recommendations are applied as accurate as possible
4. Then follow generic checklist for the rest of the pcb review (see google sheets linked below.)
### Production Files Review
Finally the gerber files, drill files and any files that are shared with the manufacturer should be exported and reviewed as well.
# Tools
## Gitlab
We use gitlab, git and Kicad for the design process. This allows us to have a versioning history of the PCBs and collaborate easily across the globe. Gitlab is also a great way to track open features that we need to implement, possible issues we come across or future ideas that might want to be added to a certain board. Within the gitlab issues we can have conversations about a certain decision and they are always in one place to understand the reasoning for a decision even later on. Slack can be used to discuss issues and we can link discussions between the two tools.
Every gitlab project should have a README.md which is the main landing page if someone wants to work with that specific PCB in more depth. (Could we sync the readme with a Confluence article? - [seems possible](https://github.com/zonkyio/confluence-sync/blob/master/README.md) - this would allow non-technical users to have documentation).
## Diff Tool
Since KiCad is open source there are people that build tools to improve the development process. The tool for version comparison that we use is [KiRi (Kicad Revision Inspector)](https://github.com/leoheck/kiri) and we're using it for reviews of later versions to see what has changed since the last iteration.
![[Pasted image 20240129105628.png]]
## Test Tracking Tool
## Google Sheets

6
99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Electronics/Design Process/PCB Testing.md Normal file
View File

@@ -0,0 +1,6 @@
The drone company Freefly has [published extensive testing documents](https://freefly.gitbook.io/freefly-public/products/alta-x/testing/test-documentation) of their drone Alta-X. Basically they have a google sheet that summarizes all tests and some high level information about those test and then there is a detailed test report linked to the main sheet.
![[Pasted image 20240130152623.png]]
I have created a template for both the [overview sheet](https://docs.google.com/spreadsheets/d/1ZVGZX8_EhPCgwdFf9EMEJC3kuFvgf5XS2nXmJZtcvYs/edit#gid=0) and the [detailed test report](https://docs.google.com/document/d/1f-5OXSd6dn2Ha0qU43wb2jsbQDjBMwj65kqMBwrAo80/edit#heading=h.qi86e7v7x1qw) for PCB testing, which can be created at the start of every project. Whenever the designer has an idea of what should be tested, it should be added here immediately.
Obviously this concept can be extended to the the mechanical hardware, the software as well as the entire drone as an integrated test.