site banner
ArjinFerman  Tinfoil Gigachad  3d ago (text post)   250 thread views

Tinker Tuesday for August 11th, 2026

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service.

1
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

Didn't do much in terms of code, but for a change of pace I started working on a story board for the game's intro. I think I'm about 50% done.

How have you been doing @Southkraut?

Thanks for asking, as always.

Doubled back and completely reworked my UI from the ground up to use custom C++ clases derived from Unreal's native UI widget classes, instead of composing UserWidgets out of native elements. They're still exactly as reusable as before, but now I can nest them without the need for intermediary "slot" elements that cluttered up the hierarchy. To still be able to WYSIWYG the design of those elements, I introduced a Style data asset that I can edit in the editor without needing to tweak anything in C++. Best of both worlds, it seems. I'm sure I'll realize somewhere down the line why this was dumb, but for now it looks good.

Then I did some more backend work to make sure that everything from the main menu to the strategic game mode to the combat game mode flowed nicely, including loading screens. Nothing fancy, literally just empty levels, completely black, that present "Loading." in the center of the screen. Added a menu to select from three different levels for the combat mode: one fully procedural, one fully pre-generated, and one with procedural landscape but pregenerated lighting. Then I spawned my first "enemy" into the combat level, and he promptly fell over, being a mere capsule with a rectangular "gun" sticking out, and could not get back up, lacking any sort of self-righting ability or indeed any behavior at all. I then wrote some stubs for exactly that behavior, and for the perception logic of combatants, and called it a day, and indeed a one-and-a-half weeks, since I'll be going on vacation tomorrow.

Didn't do much in terms of code, but for a change of pace I started working on a story board for the game's intro. I think I'm about 50% done.

Whoa. I didn't see that one coming. What's your workflow there?

Whoa. I didn't see that one coming. What's your workflow there?

A combination of modest ambitions, and AI slop. I'm planning to tell the whole story with handful of stills, and some spoken dialogue. The workflow is:

  • generate a sketch
  • throw it into PowerPoint (most of the dedicated storyboard software was either overkill, or expected me to be able to draw, rather than import a ready image)
  • write dialogue

The middle section of the story is 90% reusing the same sketch (there will be some animated details, but here I'm just describing them, rather than showing them explicitly). Most of the variation / actual work is in the beginning, to establish the scene, and will be at the tail end of it, with a little montage of the protagonist preparing for the alien invasion.

It's also possible that I'm overestimating my progress, let's see.

So I'm still plugging away on my silly Minecraft project.

I integrated the Starlark scripting into the MCP. It works well and it solved the "too many tool calls" problem.

A couple of videos demoing stuff below. There's the Starlark service generating buildings and it also has a library of schematics tagged in elastic search.

Claude and Codex both mostly went with Starlark example files and things from the schematic library. One problem I have is that there's no rollback function so I can't tell it what it did wrong. It would have been a better demo if they had come up with some unique buildings, which they can do.

It does love to just paste in long identical surfaces. I'm wondering if I can do some sort of auto-greebling pass to make things more interesting.

The underground dungeon does mix things up a bit, I added some randomness to the dungeon example file.

https://rumble.com/v7dziqq-minecraft-starlark-mcp-demo-build.html

https://rumble.com/v7dzjvc-vibebuilding-in-minecraft-with-mcp.html

I've continued noodling around in my side project. Improved execution time of a unit of work down to about 1/8th what it was. I experimented with an OpenGL synchronization context that I can fire off tasks too for GPU work, but there was too much overhead somewhere for it to be an improvement. LLM summaries pointed the finger at poor resource management in the context, and the overhead of creating new rendering targets, marshaling the resulting data back from the GPU to the CPU, marshaling that data out of the thread, etc, etc. I'm not interfacing directly with OpenGL though, I'm using a SkiaSharp canvas, so there is probably ample room for improvement there if I wrote my own shader and really did all my own GPU work.

Well... a few weeks ago I got laid off. The cool thing is I get 90 days to do "knowledge transfer," then get another five weeks of severance. So, I'm basically set for the year. (Full disclosure: I'm 53. I tried to retire before this, but got sucked back in.) My manager was also laid off and her directive was to basically fuck off and do the bare minimum.

My background is firmly on the software side of the world. Electronics have always been a fascination for me. I've been tinkering with this stuff since the early '80s, but never fully found the motivation to really pursue it for some reason.

So this May rolls around (well before the layoff), and I decide to make a controller board to replace the one in my smoker. It decided to act weird and I got frustrated. This isn't a rational decision because a new one is cheap compared to what I'm doing. I dove in with Claude Code and built a full PCB design platform. (No, I'm not replacing KiCad, et. al. The is the netlist generation side, heavily leaning on SKiDL.) That project grew and grew. Out of control basically. I even laid out a PCB and fabbed it. And it mostly works, amazingly enough. (I also learned to not try to hand-place 0402 parts because that sucks.)

The other side of this is building a complete firmware system from scratch. And now most of that actually works as well. I'm planning on open sourcing this part.

Then, right before I got laid off, I decided to pivot the hardware side. Without getting into too much detail (for fear of abject boredom, not secrecy), the new target is a line of modular, low-cost lab instruments. "Weird" shit. Things that I want to play with. Things like a lock-in amplifier, a source measure unit, precision DAQ (and a bunch of other stuff). That combined with the firmware makes some experiments way easier than the "real" instruments because you have multiple instruments sharing the same core.

Basically, I want to bring down the cost entry for some of this stuff a lot lower. But still have a real calibration story so people can do real science. And to bring the cost of these instruments down in general.

TL;DR: My side project turned into my job (hopefully). Fingers crossed I can pull this off and not lose my shirt too much!

On AI. Without AI this would have been folly to even attempt. My best guess for what this would cost without AI is on the order of $5-10MM to hire a team of experienced devs for a year or two. This is not something I have knocking around in my bank account. If I would have tried to develop this myself (without AI), it would take me the remainder of my life basically. As a bonus I would come off as a crackpot: "I have the perfect way of designing firmware! Just you wait and see!" With AI, I can make this real in a matter of months as an individual.

Good luck on the business side. Specialized hardware dev is a really important field, but it's a very feast-or-famine one.

This sort of work where all the individual pieces probably existed somewhere in some parallel or non-overlapping field, but either haven't been put together or haven't been applied in the form you want, seem like some of the best use cases, whether code-focused or otherwise. I've been working on a modified micropython firmware to support wifi programming, debugging, and breakpoints for simple programs, and it's still nowhere near ready for primetime, but it's much closer in a couple nights and weekends than I would have gotten in weeks or months of day job work before modern LLMs.

Would be interested to see the firmware system if you open source it.

Thanks! The hardware side has gotten so much (relatively) cheaper and accessible than before... I figure not counting my time (which my present company is paying for now), I'll need to sink $20-30k to have a couple spins and enough stock to hopefully sell. I can cover this myself. I figure this is a bet on myself and I can stack the odds as much as I can.

And you nailed it on the "what's already out there" aspect. My working model is that there are cool chips out there that do neat stuff, the challenge is going from a dev board to something that actually works. One of the more esoteric things I'm thinking about is something like a isolated biopotential interface. It's basically doing the design work to wrap an ADS1299 (https://www.digikey.com/en/products/detail/texas-instruments/ADS1299-4PAGR/6590685) with the appropriate front-end and connect it to a processor. There's no genius in that.

The interesting thing is all from the firmware. To do something useful with that in a non-trivial way -- beyond the typical Arduino/Raspberry Pi toy demos -- everything becomes "ok, we'll need to spin up an RTOS and do a bunch of work" and you give up and buy the instrument that's $1k and move on. The firmware side is cool because it's mostly declarative.

Again, this is nothing really new. LabView had that model back to at least the '90s. The idea of a driver having virtual "wires" being connected is right out of SCADE. But I've not really seen this on a firmware level. The thing that I always run into is even configuring a processor is a pain.

My product is basically:

  • A cheap base with the processor -- that can be dynamically configured by the firmware to accept...
  • A family of instrument cards that plug in to the three exposed ports.

You then have a declarative profile that can wire up things to do what you need. The goal is to replace a stack of instruments with all of the scripting glue that runs on the host and have it all run on a cheap, trustworthy instrument.

Something kind of like this:

# How much of your 10 uF capacitor is left at 10 V?
#
#   Instrument Slot A -- B4 lock-in: a 50 mV, 1 kHz probe, and a phase
#                        reference to tell the capacitive current from the
#                        lossy one.
#   Instrument Slot B -- A3 SMU: the DC operating point, held and measured,
#                        with a compliance limit so a shorted part is a
#                        clamp and not a fire.
#
# Neither card is a better version of the other. The SMU has no synchronous
# detector: it cannot pull a microamp of 1 kHz current out of a 10 V DC
# pedestal. The lock-in has no source with compliance: it cannot hold that
# pedestal. The experiment needs both, on the same tick, and the only thing
# composition costs here is a bias tee in the fixture (100 kOhm from FORCE,
# blocking cap from EXC OUT, the far plate into the TIA's virtual ground).

profile:
  name: mlcc_bias_derating
  version: 0.1.0
  schema_version: 1
  tick_hz: 100

ui:
  parameters:
    - { id: f_hz, type: q16, default: 1000.0 }   # test frequency
    - { id: v_ac, type: q16, default: 0.05 }     # 50 mV -- small-signal, on purpose
  surface:
    - { wire: var.cap_uf,       role: readout, label: "C",   unit: "uF" }
    - { wire: sig.v_bias,       role: readout, label: "Vdc", unit: "V" }
    - { wire: smu1.sweep_start, role: action,  label: "Run", key: f1 }

variables:
  - { id: cap_uf, type: f32, initial: 0.0 }

blocks:
  - id: smu1
    kind: smu                        # Slot B
    params:
      mode: source_v
      sense: four_wire_measure       # the bias resistor's drop stays out of the reading
      compliance_i_a: 0.001
      nplc: 10
      sweep: { start: 0.0, stop: 10.0, points: 41, spacing: lin, dwell: 2.0 }
    out:
      v: sig.v_bias                  # the volts actually across the part
      i: sig.i_leak                  # a second curve, free: leakage vs bias

  - id: li1
    kind: lockin                     # Slot A
    params:
      mode:         impedance
      ref_source:   internal
      excitation:   sine
      input_mode:   current_A        # the 10^6 V/A TIA takes the cap's AC current
      coupling:     ac               # the 10 V pedestal never reaches the gain chain
      sensitivity:  auto
      time_constant_s: 0.3
      slope_db_oct: 12
    in:
      ref_freq_hz:  ui.parameters.f_hz
      excitation_v: ui.parameters.v_ac
    out:
      y:         sig.i_quad          # autophase first: the capacitive current lands here
      theta_deg: sig.loss_angle      # and the loss angle comes along for nothing
      overload:  sig.li1_ovld

tasks:
  - id: report
    triggered_by: { tick_periodic: 500ms }
    body:
      - write: { "var.cap_uf": "1.0e6 * sig.i_quad / (6.2831853 * ui.parameters.f_hz * ui.parameters.v_ac)" }

Something like this is obviously "easy" to do if you have both a source-measure unit and a lock-in amplifier and a script. My goal would is to be able to sell something that can do this for maybe $1000, and that leaves a lot of margin.

The other angle I have on this is that something like this is far easier for an AI to write and reason about than normal firmware.

I have an absolute crap-ton left to do. Maybe 60% of the firmware is ready to do this and probably closer to 30% on the hardware side.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats