[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-93540":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":10,"trendingCount":15,"starSnapshotCount":15,"syncStatus":14,"lastSyncTime":26,"discoverSource":27},93540,"Pinscope","Faradworks\u002FPinscope","Faradworks","A comprehensive datasheet-backed electrical schematic reviewer","",null,"Python",131,21,2,0,11,24,46,78.37,"GNU Affero General Public License v3.0",false,"main",[],"2026-07-22 04:02:09","# Pinscope\n\nPinscope reviews schematics the way a good senior engineer does: with the datasheets open.\n\n\u003Cimg width=\"1912\" height=\"1080\" alt=\"pinscope-screenrecording\" src=\"https:\u002F\u002Fgithub.com\u002Fuser-attachments\u002Fassets\u002F7e9e4002-08df-423f-93c9-eefd52e88700\" \u002F>\n\n\nGive it a netlist, a BOM, and your datasheet PDFs. It builds a graph of your design, reads each IC's datasheet, and checks the circuit around every part against what the manufacturer actually specifies — reference application, pin functions, absolute maximums, recommended operating conditions. Every finding points at the datasheet page that backs it up, so you can judge the call yourself instead of trusting a black box.\n\nThe reason it exists: ERC passes boards that don't work. Your EDA tool has no idea that the CH340E you powered from 5 V drives its TXD at 4.5 V into an MCU pin that maxes out at 3.6 V, or that the net you labeled `UART5_TX` lands on a pin whose alternate-function table only offers `UART5_RX`, or that the LDO's bypass pin you left floating costs you an order of magnitude in output noise. None of that is an electrical *rule* violation. All of it is in the datasheet, and nobody has time to re-read 400 pages per part on every revision.\n\n## How it works\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\"docs\u002Fhow-it-works.svg\" width=\"920\" alt=\"Pipeline: the netlist and BOM are parsed into a design graph; datasheet PDFs are extracted into pin tables and specs; a per-IC review reads both and files findings cited to datasheet pages; the derating table and BOM roll-up are computed straight from the graph, no model involved.\">\n\u003C\u002Fp>\n\n1. **Parse** the BOM (CSV\u002FXLSX) and netlist (PADS-PCB `.asc` or EDIF 2.0.0 `.edn` — exportable from KiCad, Altium, OrCAD, Allegro, Xpedition, EasyEDA, Eagle) into a queryable bipartite graph of components and nets.\n2. **Extract** pin tables and specs from the PDFs. Large datasheets are trimmed to the relevant pages first, and every extraction is cached in a shared library, so a given part number is only ever processed once.\n3. **Review** each IC in isolation. The model gets the trimmed datasheet plus that IC's circuit neighborhood, can query the graph (`find_connected_components`, `get_net_for_pin`, `get_pintable`) and pull pages from a *connected* part's datasheet when a finding spans an interface. It files findings with severity, reasoning, and page citations.\n4. **Compute** the deterministic parts deterministically — BOM roll-up and a capacitor voltage-derating table come straight from the graph, no model involved.\n\nA post-pass normalizes findings conservatively: it can merge duplicates and downgrade severity, never upgrade. If the reviewer hedged, the report hedges.\n\nIt's a reviewer, not an oracle. It misses things, and it will occasionally question a choice you made on purpose — that's what the citations are for.\n\n## Try it on the bundled design\n\n`simple_project\u002F` is a small MSPM0G3507 board with a CH340E USB-UART bridge and an SPX3819 LDO. Run it through and Pinscope flags, among other things, the LDO's bypass pin left unconnected (~300 µV\u003Csub>RMS\u003C\u002Fsub> output noise instead of ~40) and the 5 V-powered CH340E driving the 3.3 V MCU directly — each with the page reference to check its work.\n\nYou need Python 3.12+, Node 20+, and an [Anthropic API key](https:\u002F\u002Fconsole.anthropic.com\u002F):\n\n```bash\npip install -r backend\u002Frequirements.txt\ncp backend\u002F.env.example .env                 # set ANTHROPIC_API_KEY\npython3 scripts\u002Fupload_skills.py --update    # one-time: registers the extraction prompts under your account\npython3 -m uvicorn backend.main:app --reload\ncd frontend && npm install && npm run dev\n```\n\nOpen http:\u002F\u002Flocalhost:3000, create a project, and feed it the netlist and BOM from `simple_project\u002F` plus datasheet PDFs for the ICs — grab those from the manufacturers, or set the optional DigiKey API keys and let it fetch them. Everything runs locally against your own key; projects and the extraction library live in `data\u002F`. Architecture notes are in [CLAUDE.md](CLAUDE.md).\n\n## Hosted version\n\nThis repo is the product minus accounts and billing. If you'd rather not run it yourself, [pinscope.ai](https:\u002F\u002Fpinscope.ai) is the same code, hosted, with team workspaces and a shared parts library that's already warm.\n\n## License\n\nAGPL-3.0. For commercial licensing, write to dev@faradworks.com.\n","2026-07-20 02:30:05","CREATED_QUERY"]