Fixes need to be made on the second revision of the powertrain. Namely, a higher performance DC-DC converter and redesigning the ESP32-S3 setup. Using a Teensy 4.1 to accelerate development times, all three chips have been verified to function as expected. Further testing needs to be conducted with charger IC.

After ~0.5mm acetal delrin were installed underneath the keycaps and plates glued with cyanoacrylate adhesive (superglue), all the keycaps press and travel as expected. The delrin provides a softer and smoother bottom-out and just a tiny bit less travel. I can type on the keyboard normally, but the sizing and actuations require more typing to break-in.

The power board is nearing completion. The batteries are arriving soon through Fedex (class 9 hazardous material) and the power board will be taped out later this week.

After much debugging (FB pin mishap, flipped TVS diode, etc.), the anyon_e supports the 4K OLED display and a USB-C display simultaneously, playing YouTube videos on both displays. Hardware bringup is required for additional peripherals.

V0.3 with improved fixes has been taped out. A major issue is that the low-profile Hirose connectors are out of stock, so the board will be 1.5mm thicker if this board is final (unlikely).

In the end, it seems like the culprit of the non-functional display was the hardware. Using the exact same devicetree compile and surrounding hardware setup, I was able to get the display running. In particular, the difficulties were most likely in the high-speed signaling losses across the SoM, the Hirose connectors, the HDMI connector, and the transition to the “anyon_e display evaluation” breakout board. The difference between V1 and V2 Short was the use of a male HDMI connector and the shortest signaling traces possible. This eliminated the need for a male-male HDMI conversion between the boards and shortened the FR4 trace lengths by around 2cm. That is -20% change from the pervious length. However, it looks like brightness control must be done over PWM, as (unfortunately predicted) adjusting the voltage does not result in a change in brightness. In my measurements (assuming default output is the stated 400 nits), the max current draw is around 0.5A at 12V, so a PWM brightness system should be implementable.

After the display evaluation, I think I have a much better handle on high-speed signaling especially in relation to the CM3588. This new motherboard revision will be a near-final layout and close to the tape-out design.

I am paying special attention the integrity, coupling, and EMC of the board, so I’ve made the bold move for a 6 layer stackup - (Signal, GND, Power, Power, GND, Signal). I might use the first power plane for low speed signaling since the power requirements aren’t that high.

After battling Linux DeviceTree development for the past weekend, I’m happy to say I am fluent in DTS code (jokes).

Currently forked from Joshua Reik’s modified ubuntu-linux kernel. After modifying the CM3588 DTS to support eDP1, link training is failing. Currently debugging.

After battling Linux DeviceTree development for the past weekend, I’m happy to say I am fluent in DTS code (jokes).

Currently forked from Joshua Reik’s modified ubuntu-linux kernel. After modifying the CM3588 DTS to support eDP1, link training is failing. Currently debugging.

This is the first board being set out to production. I was thinking very hard last night and decided it was safer to evaluate eDP and DP before setting forward. This board includes all the high frequency RF knowledge I’ve learned this summer to provide as comprehensive of an evaluation as possible.

I have put a lot of thought into the sizing and overall integration of the system. As I was designing today, I realized that unless I increase the overall lower chassis thickness to around 17mm, it is impossible to fit an Ethernet connector (height of the connector would be 11.8mm + 1.6mm from PCB = 13.4mm). My aim for the system is still a sleek, integrated, and low-profile design. Unfortunately, I understand why Apple only includes USB-C for connectivity now.

Another tradeoff: With the feature set in mind, a 2280 SSD simply would not fit the vertical requirements. The exact reason is complicated: the keyboard limits the maximum height of the heatsink, meaning the heatpipes have to extend horizontally. The orientation of the CM3588 means that it is most optimal to route with tall components (SSD, wireless card, ribbon cables, etc.) all around it (rather than on one side). It is not that big of a loss, since it will still support 2242 and 2230 SSDs. The PCIe 3.0x4 is limited to 4GB/s, and the newest small-form-factor SSDs are much higher speed and will not be the performance bottleneck.

Starting the motherboard’s PCB layout! It will be a long journey and I will definitely end up revising the schematic many times over.

Trying to keep the entire keyboard assembly to be under 6mm at its highest point. This required designing a custom “BPS” (battery protection system) board and slots in the main PCB to save on the height of the BPS itself.

Created the anyon e website under the byran.ee domain. I started with a Astro Sphere theme, which looks beautiful and saved me lots of time. The website is hosted within the full “laptop” repo. I will probably keep the “laptop” name for SEO (search engine optimization), since it won’t help anybody if it’s called “anyon_e”.

Using a combination of the CM3588 NAS SDK, Radxa 5B, and Cool-Pi laptop schematic and the RK3588 Design Guide (all sources in repo) for reference to create the motherboard schematic.

Created two 3D models of the CM3588 (non plus) SoM (system on module): 1. Nearly fully accurate STL in Blender using the DXFs provided by FriendlyElec 2. A roughly accurate STEP file in Shapr3D using the DXFs provided by FriendlyElec

Still a work in progress. It will use the most advanced chips I can develop with and hopefully have a RP2040 EC (embedded controller) for system monitoring or as a general purpose embedded MCU.

It was around 1AM. I wrote up the mission goal and went to sleep at 2AM. The start.