Project Insights - ReaverShadow/Mu-boo-Cub-Mug GitHub Wiki
Priorities (WIP)
Priority 1: Battery
The desire is for the battery life/status to be integrated into the OS, as if it was a laptop battery. This way the user can see the remaining battery when using Remote Access/Streaming, without having to pull the device out of bag/pocket, and look at LED indicator. There are two approaches; (1) have the ACPI tables in the BIOS programmed with the corresponding descriptors, objects, and BMICs Memory address tables, so that the BIOS can pull that info across the SMbus. An OS can then access the ACPI tables from the BIOS. Or, (2) use a Universal Power Supply (UPS) approach. Have a BMS connected via USB, which an OS can then interact with. The downside is an OS would not have "automatic" awareness of battery, and a driver would be needed for each OS.
Update 19-Jun-24: ACPI approach is unfeasible at the current time, and instead will proceed with USBHID-UPS approach.
Based on Lattepanda Mu spec (via webpage), the TDP is between 6W to 35W.
Note 1: The long term goal will be to have physical button on device to activate "unleashed" mode. This would dynamically, adjust CP1/CP2 limits (possibly through BIOS profiles), for higher TDP, based on current running power source (plug or battery). See hardware spec page for table listing out estimated TDPs for a future version.
- Aim is for the approx. 2.5 hours of use @ 22W = 55Wh (based on N100 reviews).
- 4 x Standard 18650 Li-Ion cells to start. estimate 3Ah per cell.
- Fully Charged (4.2V per cell): 4V2 × 4 = 16V8
- Nominal Voltage (3.7V per cell): 3V7 × 4 = 14V8
- End-of-Discharge (3.0V per cell): 3V0 × 4 = 12V
- Current = Power/Voltage = 22W/14.8 = 1.49A
- Duration = Capacity/Current = 3A/1.49A = 2.01 Hours
- Investigate 21700 cell cost compared to 18650
DFRobot (which I think is the same team at LattePanda), has a expansion board and code for a USBHID-UPS. It is powered by 3x 18650 Cells. It is said it "supports the HID-UPS protocol, which can be recognized as a battery device in the operating system. You can use system power management to implement power-saving modes and automatic shutdown functions, just like using an internal laptop battery." and the their wiki shows pictures of Windows showing batter. HURRAY!
Using this as a template, I will port it over to another Cortex-M based MCU, and see about implementing the HIDPowerDevice Library.
Priority 2: Size
- Mu: 69.6 x 60mm (Credit Card: 54 x 85.6mm)
- 18650 cell, D18mm x L65mm, 21700 cell, D21mm x L70mm
Preliminary Enclosure bounds: 4 x 21mm battery width (single row, side-by-side, all 4 cells) + 2 x 1mm enclosure wall thickness + 2 x 1mm wiggle = 88mm wide.
Challenges (WIP)
Challenge 1: Arduino to other Cortex-M MCU coding
Challenge 1: High speed traces
- Routing any high speed differential trace will always be a PITA, and pretty much guaranteed need a few board spins to nail the eye.
Challenge 2: Wireless antenna placement
- and possible need for external antennas.
Challenge 3: implementation of remote access/streaming Ccurrently aware of two method to establish a wireless connection Mu-boo Cub Mug, and another device.
- Connecting to a external router, and 3rd device. which is completely counter to the project purpose.
Or,
- Connecting to the WiFi card on the Mu-boo Cub Mug. which has its own obstacles and issues. The two route for the later would:
- (need to revise) using Windows network config to share a connection, typically this would be done through Windows setting and creating a bridge between ethernet port and wireless adapter (soft Access Point). However, there will not be an ethernet adapter, and thus the wireless adapter would need to be set to ad-hoc to turn it into an access point. It is well documented that the reliability of both those ways is not great. As well as Intel adapters being terrible for ad-hoc mode. Additionally, B-Link has/had a usb wireless adapter specifically designed to connect with the Quest via WiFi, but this adapter was problematic with Virtual Desktop users. In fact, the minimum requirements are for a PC/Laptop to be connected to a router via a physical wired connection.
- but since, your still connecting wirelessly to a router, that where the second route would come in. Using the virtualization capability of the N100 chip, with something like Proxmox to run two guess OS, one an Open Source router like OpenWRT and Windows.
Unfortunately, a small hiccup would be if you connect a quest wireless to the Mu-boo Cub Mug, neither would have a connection to the internet. I suspect this could be accomplished in Windows, but know it can be done in an open-source router where you bridge the wifi to another wifi device. ideally, you'll want to connect the 2.4Ghz band the internet, leaving the 5GHz or 6GHz band dedicated to only your streaming devices.
This is where another potential issue crops up. limited resources of core and ram. you basically have 3 OS (proxmox, openWRT and indows) running similtaneously. Ideally, I would like to investigate and try to solve these issues and "hiccups" on Windows, without having to use virtualization. but this would likely take more time, and I would assign it as a V1.1 task.
Choices (WIP)
This section will be updated the closer i get to completing Stage 1, as well as updated throughout the project.
Choice 1: Reason for USB 4 over OCuLink, considering gaming a considerable usage case.
Note: As have discussed in Hardware spec page, implementing USB 4.0 for this project at the current time is unfeasible. I do still do believe, given all factors, USB4.0 would be the better and optimal solution, and as such I will leave my discussion of it, even though it has been swapped for OCuLink.
Without a doubt, as showing in multiple reviews and analysis (i'll link any i find below), OCuLink wins in the eGPU department. BUT... this is not soley developed around gaming/eGPU. The top goals of the project is around portability, not absolute, but reasonable, in terms of size, weight, duration.
1st factor to consider is, where will System bottleneck(s) be? The N100 is an e-core only chip, and on average, it's CPU tests are around 1/2 performance of other CPU of the same year/generation. Frame per second (FPS) is typically CPU dependent (and the link speed between it with GPU), whereas resolution is more GPU dependent. Not to mention the limit of 8GB of RAM. Next, according to the N100 public documents, the max PCIe link speed is x4 (I wonder if PCIe controller 1 and PCIe controller 3 can be bonded to form a x8 slot). As shown below, on paper, this puts USB4 and OCuLink at the same paper bandwidth. But, and Unfortunately, the USB protocol will also introduce overhead into the system, further limiting FPS, So you might say, "Well Reaver, all the more reason to use OCuLink". Let's see a Side-by-side:
| "Paper" Feature | USB 4 | OCuLink-2 |
|---|---|---|
| Standardization Body | USB-IF (USB Implementers Forum) | PCI-SIG (PCI Special Interest Group) |
| Primary Use Case | "Universal connectivity (data, video, power)" i.e. consumers | Internal storage and enterprise connections (gamers have propelled it more into the mainstream) |
| Max Data Transfer Rate (don't forget this doesn't take into account protocol overhead, which is the real killer) | Up to 5GB/s (40Gbps, limited to 4GB/s) | Up to 16GB/s (i.e. PCIe 4.0 x8 lanes max, but we're limited to 4GB/s, or 31.5 Gbps, as it's PCIe3.0 x4) |
| Protocol Support | USB, PCIe, DisplayPort | PCIe (x1, x2, x4, x8 lanes) |
| Backward Compatibility | USB 3.2, USB 2.0, Thunderbolt 3 | PCIe (PCIe 3.0 and 4.0 backward compatibility) |
| Power Delivery | Up to 100W (USB Power Delivery) | No direct power delivery |
| Connector Type | USB Type-C | OCuLink-specific connectors |
| Hot Plugging | Yes | No (well, apparently yes, but need specialized controllers) |
| Latency | Low, optimized for peripheral connections | Very low, optimized for high-speed storage interfaces |
| Cable Length | Shouldn't be connecting either with longer then 1 meter cable. Longer the cable the more error and performance hit you'd take. |
In the table above, I've highlighted the aspects where USB 4 particularly excels for me. USB is ubiquitous, backwards compatible, tried and tested (components, hardware, software), and capable of not only data transfer and tunneling PCIe, but also video output (though I wish input/capture was standardized) and bi-directional power delivery—truly "one port to rule them all."
Considering these aspects, the smaller and easier-to-handle USB-C connector, the availability of various options like right-angle connectors due to its ubiquity (apparently there is one for OCuLink), and the N100's limited PCIe bandwidth along with other potential bottlenecks of a lower power design, USB4 was the optimal choice for this project. This project is not intended to handle new or mission-critical tasks but to serve as a practical middle ground solution. From a gaming perspective, it's meant as a compromise and a reason to play some of the older games you might have missed.
Additionally, it's worth noting that OCuLink not being hot-pluggable and requiring a second cable for power can complicate things further.
Ideally, I would incorpoate both USB4 and OCuLink. Hell, i even thought of using a PCIe switch of various types.
N100 performance referrence, No eGPU
Note: a note that could affect performance, in addition to protocol overhead, is error correction techniques, which might be more effective for PCIe, especially at these bit rates. But that's another topic for another investigation.
Recap: At the current time, It seems due to limited documentation and supply to the greater public, as well as possibly needing integration with BIOS, USB 4.0 is not a viable option. As such, i will default back to OCuLink