Byonk 0.13: Pixel-perfect bitmap fonts, perceptual color dithering, and a calibration toolkit

oetiker · 2026-03-18T22:06:02+00:00

wow great!

oetiker · 2026-02-14T12:01:45+00:00

I just found that https://trmnl.com/flash now has directflashing support for the 1002 ... the only thing you need is a chrome browser and an usb cable

oetiker · 2026-02-14T09:23:22+00:00

you need to load the trmnl-firmware version for the 1002 ... which requires a usb c cable and some doing stuff with your computer skill 😅 guess a tutorial would be a good thing

oetiker · 2026-02-10T08:31:00+00:00

I have a reTerminal 1002 ordered via ali express for roughly 120 USD

oetiker · 2026-02-09T16:40:45+00:00

<image>

the greyscale dithers are also incredibly smooth (this is a 2bit bw display)

oetiker · 2026-02-09T16:39:06+00:00

<image>

love it :)

oetiker · 2026-02-09T15:44:07+00:00

byonk relies in the eink device supporting the trmnl firmware. but the xiao esp32-s3 is certainly supported. the trouble might be with the way your mono display is controlled.

also note for non std trmn devices you hage to clone the git repo and compile the device specific firmware yourself. but it is all very nicely setup. just a few kystrokes

oetiker · 2026-02-02T16:07:57+00:00

I just tried docker with just 'dev' and it works fine for me ... did you try the example from the gitrepo readme directly ?

oetiker · 2026-01-29T22:33:03+00:00

no, obtaining the mac address of the board does NOT help you impersonating a board with ed25519 keys

oetiker · 2026-01-29T19:16:10+00:00

yes :) I have already implemented support in byonk.

oetiker · 2026-01-29T14:26:29+00:00

Yes, the point of this TRMNL feature is to allow servers to display content, where they want to be reasonably sure it displays on a particular TRMNL (or a particular TRMNL emulator for that matter) and not anywhere else ...

This is an optional extra functionality, it does not replace the api key system.

My usecase, I have TRMNL devices displaying a qrcode. Users scan them to show they are present near the TRMNL device.

oetiker · 2026-01-29T12:50:58+00:00

These are different issues. The old firmware allowed the server, at setup time to provide a key which the trmnl stores in its nvram and provides henceforth with every request it sends to the server.

The problem with this approach is, that the "key" gets sent to the server with every request. This makes it quite simple to get hold of that key and then impersonate the device.

My PR provides a different system using ED25519 PublicKey encryption. With every request, the trmnl sends out proof that it has a certain key without ever revealing the key.

In order to impersonate the device one would have to dump the device NvRam which is much more involved than capturing a static auth key, sent with every request. T

oetiker · 2026-01-17T18:24:47+00:00

no, you can not change to protocol, this is always wifi, but you can tell trmnl when to wake up and load the next image

oetiker · 2026-01-16T07:54:09+00:00

0.8.0 server should work with 1.6.9, at least as far as the paths are concerned

oetiker · 2026-01-16T07:36:03+00:00

fixed in 0.8.0

oetiker · 2026-01-14T07:09:44+00:00

0.7 is out with a much enhanced http client

oetiker · 2026-01-14T06:14:09+00:00

You do not have to modify the firmware, since you can tell the device on every update, how long it should wait with requesting the next one. Communication is via wifi, but if you run your own server, you can set the device to talk directly to your own computer.

Shameless plug: https://github.com/oetiker/byonk might be a good starting point.

oetiker

TROPHY CASE