-
Notifications
You must be signed in to change notification settings - Fork 23
Board JSON
Go to Wiki Home.
Go to Explanation data files.
Every board folder in the data tree holds two files that share the same name — one .xlsx and one .json:
Assets/Data/Commodore/C64/250407/
├── Data C64 250407 v2.0.0.xlsx <- the board's text data
└── Data C64 250407 v2.0.0.json <- the board's coordinates (this page)
The short version: the Excel file says what a component is, the JSON file says where it is.
Nothing in the JSON is descriptive. There are no names, no values, no datasheets, no links — it is pure
geometry: the rectangle that lights up when you select U17 in the component list, and the alignment
that makes a KiCad copper overlay sit exactly on top of a board photo.
The app never searches for this file by name. It takes the board Excel path that is registered in the
master workbook (Classic-Repair-Toolbox.xlsx, sheet Hardware & Board, column Excel data file) and
simply swaps the extension for .json — same folder, same base name, every time.
| Board Excel file | Board JSON file the app will look for |
|---|---|
Commodore/C64/250407/Data C64 250407 v2.0.0.xlsx |
Commodore/C64/250407/Data C64 250407 v2.0.0.json |
Amstrad/CPC 664/MC0005A/Data CPC 664 MC0005A v2.0.0.xlsx |
Amstrad/CPC 664/MC0005A/Data CPC 664 MC0005A v2.0.0.json |
Important
If you rename or version-bump the board Excel file, rename the JSON in the same go. Nothing
crashes if you forget: the board still opens, the component list is still complete — but every
highlight on every schematic is silently gone, and the only trace is a single
Board highlight JSON file not found line in the logfile.
In board files from before v2.0.0 this data lived in a Component highlights worksheet inside the
workbook itself. From the v2.0.0 board files onward that sheet is gone and the JSON sidecar is the
only source of truth. If you are looking at an old file, or porting old data forward, that is why the
sheet exists in one and not in the other.
The file has two independent top-level sections ("roots"), both optional:
{
"Component highlights": { },
"KiCad calibration points": { }
}Most boards only have the first. The two are genuinely independent: when the app saves one, it re-reads the whole file, keeps everything else untouched, and writes the roots back in alphabetical order. That also means a future feature can add a third root without disturbing your work.
Three levels of nesting: schematic name → board label → a list of rectangles.
{
"Component highlights": {
"Board layout": {
"C1": [
{ "X": 1448, "Y": 996, "Width": 102, "Height": 36 }
],
"U17": [
{ "X": 2210, "Y": 1512, "Width": 148, "Height": 258 }
]
},
"Schematics #1 of 2": {
"U20": [
{ "X": 3960, "Y": 2854, "Width": 147, "Height": 256 },
{ "X": 1239, "Y": 4032, "Width": 148, "Height": 258 }
]
}
}
}| JSON key | Must match |
|---|---|
Schematic name ("Board layout") |
Sheet Board schematics, column Schematic name
|
Board label ("C1", "U17") |
Sheet Components, column Board label
|
Matching is case-insensitive and surrounding spaces are trimmed, but otherwise the strings have to be identical. A label that exists in one file and not in the other is an orphan, and the built-in data validator writes a warning for it in both directions:
Excel data file [...] sheet [Components] has an orphan component [C42] that does not
exist in JSON file [...] property [Component highlights] - please fix!
JSON file [...] property [Component highlights] has an orphan entry component highlight
[C42] schematic [Board layout] because component [C42] does not exist in sheet
[Components] - please fix!
Orphans are the most common defect in contributed board data, and they are cheap to find — run the app once with your data and read the logfile.
X, Y, Width and Height are pixels in the full-resolution image for that schematic (the file
named in Board schematics → Schematic image file), with the origin at the top-left corner.
- They are not percentages, not screen pixels, and not relative to your current zoom. That is exactly why the same numbers work in the main view, at any zoom level, and in the thumbnails.
- They are always whole numbers — the editor rounds when it saves.
- Consequently: if you replace a schematic image with a scan at a different resolution, or crop it, every rectangle on that image becomes wrong. Re-cropping an image is a re-labelling job, so get the image right before you start drawing.
The value is a list, not a single object. If a component appears twice on the same sheet — a chip drawn
in two places on a schematic, a part mounted on both sides — give it two rectangles, as U20 above.
They highlight and blink together as one component.
There is no region field here, and you should not fork rectangles per region. Region lives on the
component row in the Excel Components sheet, and the rule is:
- Component row has a blank
Region→ highlighted in every region. - Component row names one or more regions → highlighted only in those.
One label, one set of rectangles; the Excel row decides whether it is drawn.
When the app writes this file it uses two-space indentation, sorts the roots alphabetically, sorts board
labels naturally (C2, C9, C10 — not C1, C10, C2), and sorts the rectangles inside a label
top-to-bottom then left-to-right. The file is UTF-8 without BOM; line endings follow whichever OS saved
it, which is harmless.
Reading is completely order-independent, so a hand-written file in a different order still works. But if you reformat or re-sort by hand, the next save from the app puts it all back, and your contribution then shows hundreds of changed lines that are not actually changes. Let the app own the formatting.
Only present for boards that ship a KiCad data/ folder. One entry per schematic view, recording how the
KiCad geometry has to be stretched to sit on top of that particular image:
{
"KiCad calibration points": {
"Top (replica)": {
"CadName": "250407_ - PCB Top",
"OffsetX": 50.87193460490473,
"OffsetY": 451.9972752043597,
"ScaleX": 0.9769080633767282,
"ScaleY": 0.812766517468314,
"MirrorX": false,
"MirrorY": false
}
}
}| Field | Meaning |
|---|---|
CadName |
Which KiCad view this image was matched against, e.g. a PCB layer or a schematic sheet |
OffsetX / OffsetY
|
Top-left corner of the calibration box, in image pixels |
ScaleX / ScaleY
|
Box size ÷ full image size (1.0 = the box covers the whole image) |
MirrorX / MirrorY
|
The box was dragged inside-out — used when the image shows the board from the other side |
These numbers are the result of dragging a box in the app until the copper lines up with the image, so they come out with fifteen decimals and are meaningless in isolation. Do not hand-edit them. If an overlay drifts, redo the calibration; it takes a minute and it is the only reliable way to get it right.
This file is written by the app. Editing it by hand is possible, but it is not the intended workflow and it is very easy to produce something that is valid JSON and still wrong.
- Schematics tab → in the settings panel, tick Enable contributor mode.
- Right-click the schematic image (a click, not a drag) to open the floating menu.
- Choose Enable component label editor (or Calibrate KiCad traces for the KiCad root).
- Drag to draw a rectangle; drag the handles to resize; drag the middle to move; right-click a rectangle to delete it. A brand-new rectangle asks you for a board label and a category.
- Press Apply all editor changes.
What that save actually does:
- Writes the highlights for the currently selected schematic only — every other schematic already in the file is preserved untouched.
- Appends a row to the Excel
Componentssheet for any board label that did not exist yet. If you introduced no new labels, the workbook is not touched at all. - Refuses to save, with a message, if a rectangle has no label, no category, or zero size, or if the same label was given two different categories.
If the board's Excel file is open in another program the workbook half of the save can fail — close it and try again.
🎬 There is a walkthrough video: How to use component label editor
| What you see | Almost always means |
|---|---|
| No highlights at all on a board, everything else fine | JSON missing, renamed out of sync with the .xlsx, or malformed — check the logfile |
| One component never highlights | Label typo (join mismatch), or its Region in the Excel excludes the current region |
| Highlights land on the wrong schematic, or nowhere | Schematic name key does not match Board schematics → Schematic name
|
| Every rectangle on one image is shifted or scaled | The image was replaced or cropped after the labelling was done |
| KiCad copper drifts away from the image | Calibration is stale — recalibrate that view |
| "Orphan" warnings in the logfile | Excel and JSON disagree about which components exist |
A missing or broken JSON never blocks the app. It logs a warning, treats the board as having no highlights, and carries on — convenient at runtime, and easy to miss while contributing. Read the log.
-
Ship the
.xlsxand the.jsontogether. They are one dataset in two files, and reviewing either one alone is meaningless. - Keep the base names identical, including any version suffix.
- Let the app write the JSON. Do not reformat, re-sort or pretty-print it by hand.
- Run the app once against your data and read the logfile before submitting — orphan components, duplicate UUIDs and missing files all show up there.
- Do not put descriptive data here. Names, values, part numbers, regions, links, credits and oscilloscope baselines all belong in the Excel file.
The board JSON is part of the online data manifest and is checksum-synced from
classic-repair-toolbox.dk like any other data file — independently of application releases. At startup
the app syncs the master workbook and the board Excel files first; the board JSON arrives with the
background pass that fetches the remaining data files shortly after the window opens.
While a board of your own is registered in your personal contribution workbook, that board's Excel file,
its JSON sidecar and its whole KiCad data/ folder are protected: the sync will not overwrite them,
and the orphan cleanup will not delete them. Your work in progress is safe from the server's copy.