Christopher Van HooseandClaude Fable 5
08c9f2b822
North was wrong on hardware, and the device's own saved state said why. Its stored centre was (-0.3875, -3.465) where four measured headings put the true centre at (-0.340, -3.378): out by 0.099 G against a horizontal field of only 0.27 G. Replaying the measured readings through that centre gives -1 deg of error at north, -12 at east, -18 at south and +22 at west -- errors that swing with direction, which is a wrong centre, not a wrong formula. align and mirror were both 0, so the axis mapping was doing its job. Min/max midpoints only find the centre from a COMPLETE sweep and are skewed by whichever extreme was missed; with a bias ~7x the field here, a tenth of a Gauss of skew is a third of the whole signal. Calibration now fits the sphere that the samples actually lie on -- |p - c|^2 = r^2 is linear in (c, r^2-|c|^2), so it is a 4x4 solve over running sums with no sample storage, which matters inside a 256 KB app heap. Coordinates are accumulated relative to the first sample because Lua here is single-precision and squaring raw values near 3.5 G throws away the precision the fit depends on. The fit is checked before it is saved: a singular system (a flat spin, where the centre is undetermined along z) or a radius outside Earth's 0.25-0.65 G band is refused with a reason, leaving the previous calibration alone -- the old code would happily save the garbage. The toast now reports the fitted field strength, which is the number that says whether a calibration is any good, and the progress line shows the sample count. Also adds a D key: the calibration in use, the raw vector, the horizontal components and the stored align/mirror, so a wrong heading can be read off the screen instead of guessed at. Harness: the fit recovers a simulated bias exactly, and a flat-only spin is refused without touching the saved values. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
wadamesh.com infrastructure
Distribution stack for wadamesh: a VPS nginx origin behind Cloudflare.
tiles.wadamesh.com →CF (HTTP, edge-cached) → nginx → OpenStreetMap / OpenTopoMap
firmware.wadamesh.com →CF (cache bins) → nginx → /srv/wadamesh/firmware
flasher.wadamesh.com →CF (HTTPS) → web flasher (TODO — see below)
wadamesh.com →CF (HTTPS) → landing page (later)
Map tile styles. The default /{z}/{x}/{y}.jpg route serves OpenStreetMap
(the firmware default). An opt-in OpenTopoMap topographic style is served from
/opentopo/{z}/{x}/{y}.jpg (explicit OSM alias at /osm/...); the device requests
it only when the user enables Map → Options → Topographic map. Legal: OpenTopoMap
map tiles are © OpenTopoMap (CC-BY-SA) over © OpenStreetMap contributors
(ODbL) + SRTM — the touch UI shows that attribution when topo is active, and the
14-day disk cache keeps each tile hitting OpenTopoMap at most once per fortnight
(their tile-usage policy asks for a contactable UA + caching, both of which the
transcode service provides). Deploying the topo routes = update
tiles.wadamesh.com.conf + tile-transcode.py, then
systemctl restart wadamesh-tile-transcode && nginx -t && systemctl reload nginx
and purge the Cloudflare cache for tiles.wadamesh.com/opentopo/*.
The firmware fetches tiles + the update-check over plain HTTP (on-device HTTPS isn't viable — mbedTLS needs ~30 KB heap, only ~5 KB is free post-Wi-Fi), so the tile + firmware hosts must stay reachable over HTTP. Cloudflare provides the edge cache, HTTPS for the flasher, and hides the origin IP (so no IP lives in this repo or the firmware).
1. VPS (origin)
sudo apt install nginx
sudo mkdir -p /srv/wadamesh/firmware/releases/TOUCH /var/cache/nginx/wadamesh-tiles
sudo cp deploy/nginx/tiles.wadamesh.com.conf /etc/nginx/sites-available/
sudo cp deploy/nginx/firmware.wadamesh.com.conf /etc/nginx/sites-available/
sudo ln -s /etc/nginx/sites-available/tiles.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/firmware.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
2. Cloudflare
- DNS:
A/AAAArecords fortiles,firmware,flasher,@→ the VPS IP, all Proxied (orange cloud). - SSL/TLS: mode Flexible (CF↔origin HTTP) is enough since the origin is
HTTP-only. Do NOT enable "Always Use HTTPS" on
tiles.orfirmware.— the firmware needs plain HTTP there. - Cache Rules:
tiles.wadamesh.com/*→ Eligible for cache, Edge TTL ~14d.firmware.wadamesh.com/releases/*/*.bin→ cache, Edge TTL ~1d.firmware.wadamesh.com/releases/TOUCH(the listing) → short TTL (~60s) or Bypass, so new releases appear promptly.
3. Publishing a release
From a wadamesh checkout (builds both boards, refreshes the listing, rsyncs up):
WADAMESH_VPS=user@your-vps scripts/release.sh beta_2
The on-device check GETs http://firmware.wadamesh.com/releases/TOUCH, finds the
highest beta_<N>, and (once OTA-over-Wi-Fi is re-enabled) pulls
…/releases/TOUCH/beta_<N>/<board>.bin.
Done
- Web flasher ✅ at
flasher.wadamesh.com—deploy/flasher/(esp-web-tools / Web Serial, board picker, manifests pointing at the rolling/latest/merged bins;release.shrefreshes/latest/each publish). - Apex
wadamesh.com301-redirects to the flasher — activate by pointing thewadamesh.comA record at the VPS in Cloudflare (it's still on the parking IP).
TODO before public launch
- Re-enable OTA-over-Wi-Fi in the firmware (currently it version-checks then defers to manual flashing).
- Flip
wadameshrepo public = launch. - Decide tile-proxy sharing: dedicated
tiles.wadamesh.com(this config) vs reusing the meshcomod proxy.
Never commit the VPS IP, SSH keys, or
WADAMESH_VPS. Cloudflare fronts the origin; the deploy target is supplied via the environment at publish time.