Tapestry - Nodes

What is Tapestry?
All Tapestry posts

The images in Tapestry are displayed on multiple e-paper displays, each driven by a single PCB which I call a “node”.
Those nodes are EPDiy devices, running a custom server

Hardware

I found the hardware docs for EPDiy V7 (here), and ordered 5 PCBs from jlcpcb.com, including assembly. I won’t say it’s the easiest process for a newbie, but it worked.
Each PCB has a paired e-paper, either ED097TC2 (the bigger ones) or ED060XC3 (which were cheaper to start with).

Power is provided via USB from a beefy powered USB charging station

Software

$ curl 10.42.0.162 -s | jq .
{
  "width": 1200,
  "height": 825,
  "temperature": 20,
  "screen_model": "ED097TC2"
}

$ curl -XPOST 10.42.0.162/clear
Cleared

Each PCB runs an HTTP server. I contributed some version of it to the EPDiy repo here.
Currently, the basic logic goes like this:

1. Open NVS (non-volatile storage)
2. Connect to WiFi with SSID and password from NVS, get IP from DHCP
3. Start HTTP server
4. Set e-paper display (EPD) up according to screen type from NVS

The HTTP server has these routes:

1. GET /:
   Returns JSON containing:
   1. screen width/height in pixels
   2. screen type
   3. current temperature
2. POST /clear:
   Clears the screen
3. POST /draw:
   Accepts:
   1. Body: a binary-specific format of an image (4-bit grayscale)
   2. Headers: height/width of the image to be drawn
   3. Headers: optional start coordinates
   4. Headers: optional instruction to clear the screen before drawing the new image

   And draws it on the display

Case

I’ll make another post about the cases, but I’ll mention that I had a lot of LLM help designing them, and 3D-printed them at home with multiple iterations

Performance and improvement

Although the node’s software is very basic, it works surprisingly well.
Given infinite time, I think I’ll try migrating from WiFi to Bluetooth. It feels slightly more secure, as in WiFi I can’t roll the WiFi password without re-flashing all of the nodes, and in Bluetooth I’ll only have to supply the nodes with the controller’s BT address. It also feels more appropriate for the type of interaction the devices require - the nodes don’t need internet access, and don’t need to interact between one another. All they need is to trust the controller and accept commands from it.
My aversion to BT is that WiFi+HTTP provides a really nice RPC framework. I have solid clients, timeouts, body for binary data, JSON/headers for textual. Moving to BT will be a bit of an adventure in that area.

I’m also toying with moving the power from USB to something simpler, as in a 5V PSU with some wires connecting to the ESP32’s GPIO. I feel that the USB cables are a bit bulky, and I don’t need the added value they provide, but like the HTTP they’re simple to operate and work well enough for now.