01

The short answer

Build the badge as a cached, occasionally refreshed display rather than a miniature always-online dashboard. Start from Badger OS examples, design a high-contrast monochrome layout, fetch only compact data, save the last good result locally, and spend most of the time asleep.

Makers building a name badge, task list, room status sign or low-update personal display on Badger 2040 W.

02

Before you start

Have these basics ready before choosing parts or flashing firmware.

  1. A Badger 2040 W, USB data cable and a compatible battery if portable operation is required.
  2. Pimoroni’s current firmware/examples and a small monochrome asset workflow.
  3. A simple HTTPS or local endpoint if the badge will fetch remote data.
03

Choose the refresh model

Manual refresh: Content changes when the user presses a button; simplest and most battery-friendly.

Scheduled refresh: Data changes a few times per hour or day and staleness can be shown.

Event-driven refresh: An external system can signal an update, but you accept added connectivity complexity.

04

Understand what persists

E-paper keeps its image without continuous display power, but the microcontroller, Wi-Fi connection and refresh still consume energy. Design the application around long sleep periods and infrequent full updates.

  1. Define a maximum acceptable content age.
  2. Show the last successful update time.
05

Install and preserve a known baseline

Load the current Badger 2040 examples and run the launcher before modifying files. Keep a copy of the working filesystem so experiments can be reverted without reconstructing the environment.

  1. Test every button.
  2. Record the firmware and repository revision.
06

Design for monochrome legibility

Use black, white and deliberate whitespace; avoid tiny text and gray-dependent screenshots. Make the most important state readable at arm’s length and reserve icons for meanings that remain clear without color.

  1. Prototype at the physical pixel dimensions.
  2. Test long names and worst-case values.
07

Control refresh artifacts

Update only when information changes and use the library’s documented refresh modes. Schedule periodic full refreshes if partial updates leave ghosting, and never hide stale data by repeatedly redrawing the same failed state.

  1. Keep a refresh counter during testing.
  2. Use a visible offline/stale marker.
08

Fetch compact data

Connect to Wi-Fi, request a small payload, validate it and disconnect or sleep promptly. Cache the last good response locally so a network outage produces an honest stale display rather than a blank badge.

  1. Use timeouts and bounded retries.
  2. Keep credentials out of the published repository.
09

Measure the complete duty cycle

Test wake, connect, fetch, render and sleep on the intended battery. Record failures and actual update frequency; optimize connection retries before trimming drawing code.

  1. Use a manual wake button for recovery.
  2. Protect the battery and board in the enclosure.
10

Safety and privacy notes

Use a compatible protected battery and avoid charging or operating damaged cells. A wearable badge is public by nature: do not display private tasks, access codes, live location or credentials, and secure any endpoint that reveals personal status.

  1. Disconnect the battery before enclosure rework.
  2. Respect API terms and avoid aggressive polling.
11

Troubleshooting

The display shows ghosting. Reduce unnecessary partial refreshes and perform a documented full refresh at a sensible interval.

Wi-Fi drains the battery. Shorten timeouts, limit retries, cache data and move to manual or less frequent updates.

The badge boots to an error or blank app. Restore the known-good example filesystem, inspect serial output and add assets one at a time.

12

Next steps

Keep the next experiment small and reproducible.

  1. Run the stock examples.
  2. Create one static badge layout.
  3. Add cached Wi-Fi data with a visible freshness timestamp.