diff --git a/hardware/README.md b/hardware/README.md
new file mode 100644
index 0000000..859a835
--- /dev/null
+++ b/hardware/README.md
@@ -0,0 +1,45 @@
+# HSC26 Artemis 2 Hardware
+
+The schematic is included as a PDF.
+
+Gerbers and other files will come later. Contact me if you want them.
+
+
+## Known Hardware Bugs
+
+### REV1
+
+- The voltage regulator is a bit weak, so many LEDs on at once can cause white to drop out.
_(true, 20260509_)
+ - This still needs to be investigated, but it is assumed that the boost regulator cannot supply enough current. However it could also be too low value of a polyfuse, or a polyfuse with too high series resistance causing problems. (I measure nearly 4 ohms on both F1 and F2)
+ - The maximum practical instantaneous power consumption was assumed to be ~50mA but with many LEDs lit at once this design is probably breaking that limit.
+ - This has implications for the addon connector: additional load from addons may cause dropouts of the badge boost regulator causing malfunction of the badge.
+ - With HSC26 release firmware, it is possible to cause white LEDs to drop out if the battery is low enough or if the brightness is turned up.
+ - This will be mitigated in future firmware with more power optimized programs, as well as programs that take advantage of knowing ambient light level.
+
+
+
+- Power is switched by switching the GND node for both the battery and USB. This works fine for battery, but when plugging in USB with the power switch off, the device becomes powered even if the power switch is off.
_(true, 20260509_)
+ - Right now it is assumed that a USB PD CC line is the ground return path. The USB CC lines are run to the MCU as I wanted to play with the USBPD peripheral.
+ - When in this state, the bootloader function does not work properly.
+ - **Workaround**: Remove the battery switch and set the power switch to ON in order to update firmware with the factory bootloader.
+ - **Resolution**: Future runs of this badge will likely eliminate the USB PD lines to the MCU altogether and use external pulldowns instead, and/or power switch will switch the high side (3V3 net) instead of low side. There is no real need of the USBPD peripheral in this design.
+ - Future firmware will likely have another activation method for entering the bootloader during normal operation, seeing as the power switch won't really work anymore when plugged in.
+ - To anyone implementing CH32X035 MCU: it is advisable to use a solution to physically switch out USB PD lines (such as with MOSFETs) unless main firmware is running, as the USB PD lines don't work as expected unless the USBPD peripheral is configured. You may also want to implement your own bootloader that configures USBPD since the factory bootloader does not (and how could it, not knowing the design power sourcing requirements?)
+
+## Testing
+
+- USB LDO: **Tested OK**
+- Reverse polarity protection: **Tested OK**
+- MCU: **Tested OK**
+- LED Driver: **Tested OK**
+- Main LEDs: **Tested OK**
+
+- Battery Buck: **Needs thorough testing**
+- Power circuit: **Needs thorough testing**
+
+- Accelerometer: **UNTESTED**
+- Ambient light detection LED **UNTESTED**
+- Rear status LED **UNTESTED**
+- Power consumption assumptions: **UNTESTED**
+
+- USB PD: **Design Defect** - power switch does not work as expected
\ No newline at end of file
diff --git a/hardware/SCH_hsc26 artemis2_REV1_20260509.pdf b/hardware/SCH_hsc26_artemis2_REV1_20260509.pdf
similarity index 100%
rename from hardware/SCH_hsc26 artemis2_REV1_20260509.pdf
rename to hardware/SCH_hsc26_artemis2_REV1_20260509.pdf