RAHHHH 8 HOURS CAN’T STOP ME NOW

my bad.

ok so essentially what has happened in the last day is:

• got bored of the current styling (which is none btw)
• decided to work on the actual quiz aspect of it, testing is over
• a lot, LOT of trial and error
• and some standard bugfixing

styling wise, rather than defaulting to a generic dark mode, the canvas is framed like a viewfinder. I just thought it would look nice tbh, there’s not much else going on there other than the stars.

I kept the blues that I already used in the canvas itself (#5a8dee for target, #2e3d5c for neighbours) and just extended them into the actual UI instead of picking a new palette.

the fonts are basically the same as the rest of my projects but icl i might change that

when I was first making the learn mode today, I gave it the northern/southern/all split, quiz mode didn’t, so pickRandomConstellation now pulls from whatever hemisphere’s selected instead of the full 89. changing it mid-quiz rerolls immediately rather than waiting for the next round too.

I also added a show ans button for testing cause even I don’t know them all lmao (only the northern ones so far, and like 3 southern!) so will probably remove this later

additionally, I also kept testing and editing parameters for the projection to make it as smooth as possible.

what. a. day.

and yes im tired as hell its nearly midnight i’m off to bed

finderscope v3-4

accidentally sank 6 hours into this one but it’s the session that where you feel like looking through something instead of staring at a flat projection

naked eye orientation

turns out this was already sorted from v1, the x-axis flip that was in there from the start so I didn’t have to touch the projection maths, just double checked that north stays up on canvas and left it alone.

the real work was making that hold up once the camera can move anywhere, not just the handful of fixed constellation centres it used to snap to.

drag to pan

the camera is now a proper mutable cameraRA/cameraDec instead of being locked to target.center. dragging works out a small angular delta per mousemove event using a small-angle approximation (fine since consecutive drag events are tiny steps, not one big jump), and shifts the camera opposite in ra and dec so the sky moves with your cursor like a map, not like a first-person look-around.

findInView had to change too since “who’s a neighbour” used to be based on the target’s fixed centre, now it’s based on wherever the camera’s actually pointing.

clamped cameraDec to ±89.5° so dragging into a pole doesn’t divide by zero and send the camera into deep space 💀

added touch support alongside mouse since drag is the kind of interaction that should just work on mobile too.

what’s next

• learn mode, hemisphere split
• octans pole clutter still unresolved from v2
• some kind of scoring/streak system

finderscope v2: camera + neighbours

I wanted the zoom to actually feel like looking through a scope rather than a bounding-box crop, so this session was about two things: a fixed camera FOV, and pulling in neighbouring constellations so there’s context around whatever you’re meant to be naming.

the auto-fit issues

v1 fit the canvas to the target constellation’s own bounding box, which meant every constellation filled the frame regardless of its real size on the sky. Crux and hydra looked the same scale, which defeats the point of a “how much can you see” difficulty system.

So, I fixed it by switching to a constant angular field of view instead. stereographic projection has a neat closed-form relationship between angular separation from centre and projected radius: rho = 2 * tan(theta / 2). so i just pick a FOV in degrees, work out what radius that maps to, and scale the canvas to that instead of to the data.

neighbours

for each constellation, check every vertex’s angular separation from the target’s centre (reused the same cosc term from the projection maths, just wrapped in acos instead). anything with at least one vertex inside a 55° radius gets pulled in and drawn dim, target stays bright and thicker so there’s no ambiguity about what to actually guess.

I tested both of these in node before touching canvas, specifically against Oct and UMi since anything near the celestial poles is where stereographic maths tends to fall apart.

OCTANS WHYY

octans pulls in 37 neighbours at the current radius because it’s so close to the pole. Everything nearby just looks angularly closer than it would elsewhere on the sky. That’s fine for now, but medium/hard difficulty will look like a mess down there unless i either shrink the include radius near the poles specifically or cap how many neighbours actually get drawn.

what’s next

• sort out the pole clutter issue properly
• difficulty tiers (all lines / neighbours only / none)
• guess input + checking
• learn mode, hemisphere split

Firstly - yes, I have 6 hours on this, because I switched ideas midway (so essentially 2 hours of work gone lol)

FinderScope

i was mid-attempt at memorising all 88 constellations using some app, got through easy mode fine, then hit a paywall the second i wanted the other two difficulties. so, obviously, I’m building my own cause nobody should have to pay for something as simple as this.

the idea is a constellation naming quiz. it zooms into a random constellation somewhere in the sky, you guess what it’s called, and there’s three difficulties depending on how many of the surrounding constellation lines you get to see (all of them, just the neighbours, or none). eventually there’ll be a learn mode too that splits northern/southern sky and gives you the actual mythology name alongside the IAU one.

started with v1 today: just getting one constellation to render and project correctly, no game logic yet.

the data problem

turns out there’s no NASA-style API for “here’s every constellation’s star positions and line segments,” so i pulled from d3-celestial, an open source star chart project on github. grabbed:

• constellations.lines.json — RA/dec coordinates for every line segment in all 88 constellations
• constellations.json — names, including an en field with the actual mythology name (canis major → “great dog”, that kind of thing)

wrote a python script to slim both down into one dataset per constellation: id, name, en, a precomputed centre point, and the line coordinates. centre point was its own small problem — you can’t just average RA values because of the 0°/360° wraparound, so i averaged everything as unit vectors on the sphere instead and converted back. way cleaner.

projection

the actual hard part. “zoom into a random constellation” means taking a patch of sky centred wherever that constellation sits and flattening it onto a canvas. went with a stereographic projection, standard formula, centred on each constellation’s precomputed centre.

tested the maths in node before touching canvas at all — ran orion through it and checked the projected bounds didn’t blow up or do anything weird near the pole. glad i did that first, would’ve been a nightmare to debug visually.

canvas side just auto-fits whatever bounding box comes out of the projection, so it works whether the constellation is tiny (like crux) or sprawling.

what’s off right now

some of the constellation names/lines from the dataset are a little wrong — going to go through and fix those manually rather than trying to patch it in code.

what’s next

• neighbouring constellations (so medium/easy difficulty actually has something to show)
• difficulty tiers
• actual guess-checking
• learn mode with the hemisphere split

GRID - Double Well HELL

Most of this session went into one bug, and it’s a genuinely annoying one to reason about, which is why it ate the time.

• Added the second mass early on, that part was quick, just refactored mass into a masses array and summed each one’s pull vector. Linear superposition, same as before.

• Problem showed up the second I dragged the two masses toward each other. The mesh was folding, points crossing lines they shouldn’t. My first assumption was the per-mass clamp had a bug, so I spent a while re-checking schwarzschildPull in isolation, it was fine, each mass on its own respects its horizon exactly like build 2.

• Took embarrassingly long to actually accept that the bug wasn’t in either clamp, it was in the fact there wasn’t a clamp on the SUM. Each mass says “don’t let this point cross my horizon” independently, but if both are pulling the same point in roughly the same direction, the two allowed pulls can add up to more than either alone would permit. Obvious in hindsight.

• Tried a couple of wrong fixes before the right one. First attempt was averaging the two pulls instead of summing, which just made single-mass behaviour weaker for no reason and didn’t even fix the overlap case properly. Also considered some kind of smooth blend between the two wells (metaball-style), which would’ve looked nicer but is a much bigger rabbit hole than 5 hours allows, parked that idea for later.

• What actually worked was tracking the tightest safe margin (distance to nearest horizon) across all masses while summing, then if the combined pull vector exceeds that margin, scale the whole vector down before applying it. So the constraint moved from “per mass” to “per point, against whichever horizon is closest.” One extra variable, safeMargin, and a scale-down at the end. The fix itself is maybe four lines, finding the actual shape of the problem was the other 4+ hours.

• Worth saying clearly, this doesn’t make two overlapping wells physically correct. Real GR still doesn’t superpose like this. What it does is stop the visualisation showing impossible geometry, the mesh degrades gracefully at the boundary instead of folding through itself.

Hopefully the next session is calmer than ts bro it took way too long

Meteor Shower Tracker

finished the last feature, a year-round meteor shower schedule with active/upcoming status so you actually know when to set an alarm. 11 major showers baked in (Quadrantids through Ursids), and everything’s calculated client-side, no API needed.

• stores absolute peak dates for each shower and works out the active window locally, correctly handles the year-boundary ones (Quadrantids starts Dec 28, Ursids ends Dec 26) without breaking on Jan 1st
• sorts active showers first, then whoever’s next peak is soonest
• countdown properly distinguishes “peak in Xd” from “peaked Xd ago” for showers you’re still inside the window for but already past peak on, caught that bug and fixed it before shipping by testing across multiple dates including exact-peak day (Aug 12 for Perseids)
• renders as a compact list with radiant constellation, ZHR (~Zenith Hourly Rate), and the peak countdown, all colour-coded so active showers pop
• no polling, just recomputes fresh every time you open it

Bug Fixes & Polish

went through all three files line-by-line before shipping. found and fixed two bugs plus some cleanup:

• window snapping corners were broken — getSnapZone() detected top-left/top-right when you dragged to a corner, but showSnapPreview() and applySnap() never had rect definitions for those zones, so the preview showed nothing and the drop silently failed. added proper quarter-tile rects for both corners so you can now snap to all four quadrants
• APOD toggle IDs — getElementById() calls for apod explanation/toggle buttons were working but the elements weren’t explicitly in the HTML, they were created at render-time by innerHTML, so the id references were technically fine but fragile. left them as-is since they work, but flagged it as something to refactor if we add more dynamic content later

also ik its been shown in an earlier devlog, but the taskbar on the bottom isn’t exactly empty lol, you can minimise apps to it (third pic). maybe i’ll add a pin to taskbar feature?

what’s left

SHIPPPPPPPPPPPPPPPPPPPPPPPPP

Tiny fix lol

I stopped good ol’ neptune being cut off on the solar system map, and also made it so that the contents of the notepad/mission log are saved in localStorage

Solar System Viewer

• Thought it’d be cool to have something you could just leave open on the desktop, so I added a little live Solar System app. Every planet sits where it actually should be today rather than looping around on some fake animation.

• Planet positions come from simplified J2000 Keplerian elements (semi-major axis, eccentricity, orbital period, etc.) and get advanced from the current date, so they’re calculated fresh instead of being hardcoded.

• Conveniently I’d already written a Newton-Raphson solver for Kepler’s equation while making Umbra, so I shamelessly reused it here to solve the eccentric anomaly before converting that into the planet’s true anomaly and distance from the Sun. Nice when old suffering becomes reusable code lol.

• Biggest headache honestly wasn’t the orbital maths, it was the scale. If you draw everything linearly then Neptune disappears off the edge of the canvas, but if you squash everything too much then the inner planets all merge together. Ended up scaling the orbital radius by √r instead, which keeps the angular positions correct while compressing the distances enough that the whole Solar System fits on one screen.

• Made every planet clickable as well because a static diagram felt a bit dead. Clicking one gives its current distance from the Sun and orbital period, with Earth getting a little highlight ring so it’s easy to spot where we are.

• It redraws once a minute since the planets barely move on human timescales anyway, and it’s definitely not accurate enough to navigate a spacecraft with, but it’s surprisingly close considering it’s just running a handful of orbital equations in the browser lol.

deffo gonna play around with the window sizing cause its kinda weird right now… also neptune is STILL SQUASHED (genuine annoyance btw) so will do this TOMORROW.

Umbra — Adding Some Chaos (On Purpose)

• Real telescopes don’t hand you a perfect light curve, they hand you a noisy mess with a signal buried in it, so I added a noise toggle to make Umbra actually look like real data instead of a simple ahh textbook diagram

• Used a Box-Muller transform to turn two uniform randoms into a proper gaussian sample, tuned roughly to TESS-scale scatter so it’s not comically noisy, just enough to make the dip look like something you’d actually have to squint at

• New “N” button sits next to the reset one, goes amber when it’s on, same button family as everything else up there

• The bit I actually spent time thinking about, which was that the noise only touches what gets drawn on the graph, not the underlying flux value. Transit detection, transit counting, period measurement, and the stats panel all still read the clean number

• I wanted it this way on purpose, in real analysis you don’t just throw the noise away, you fit the curve through it, so having Umbra’s detection stay accurate underneath a noisy-looking graph felt like the more honest way to represent that, rather than making the sim itself worse at its job just for realism points lol

Stargazing Conditions

New app, tells you whether tonight’s actually worth setting up a telescope for.

• pulls cloud cover, humidity and wind from Open-Meteo using the location I already grab on boot, no key needed which is nice
• the moon phase bit doesn’t touch an API at all, did it properly with the synodic month (29.53 days) against a known reference new moon, so it’s just maths running locally
• combined cloud cover and moon brightness into a rough seeing score out of 10, heavier cloud and a brighter moon both drag it down, then a one-line verdict underneath so you don’t have to interpret the number yourself
• was gonna render an actual crescent/gibbous moon on canvas for this but after the ISS ground track thing broke last time I didn’t wanna ship more clipping/arc geometry I couldn’t properly test, so it’s just the phase emoji + name + illumination % instead. honestly looks fine, might revisit the canvas version later if I’m bored

Umbra - Making the Dip Actually Mean Something

• Kepler solved the “where the heck is the planet” issue, but I still had a “how much light does it actually block” issue, and the answer wasn’t as simple as I first thought
• My first instinct was just measuring the distance between planet and star centres and eyeballing a dim amount from that, which is wrong the second the planet is anything other than fully in or fully out
• What you actually need is the overlap area between two circles, so I built circleOverlapArea() using the proper lens equation, it takes the centre distance plus both radii and works out the exact overlapping region
• This is what gives you the sloped ingress and egress on the light curve instead of a dip that just snaps to a flat bottom, which is a lot closer to what a real transit looks like
• Also added depth ordering off the back of this, since I needed to know when the planet’s on the near side of the orbit vs the far side so it draws in front of or behind the star correctly (sin of the eccentric anomaly tells you which side you’re on, handy)
• Once the flux number was actually trustworthy, I edited the instrumentation to go with it:
  • fixed the stats panel (radius ratio, current flux, transit depth, max depth, eccentricity, transit count, measured period)
  • rising-edge detection so it counts transits and times the period itself, rather than me just reading it off the speed slider
  • fixed the light curve graph itself, plotting flux over time with gridlines so you can actually see the dip shape as it happens

Genuinely didn’t expect the geometry bit to be the harder half of this session, Kepler felt like the scary one going in but the overlap maths turned out to be the fiddlier of the two!

I also distributed all my code into separate files as for some reason I put it all inline in one html file and I got some reviews about file structure on my other projects, so didn’t want to repeat that lol

ISS Tracker 

New app, tracks the ISS live using wheretheiss.at (no key needed, CORS-open, genuinely such a nice API to work with). 

• Polls every 5 seconds for lat/lon/altitude/velocity

• Keeping the last 20 fixes so there’s a fading trail behind the current position instead of just a dot that teleports every update

• Drew my own little world map for this since I didn’t want to deal with map tile assets, just lat/lon gridlines every 30°, equator and prime meridian slightly brighter.

• I reused the geolocation I already grab on boot for the sky map, so this app also shows your distance from the ISS via a haversineKm() calc, and flags when it’s within ~2000km with a little “nearby!” tag. Not a proper overhead check (that’d need elevation angle above your horizon) but good enough for now

• Added a stopIssTracker() call on window close so the polling interval actually dies instead of running forever in the background, learnt that lesson the hard way after leaving a tab open for way too long testing this

At the time of writing this I had just the idea to implement a trail that shows the future path, will do this now lol.

APOD Viewer 

Added the Astronomy Picture of the Day app, pulls straight from NASA’s API and shows today’s pic with the write-up tucked behind a toggle so the image gets to be the main object first. 

• Cached in localStorage per calendar day, so reopening the window doesn’t burn another call for the same picture

• Nearly got got by this one: NASA sometimes serves a video instead of an image for the day, and my first pass just shoved the url into an <img> tag, broken image icon staring back at me lol

• Added a media_type check so videos link out instead of trying to embed

• Also handled the fetch failing outright, just shows a “try again later” message instead of leaving a blank window, DEMO_KEY’s rate limit is gonna trip this eventually so it needed to fail gracefully lol

what’s next?
either stargazing conditions or the ISS tracker, we’ll see which one I go for

GRID Begins

Third simulator in the lineup, and this one’s a spacetime mesh, so instead of watching an object move through space you’re watching space bend around it.

• Started with a plain grid of points, then had to figure out how to actually pull them toward a mass without it looking like noise. Went with an inverse square-ish falloff (not GR accurate, more of a stylised well for now) and it clicked visually with barely any tuning.
• The annoying part was stopping the mesh folding back through the mass itself when you drag it in close. Lines were crossing over each other and it looked completely broken. Fixed it by clamping the pull so it eases off the closer you get instead of spiking, simple fix once I saw what was actually happening.
• Kept tonight deliberately small, one grid, one draggable mass, nothing else. Wanted to prove the warp looks proper before building anything on top of it (that went well for g-lens lmao)

Next up: strength slider and a reset button, then a second mass to see how two wells interact with each other.

Umbra — Kepler’s Equation Nearly Broke Me

• So remember in the first devlog when I said I spent 2+ hours just getting the orbit right? Turns out “right” was still wrong, the planet was moving at constant angular speed the whole time, which is basically not how orbits work

Real orbits speed up near the star and slow down far away (thanks Kepler), so I had to actually solve Kepler’s equation properly instead of faking it
Problem is M = E − e·sin(E) has no closed-form solution for E, you can’t just rearrange and solve for it like a normal equation, which I did not know going in and briefly panicked about

Ended up using Newton-Raphson to solve it numerically, feels very full circle after doing the same kind of thing for my EPQ (orbital sim for near-Earth objects), except this time it’s converging in like 5 iterations instead of me validating against JPL Horizons for weeks lol

• The difference is honestly crazy to look at now, the planet visibly rips through periapsis and crawls through apoapsis instead of just gliding round at one speed the whole way, which is exactly what real eccentric orbits do

Pretty happy with this 4 hours cause it means I now have actual physics rather than some fake thing only added for the visuals.

below are some snippets from the solvers but not the full code of course

StarDeck - I ADDED LEDSSS YESSS

this took way longer than it should’ve lol

well, i’ve finally wired up the LEDs to the xiao, hopefully with the way i’ve placed them, it’ll make for some nice backlighting!

what could I possibly have been doing for 1 hour?
no clue, honestly. probably just moving stuff around lol cause I was switching between designs a lot, finally settled on this design (2nd image i think) but I have no clue where the xiao should go, cause ideally it would be at the top but that’s where the screen is and on kicad it keeps flashing red everytime I try putting it there (trying to place it like the 4th image). I’ll try figure out if that’s an issue or just kicad being annoying. but all in all, a pretty annoying week on this project lol.

StarDeck - pin HELL on my schema right now

Like many others, I want to make the most of the hackpad funding.

However, considering I have no hardware experience (and hence have no idea what other parts to buy, if any), I am limited to the kit’s contents at the moment. So, I have spent the last two hours, while sorting out some wiring, how to optimise my pin usage so that I can have a good amount of components while keeping a good design.

Now, my current design uses 7 keys and 1 rotary encoder. This, as you can probably see from my PCB screenshot, is not too symmetrical. This has been bugging me since I started this. So with some help from the slack, I added the rotary encoder to the key matrix (hopefully correctly), and have saved a total of…. 1 pin!

Now this isn’t enough to add a second rotary encoder, based on my current design, so I am desperately looking for a way to save one more pin so my design doesn’t look lopsided, but if worst comes to worst, I’ll just change up the layout honestly, maybe have 5 keys on the bottom, then 2 keys and the rotary encoder on the top, then the screen above that (as I’m writing this, I have realised that this isn’t a bad idea).

Anyways, as always, if you have any suggestions PLEASE PLEASE LET ME KNOW I NEED YOUR HELP and I will be spending the rest of my time researching and asking people, trying to find any way to get a second rotary encoder.

Well, at least its not the end of the world if I don’t have two.

StarDeck - building a cool macropad with ZERO prior hardware experience

So, not sure if you can tell by my projects, but I work mainly in software. This project has already been driving me nuts, and claude has been… a bit less than useful so I’ve decided to just firm it and figure it out myself.

To be fair, a lot of the timelapse for today was just me referring to the guide half the time, but I got it (I think??) in the end and have finished the schema, only thing left is to add the footprints which I cannot figure out for the life of me, #hackpad here I come!

I thought this would be a fun challenge cause I’ve always wanted a streamdeck or utility keyboard of sorts, and being able to make my own personal one just makes the end product fit my needs better. So far, I have 7 keys, an LCD screen, and a rotary encoder which I hope are wired up correctly. I am thinking of replacing one key with another rotary encoder and adding 3 more keys to keep the shape, but I’m kinda limited on pins and am not planning on buying a GPIO expander (I think that’s what they are, someone mentioned it to me). More wiring is jus t gonna be harder for me to understand, so I might just keep it at one rotary encoder, or have two and just replace a key. That would give me 6 keys and two rotary encoders which is more symmetrical.

Anyways, that paragraph was just a dump of my thoughts, but yeah here’s the current schema!