MiniSphere

We're starting to finalize some of the bigger pieces of this project, so we're excited to start sharing our progress! We've got the geometry and LED arrangement set, now we're testing our electrical design and getting started on writing some animations. Here's what we've been up to!

Hardware

To test out our electrical design before we jump into form factor MiniSpheres, we decided to start with a development board to test all the subsystems and components, and to characterize the system.

We got the development boards made and assembled by PCBWay (www.pcbway.com), big thanks to them for sponsoring the PCBAs! We've used PCBWay for fabrication and assembly a bunch over the years, and their quality and speed is hard to beat. Our boards came perfectly assembled with no issues, and in no time!

The heart of the system is a Quarto DWM3001C module, which has an nRF52 microcontroller and an ultra-wideband radio. The nRF52 is responsible for interfacing with everything from the IMU, to the battery charger, to the addressable LEDs on the outside.

The development board has the following subsystems:

• Quarvo Module (BLE/UWB)
• IMU
• Battery Charger
• BMS
• LED Boost Converter (Li-Ion → 5V)
• 3V3 Buck Converter
• Hall Effect Sensor
• Level Shifter for the LEDs
• USB-C (Programming/Debug/Charging)

Finally, the development board has a single panel of LEDs. The full spheres will have 10 of these each!

We've fully tested and validated the hardware design and apart from some small bodge wires, we are ready to fabricate the form factor control boards!

Mechanical

The main goal of this project is to shrink the Las Vegas sphere as much as we can, while keeping as much functionality as possible. We experimented with different geometries and diameters, and different arrangements and densities of LEDs, balancing that with other requirements like battery life. We landed on a V3 geodesic sphere with 180 faces, 75mm in diameter, with 6 LEDs per face. That's a total of 1080 LEDs, powered by seven 18350 Li-Ion cells in parallel.

One sphere will have 10 flexible PCB panels of LEDs, soldered together to cover the sphere in LEDs. The flexes wrap around a subframe structure that supports them while protecting the internal components. Each flex has small contacts on either side to chain power and data from one flex to another, and similar pads on the back that lets us tap into those signals if we need to.

Each hemisphere of the subframe has locating features to align the flexes, and to align from one hemisphere to the other. We broke the sphere up into the smaller LED panels due to the manufacturing cost of one large flex.

Below is a cross section of the sphere:

And here you can see how the hemispheres are split, which lets us open the sphere up for maintenance and debugging. Ultimately, we'll add an outer shell to protect the whole assembly and diffuse the light from the LEDs.

Battery Safety

Since these spheres will be in the hands of our friends, family, and strangers alike, we want to make sure it's safe to handle. When not handled properly, the Li-Ion batteries can easily turn these into lack-luster grenades. To mitigate this, we're only charging the battery back to 4.1V (instead of the typical 4.2V), and we have a BMS to protect the pack from short circuits, as well as under and over voltage conditions.

Simulator

We started with a Python simulator to help explore LED arrangements and spacing, and to have an easier way to test out ideas for animations and patterns on the spheres. It uses VPython for the 3D rendering and geometry, which makes it super simple to get some shapes on the screen.

The simulator is the source of truth for some of the physical aspects of the sphere. For one, it prints out the relative LED positions that the CAD uses to place the LEDs on each face. The simulator also knows the ordering of LEDs in the chain, so it can produce the mapping from LED indices to their orientations in space, which ultimately drives the animations.

Firmware

The spheres are driven by an nRF52 that's in a DWM3001C ultra-wideband module (they'll eventually be able to tell how far away they are from each other!). The firmware itself is based on the Zephyr RTOS, and right now it's pretty bare bones as we bring up and test the hardware.

The animations themselves are written kind of like graphics shaders, meaning they're just a single function that takes in the position of the LED (among other things) and outputs the color that the LED should be.

Every frame, the animation module asks that function what color each LED should be, and then it encodes the colors directly into the SPI buffer that gets shifted out to the LEDs. Since they're addressable LEDs, the color values need to be broken down into properly timed bit patterns that are sent over the single data wire.

We found that floating point operations are a little too slow on the nRF52 for rich animations (even with an FPU!), so the animations use 16.16 fixed-point numbers for all values, which means we can use integer math operations under the hood.

Next Steps!

We've got a bit more work to do on the firmware side to fully validate and bring up the hardware, but we're close to done. We've ordered a sample set of the flexible PCD LED panels so we can iron out any integration issues on the mechanical side before we put in the big order, which will be enough for 6 spheres!