Multi-channel Altium schematics can import with duplicate designators.
A repeated-channel Altium design instantiates the same parts many times, kept apart by a per-channel suffix — C33A, C33B, and so on. A standard Altium → KiCad migration can strip that suffix, so the copies collapse onto one reference and the annotation collides. Crosspad detects the collision against your source, repairs the references back to unique where the channel mapping is recoverable, and re-validates — so a duplicate designator is a finding, not a surprise in ERC.
What does a standard migration do to a repeated-channel schematic?
Altium's multi-channel design lets you draw one channel and repeat it — four ADC front-ends, eight identical power stages — and it keeps every instance's parts distinct with a per-channel designator. A common form is an alpha suffix: capacitor C33 in two channels becomes C33A and C33B. That suffix is what makes each copy a real, separate component with its own place in the BOM and the netlist.
A standard Altium → KiCad migration can strip that channel differentiation. C33A and C33B collapse back onto a single C33 — and every other repeated part with them. The result is duplicate reference designators and inconsistent page numbers across the repeated sheets: distinct components quietly merged into one, in a schematic that still opens.
documentedKiCad #24861Separately, on multi-pad parts the pin designators can arrive as literal text instead of being interpreted — the designator reads as a string rather than driving connectivity.
documentedKiCad #23709
Affected: open · seen in KiCad 10.0.0 / 10.99, still open as of 10.0.6. These are version-specific and get worked on release to release — where a fix ships, this page names the version.
How does this show up on the bench?
You import a multi-channel board and it opens. Then the second-order effects land — because two parts are now one reference:
ERC lights up with duplicate reference designators and annotation conflicts on the repeated sheets.
The BOM is wrong: two distinct parts collapse into one line, so quantities are under-counted.
The netlist is ambiguous where a per-channel net used to be distinct.
Page numbers are inconsistent across the repeated sheets (KiCad #24861).
On multi-pad parts, pin designators show as literal strings instead of driving connectivity (KiCad #23709).
Nothing warned you up front, because the schematic “imported successfully.”
| ELEMENT | SOURCE | AFTER A STANDARD MIGRATION | STATUS |
|---|---|---|---|
| Channel-A parts (C33A …) | repeated channel | collided → C33 | duplicateDUPLICATE |
| Reference annotation | unique per channel | duplicate refs | erc conflictERC CONFLICT |
| BOM line for C33 | two channel copies | one line | under-countedUNDER-COUNTED |
| Multi-pad pin designator | interpreted | literal string | reviewREVIEW |
| Sheet page numbers | sequential | inconsistent | action requiredACTION REQUIRED |
Every repeated part, back to a unique reference — or flagged.
A tracked issue tells you this is possible. It doesn't tell you whether it touched your board. Crosspad reads your Altium source directly, so it knows the channel structure the migration flattened — and it can put the references back.
- 01DETECT
Read the repeated-channel structure from your Altium source and find every collided or stripped designator in the migrated result — duplicate references, lost channel suffixes, pin designators that arrived as literals.
- 02REPAIR — WHERE THE MAPPING IS RECOVERABLE
Where the original channel mapping can be recovered from the source, repair the references back to unique (C33A, C33B rather than a duplicate C33), restoring each part's place in the BOM and netlist.
- 03RE-VALIDATE
Re-parse the repaired board and run the same detection again: no reference is still collided or stripped, the component, track and via counts are unchanged, and net connectivity has not regressed. A repair that fails any of those is rolled back.
- 04FLAG
Where the channel mapping genuinely can't be recovered — or where it can, but the reference would be one Crosspad invented rather than one your source proves — Crosspad flags it as an engineering decision and shows you the mapping it established. Never a silent renumber, never a guess presented as fact.
If Crosspad can't recover the original channel mapping — or if recovering it would mean writing a reference Crosspad invented rather than one your source proves — it flags the collision instead of renaming. Which naming is authoritative is your call, and you get the mapping to make it with. The promise is that every duplicate is surfaced for your project — not that every one is universally solved.
Frequently asked questions.
Why do my designators duplicate after importing a multi-channel Altium project?
Because a repeated (multi-channel) Altium schematic keeps its copies apart with a per-channel suffix — C33A, C33B — and a standard migration can strip that suffix, collapsing the copies onto one reference. The duplicate annotation and inconsistent page numbers are documented in KiCad's tracker (#24861). Crosspad reads the channel structure from your source and repairs the references back to unique where it can recover the mapping, then re-validates.
Can Crosspad guarantee it fixes every duplicate designator?
No one honestly can — where the original channel mapping can't be recovered from the source, the correct reference is genuinely ambiguous. What Crosspad does is make every collision visible for your project: it detects the duplicates, repairs them back to unique references where the mapping is provably recoverable and re-validates, and flags the rest as a decision instead of silently renumbering.
Find out if your channels collided.
Point Crosspad at a multi-channel Altium project and get evidence of exactly which references collided, which it repairs back to unique, and which need a decision.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
RELATED
- All tracked Altium → KiCad import issues
- Migrating multi-sheet Altium schematics to KiCad
- Altium → KiCad migration, end to end
Last updated 2026-08-31. Anchored to KiCad 10.0.6 (2026-08-29). This page is refreshed on each KiCad point release that changes Altium import; the family is scoped to the versions it affects (open · seen in 10.0.0 / 10.99), and sources are KiCad's public issue tracker (#24861, #23709).