Six months after freezing our initial V0 prototype, real-world networking, bootloader hacks, and an unexpected fit with the Raspberry Pi Zero transformed ADX from a single rugged board into a 3-Tier open hardware standard for enclosure-native modular electronics.

The 6-Month Silence: What Actually Happened

Back on April 30th, we posted our last project log announcing that the schematics for ADX Core V0 were frozen and sent off to JLCPCB.

And then... total silence for nearly six months.

We didn't abandon the project. Quite the opposite: once the physical boards arrived on our bench and we started debugging, everything looked great. But the moment we tried to actually design an enclosure for it—and started seriously planning how it would connect to messy, real-world factory wiring—we hit a massive wall.

It turns out, making a board work on a desk is easy. Designing a board that makes sense inside an industrial enclosure, handles external wiring cleanly, and remains maintainable is a completely different beast.

What started as an effort to build "a rugged industrial Arduino on an ATtiny1616" had to fundamentally transform. Over the past half-year of staring at CAD models, realizing our initial architecture wouldn't survive outside the lab, and doing stripped-down redesigns, ADX has evolved into something much broader: The Open Hardware Standard for Enclosure-Native Modular Electronics.

Here is the lab notebook on how we hit the "enclosure wall," what we re-engineered, and where the standard stands today.

---

1. Networking in the Real World: The Core-D Experiments

When the V0 boards landed on our bench, basic GPIO toggles worked fine. But our ambition was multi-drop industrial communication: daisy-chaining multiple boards over a single twisted pair with robust bootloading.

To rigorously test field protocols, we designed and spun a dedicated testbed board: ADX Core-D. Starting in late August, we iterated through several protocol layers:
- LN-485 (LIN-based packet frames over half-duplex RS-485)
- PAL (Physical Access Layer tuning, slew-rate shaping)
- DROP-BUS (Collision handling and deterministic multi-drop streaming)

Running continuous data streams across three cascaded boards revealed crucial lessons about ground-bounce, common-mode noise, and line reflections. It quickly proved that robust galvanic isolation wasn't just a nice-to-have spec sheet bullet—it was an absolute requirement for survivable field hardware.

---

2. The Field Maintenance Dilemma: WebSerial & OTW Bootloading

The biggest operational pain in embedded field deployments is simple: nobody wants to drag a heavy laptop and a dedicated hardware debugger (like a UPDI dongle) up a ladder or into a dusty electrical cabinet just to tweak three lines of code.

We wanted OTW (Over-The-Wire) firmware updates over the existing RS-485 bus, controllable directly from a standard web browser via the WebSerial API.

In late September, we built and deployed a browser-based WebSerial PWA Uploader (hosted directly on our GitHub Pages). But we immediately ran into a notorious low-level barrier:

Standard USB-to-UART bridge chips (CH340, FTDI, CP2102) and operating system drivers (especially Windows Win32 serial drivers) handle standard send_break() signals unpredictably. Pulse widths varied wildly from a few milliseconds to over 100 ms, completely desynchronizing the target bootloader.

The Hack: The Half-Baud Pulse Trick
Instead of relying on fragile OS break APIs, we developed a deterministic timing workaround: temporarily cutting the baud rate in half and transmitting a framing pattern (or injecting a calibrated zero byte at the lower baud).

This simple software hack generated a rock-solid, predictable break pulse across virtually all commodity USB-RS485 adapters, allowing standard browser tabs to reliably trigger target MCU bootloaders without any proprietary flashing hardware.

---

3. The Art of Subtraction: Eliminating the BMC via ATtiny CCL

In mid-September, we faced an architectural dilemma for multi-drop flashing. If ten slave boards share the same RS-485 line, how do you reboot and reprogram Board #3 without disrupting Boards #1, #2, and #4?

Our first answer was brute-force hardware: we designed a prototype called CORE-S-P, equipped with an onboard BMC (Baseboard Management Controller)—a tiny secondary supervisor MCU that listened to bus commands and held the main MCU in hardware reset.

It worked. But it felt wrong. Adding a secondary MCU increased BOM cost, consumed precious board real estate, and introduced another point of failure.

The Pivot: Whole-Bus Reset + SIGROW Matching

In early October, we executed an aggressive "subtraction" redesign:
1. We utilized the CCL (Configurable Custom Logic) internal hardware blocks inside the Microchip ATtiny1616.
2. The CCL listens asynchronously to the bus break pulse and triggers an autonomous hardware reset—even if the CPU core is stuck in a hard fault.
3. When an update is initiated, all nodes on the bus enter bootloader mode simultaneously.
4. The host uploader queries the factory SIGROW (Device Signature / unique hardware identifier).
5. Only the node matching the target signature accepts and burns the incoming Flash payload; all other nodes time out safely and return to running their application sketch.

We sacrificed hot-swap flashing of individual nodes while the rest run, but in return, we eliminated the extra BMC chip entirely, slashing BOM complexity while drastically improving reliability.

---

4. The 3.3V Logic Pivot & The Pi Zero "Aha!" Moment

As October progressed, we realized that an 8-bit ATtiny1616, while brilliant for ultra-low power and harsh temperatures, lacked the muscle for high-throughput Ethernet or complex TCP/IP stacks. We began architecting companion CORE boards based on RP2040 and ESP32.

This forced a critical electrical reckoning:
- Mixing 5V and 3.3V logic across modular addon cards is a recipe for user error and level-shifter clutter.
- Rather than forcing level-shifters onto every future expansion CARD, we shifted the entire ADX 20-Pin Bus standard to Native 3.3V LVCMOS Logic.
- The ATtiny1616 on our flagship CORE-A5 was reconfigured to run natively at 3.3V.

Meeting the Raspberry Pi Zero

Around the same time, we explored whether a full Single Board Computer (SBC) could ever interface natively with the ADX form factor. We laid out a mechanical study for an ADX PiZERO Expansion CARD.

What we found was an astonishing geometric alignment:
- Placed on the standardized 87.0 mm × 48.0 mm profile, the Raspberry Pi Zero's USB and mini-HDMI ports align flush against the 67 mm single-edge I/O opening.
- With onboard eFuses and dedicated 5V/2A power regulation on the CARD, the Pi Zero plugs directly into the ADX power highway and 20-pin bus.

┌────────────────────────────────────────────────────────────────────────┐
│               【 ADX 3-TIER OPEN HARDWARE STANDARD 】                  │
├────────────────────────────────────────────────────────────────────────┤
│  Tier 1: 8748 Form Factor (87 × 48 mm, M3 10mm Keep-out, 1-Edge I/O)   │
│  Tier 2: ADX 20-Pin Bus (VBUS 5V/2A, Pin 5 GND Shield, 3.3V Logic)     │
│  Tier 3: Ecosystem (MCU COREs, SBC CARDs, Power/Proto CARDs, WebSerial)│
└────────────────────────────────────────────────────────────────────────┘

Suddenly, ADX was no longer just an "Arduino enclosure standard." It had become a unified platform bridging low-power 8-bit MCUs, 32-bit dual-core controllers, and Linux SBCs—all sharing the exact same DIN-rail mounts, 3D-printable cases, isolated industrial power supplies, and battery cards.

---

5. Standardized Naming: CORE vs COREX

To keep the ecosystem clean and intuitive as the hardware catalog grows, we have formalized our grade taxonomy:
- CORE / CARD: Standard grade for desktop prototyping, lab benches, and general automation.
- COREX / CARDX: Extended Industrial Grade (-40°C to +105°C). Fully isolated (2500V galvanic isolation), equipped with high-temperature components, reverse-polarity valves, and industrial TVS arrays for extreme plant floors, crawl spaces, and outdoor deployments.

We are also wrapping up the PCB layout for the ADX Reference CARD—a physical FR4 ruler card designed with all dimensional keep-outs, rail margins, and bus pinouts silk-screened directly onto the board. It will be released alongside our upcoming hardware drops, making it perfectly frictionless for anyone in the community to design their own ADX-compatible expansion cards.

---

What’s Next: Back to Weekly Logs

The architectural foundations are now rock solid. We have settled the form factor, the 20-pin bus specification, the bootloader scheme, and the modular ecosystem.

Because of the massive gap since our last post, this log was naturally packed with high-level architectural changes. From here on out, we are returning to regular weekly devlogs. In the coming updates, we will dive deep into:
- The complete schematic and PCB layout of the production CORE-A5
- Step-by-step oscilloscope traces of the CCL break-recovery mechanism
- How our isolated DC-DC Power CARDs safely handle 12V–48V industrial rails
- Demonstrations of the browser-based WebSerial diagnostics tool

Thank you for your patience during our quiet months of prototyping. Please hit Follow / Skull on the project page to stay tuned as we bring enclosure-native hardware into the real world!

---