• Claude was close but too complex

    DTW Projects • 07/28/2026 at 00:01 • 0 comments

    I'm very much the kind of person who needs to understand the ins and outs of how a project functions- this is doubly true if I am making the project and putting my name on it. Claude made a truly impressive interface to get the first steps going on the azimuth and pitch axes but everything else was a miss. Somewhat delighted that I have to roll my sleeves up I am going to have to scrap Claude's first run because it's too much and too complex for me to understand outright what was written and it's not worth spending cycles trying to learn it- better to build the aprts up myself so I know whow everything goes together. That way I'll be able to troubleshoot when something goes wrong. Claude's not fired per se but I'm defintiely going to need to build the firmware myself.

  • Small update from my software intern (Claude :) ):

    DTW Projects • 07/23/2026 at 18:34 • 0 comments

    "

    The brain is alive: full tracking firmware, validated to 0.0004°

    The CAD side of Punctum Lucis has been grinding along (see the azimuth ring gear saga in earlier logs), but this week the project grew a brain. The ESP32 now runs a complete MicroPython firmware stack: it knows where it is, knows what time it is, knows where the ISS is, and knows how to swing a laser pointer to follow it.

    What's running on the chip

    The whole thing is cooperative async — about a dozen asyncio tasks sharing one core-brain loop:

     SGP4 on a microcontroller.I'm running the real thing — the pure-Python core of Brandon Rhodes'python-sgp4, trimmed and cross-compiled to bytecode so the ESP32's ~100 KB of heap doesn't choke. TLEs are pulled straight from CelesTrak over TLS, cached to flash, and auto-refreshed. A propagation costs on the order of 100 ms, which is way too slow to run at control-loop rate, so the tracker propagates a keyframe every 2 seconds and linearly interpolates az/el at 5 Hz in between. Interpolation error stays under ~0.1° except right at zenith.

     Sun, Moon, and planets with no internet at all, via Paul Schlyter's classic low-precision ephemeris. The Moon is the designated first light target: big, slow, and you canseethe beam miss.

     GPS does double duty: position for the observer math, and the RMC sentences anchor UTC against the ESP32's millisecond tick counter for sub-second time. Time error matters — the ISS moves at up to 1.2°/s, so 100 ms of clock slop is 0.12° of pointing error.

     A web dashboard served by the ESP32 itself(Microdot + one hand-rolled HTML page, gzipped to ~4 KB). Live pointing readout, target picker (curated satellite list, raw NORAD ID, or a planet), jog buttons, laser toggle, and the whole calibration workflow. No cloud, no app — just a browser on the LAN.

     Wi-Fi provisioning without leaking credentials into a public repo: secrets live only on the device, and if it can't join a network it boots as its own access point and serves a setup page. The repo ships templates only.

    The part I'm most pleased with

    Before letting this thing point at anything, I wanted proof the math was right. The pointing chain (TLE → SGP4 → TEME frame → topocentric az/el) runs identically under desktop Python, so there's a validation script that compares the exact code the ESP32 runs against Skyfield, the gold-standard astronomy library.

    Result: satellite az/el agrees with Skyfield to 0.0004°. Sun 0.005°, Moon 0.03°, planets under 0.03°. The mechanical backlash in a $2 geared stepper is going to be a thousand times worse than the math. That's the right place for the error budget to live.

    Design decisions the hardware forced

     Azimuth is continuous— the pinion walks around a stationary ring gear and every wire rides the rotating stage, so there's no cable wrap and the firmware always slews the short way around. 20:3 gearing on top of the 28BYJ-48's internal 63.68:1 works out to ~75 half-steps per degree: 0.013° resolution.

     Elevation gets ±120° of software travel.The only thing on the elevation stage is the laser diode, on wires with a couple turns of slack. Why below the horizon? Because indoors, an ISS pass doesn't end at the horizon — the dot just keeps crawling down my wall. That's the whole point of the project: making the invisible geometry visible.

     The laser is a plain on/off toggle for now.I had built an elevation-gated software interlock, but for an indoor pointer-class diode it mostly created "why isn't it firing" confusion. Safety is operational for v1 (it's my living room and my retinas); smarter lockouts can come back later for any outdoor/higher-power variant.

    Bench status & next steps

    Current gremlin: the GY-271 magnetometer isn't answering on the I2C bus — scan comes up empty, so it's wiring/pullups/dead-board territory rather than software. The firmware shrugs it off (the compass was only ever an advisory coarse-north...

    Read more »

  • All night work to get it working for the contest (so close but not quite there)

    DTW Projects • 07/23/2026 at 18:32 • 0 comments

    Managed to 3d print the design and start assembling it. Here is a video of the azimuth and pitch stage working. Having some trouble with the magnetometer and laser diode which is tied directly to esp32 gpio pin (for low power but my bench test showed that 3.3v works to light the diodee with only a 14mA power draw so I should be okay to power the diode from the esp32).