I was recently rummaging through a storage closet, when I discovered a box I didn't recognize. Inside, I found the barely-used Recon Instruments Jet "smart glasses" that I had impulsively preordered back in 2013.
My original interest in the glasses was not for their designed purpose, but instead for the potential of hacking them into a HUD for my motorcycle helmet. Recon advertised that they planned to release a SDK, and for the purposes of my project, a weather-resistant $500 display was far more palatable than the delicate-looking waitlisted $1,500 Google Glass.
By the time they actually shipped in 2015, the public had developed strong opinions about people wearing internet-connected cameras on their faces. Undeterred, I was still hopeful that they would work for my helmet project, or would at least provide some utility on my daily bicycle commute to San Francisco.
My initial test wearing the glasses while on my bike was quite disappointing. Evaluating the product at face value (ha!), the Jet's apps just didn't provide enough added value to justify wearing them. You can get more accurate data from a $25 cycle computer, music sounds better in earbuds, and if you're lost on a bike or you get a text message, it takes 30 seconds to stop and peek at your phone.
The uninspiring default apps were not the showstopper for me, though. Setting aside the difficulty of getting used to the obtrusive opaque display mount, the optics were... bad. There wasn't much adjustability, and it was nearly impossible to get the display both fully in focus and fully visible at the same time. (The Terminator would have hated this display!) The bright backlight and soft-focused edges made the screen look more like an old CRT than anything out of my sci-fi fantasies. The Jet's UX was thus almost necessarily awkward, legibility concerns on the tiny panel dictating using a large font that limited how much information could be presented per screen. This then meant many more screens, and a lot of navigating and paging around with a temperamental touchpad.
I packed the glasses back into their case after a single ride, with the intent to sell them when I got around to it. However, at that time I was a preoccupied parent of a 2-year-old, and had just started a new job.
So, I instead immediately forgot they existed.
Until 12 years later!
Recon Instruments was acquired by Intel in 2015, and shut down in 2017.
I didn't intend to launch into a project. I was just planning to reacquaint myself with the glasses, mostly to decide whether it was worth trying to sell them for beer money, or whether they were basically e-waste to recycle. Naturally, after over a decade, the batteries were very dead. Not only did they not hold a charge, but the Jet wouldn't even boot, even when plugged into USB. Before writing them off as scrap, I decided to first try some battery surgery. The battery module is a removable pod on the opposite arm from the display (which does a good job balancing the weight).
Inside the pod is a small charge management board (with 3 spring-loaded contacts) that also acts as the connection to the glasses, powered by a 490mAh 3.7v LiPo battery (701547). I have lots of 3.7v LiPos kicking around, but unfortunately all the wrong size. As a "temporary" test, I desoldered the old battery from the charge management board, and soldered in a larger battery via pigtails.
Once it had continuity to a battery with some voltage, the Jet booted right up!
But now they were in a weird state, cracked open, with an ugly battery dangling off the side. Nobody's going to buy them for cycling in this condition...
It was October 16, 2026. This context is important. I didn't have any plans for the glasses. But this was the month when the Internet collectively discovered they could use AI to reverse-engineer everything.
So naturally, I pointed Claude Code at the Jet and said "heyyyy...."
I have decades of experience writing high-level code, but I've also worked on a lot of low-level systems. I've written kernel drivers from hardware specs, reverse engineered proprietary code using only strace, used logic analyzers, soldered connections for snooping diagnostic ports, and spent considerable time poring over tcpdump logs. I've written compilers and built embedded systems for robots. My point is not to brag, but just to disclose the sort of knowledge I was bringing to the project. Having worked "close to the bits" certainly enables me to prompt more effectively than a total novice, but the sheer velocity of an LLM doing the heavy lifting was simultaneously amazing and ego-crushing. My experience just wasn't all that critical.
Within the first day, the Jet was rooted, the critical hardware was mapped out, and a replacement menu system was up and running on Android. On day two I decided I wanted to swap Android for Linux. The drivers for the display, input, battery management, and WiFi were all quickly ported. Rendering the kernel log to the display for debugging.
A weekend or so later, here's Claude's executive summary of the hardware situation:
A Recon Jet (TI OMAP4430, 1 GiB, 8 GB eMMC, 428x240 Kopin microdisplay, camera, two mics, speaker, IMU, WiFi/BT) boots mainline Linux 6.18 from its eMMC boot partition in under four seconds to a live display, with the rooted stock Android kept in the recovery slot as a fallback.
Every piece of hardware the project needs works from mainline: display, touchpad, both buttons, camera, WiFi, Bluetooth (LE keyboard paired), speaker, microphones, IMU, barometer, proximity "glance" sensor, board temperature, charger and fuel gauge, power LED, watchdog, RTC.. GPS works through the stock TI daemon in a chroot.
Not ported:
FM (removed driver), the Apple MFi coprocessor, and the speaker's DSP tuning.
I can't imagine how long it would have taken me to get to the same point coding all this on my own. Months? Years?
Although I didn't enjoy using the Jet as an end-user product, the physical hardware is pretty impressive for 2013. The designers were operating under extremely challenging space and power constraints, yet they crammed tons of functionality into a tiny space, and claimed a four hour runtime. Even after trying to build a "low power" mode, my replacement software runs extremely thirsty compared to the default product. (I'm constantly pulling over 300mA, yielding a battery life closer to 1 hour. Good thing I don't need to market and sell my version to bicycle-racing weight weenies! For hacker glasses, a USB tether to a powerbank to extend runtime feels like a completely reasonable solution.)
As far as my application software goes, it's kind of a hot mess. When I started, I didn't have any concrete plans beyond a proof-of-concept: "replace the stock software". Without a concrete product in mind when I started, every time I subsequently had a new idea, it strained the architecture of the current implementation.
Where things landed is a compromise.
A small static C daemon (jetd) owns the panel and inputs, and is controlled using a line protocol on a local socket; a NodeJS application (jet-app) on the device owns the user interface as a set of "app mode" plugins.
There is a bit of awkwardness in that jetd does some UI on its own. Notably, it owns the kernel log display, and the interactive shell terminal. If jet-app isn't running and connected, jetd switches to a "deadman" mode to enable access to these low-level tools.
fbcon framebuffer console resulted in a long phase of tedious kernel deadlocks that required manual intervention to restart the device. It proved to be easier and safer to just have jetd just tail /dev/kmsg which worked for debugging almost all real problems I encountered. For fixing low-level crashes, the boot guard automatically skips chronically failing kernel modules, and messages emitted before jetd runs are persisted in "oops" or dmesg logs.
Platform capabilities (provided via Linux kernel drivers and the jetd daemon):
- Local graphics API to draw to the display
- Microphone access
- Speaker access
- Input via two buttons plus a trackpad to detect swipes
- Shell mode
- Kernel log mode
- Networking via WiFi and USB
- mDNS publishing as
jet.local - VPN access via WireGuard (to access my homelab services)
- Remote ssh
- Bluetooth keyboard
- Camera image capture
- Glance detection
- GPS
- IMU
- Power management
- Remote API for debugging, system settings, camera capture, and remote "screen sharing", including audio and inputs.
The system was ready to build... something. But what?
Having abandoned the idea of using the Jet in my motorcycle helmet, I had a few alternative project ideas that intrigued me:
-
Augmented senses. Could the glasses continuously provide extra information about the world that either I can't normally see, or that I'd need to do extra work to interpret? Examples: automatically show QR/bar code information, compute and compare unit pricing for products at the supermarket, interpret resistor color codes when I'm at my workbench, show nearby wifi networks, recognize and deep-dive specs for ordinary things around me, etc. It turned out that the Jet's camera's focus and exposure weren't well-suited for tasks like desk-distance resistor band identification, so I quickly realized this idea had some basic hardware limits attached. I still like the basic concept of augmented senses a lot, though. It's the primary feature I'd want from real AI glasses.
-
An OSINT interface. Inspired by God's-Eye View , display relevant info about my location on a continuously updated map, such as crime alerts and known surveillance cameras; allow viewing real-time stream from public traffic cameras. While this seemed cool at first (in addition to too many sci-fi movies, I've watched too many spy movies) I then realized that not only do I not need a real-time intel feed to survive my bike ride to the coffee shop, my town is pretty boring, and any data would be limited and repetitive. (There was a fire a few blocks away... three weeks ago, and yep, the Flock camera is stillll on the corner!)
-
In the late 90's, I had been fascinated by Thad Starner's work at MIT Media Lab on wearable computing, in particular the concept of a "remembrance agent " - a continuously running automated information retrieval system displaying a feed of relevant stored memories. I wondered if I could build a lightweight version of this idea. It seemed like it could pair well with an augmented senses feature.
As a general rule, when the scope of your "weekend project" starts bumping into someone's PhD thesis, it's probably time to reassess the feasibility of your plans!
AI glasses are not a solved problem, so it was clear further work on this project would require endless iteration. Alexa and Siri provided a sobering reminder that commercial AI products with huge development budgets and years of development remain frustratingly crude and limited... and I'd be tackling this with precisely zero experience building even a basic interactive voice assistant, never mind one with a camera and lots of other sensors!
Even armed with agentic superpowers, I had to concede that almost any useful AI glasses build would require far more work than reasonable for a one-off hack... especially for a one-off hack motivated more by engineering curiosity than any actual intent to actually... use them.
I thus decided that the milestone for "Part 1" of this project should be far more humble, focusing simply on exercising end-to-end functionality:
I want to be able to speak to the glasses, request analysis of the current camera view, and then receive a description of the scene; details as text, and the summary or commentary as a voice response. A decade ago, even this would have been a huge project. In 2026, it proved to be completely reasonable, providing valuable experience in building a different type of agentic loop than I had every built before. I even went a bit beyond the basics. To make things more interesting, I decided that instead of building a generic "helpful assistant", it would be more fun to give it some personality. I also built in a (very) rudimentary "world model" to capture details of things seen by the camera.
Here's where things stand:
The interface is built as set of menu-selected modal screens.
The menus can be navigated using the physical buttons on the glasses, or using a Bluetooth keyboard, or for debugging, using the jet live remote mirror page shown above. You can also select modes using voice (more on this below).
Log Mode was described previously.
Shell Mode does what it says on the tin. It even supports ansi color, allowing tools like htop to look pretty. Thad Starner's wearable interface relied on emacs, my favorite editor, so naturally I needed to make sure that also worked. I don't have a Twiddler for input like he used, but my tiny Bluetooth keyboard works fine for occasional typing.
Map Mode is pretty crude, and was built primarily as a punchlist item to exercise the GPS. It provides a limited ability to zoom and pan around your current location. The free OpenStreetMap layers are very desaturated and low-contrast, which made them hard to see on the device, especially during daylight. I briefly poked around a bit to try to find better renditions, but didn't find anything that worked well.
Describe Mode, Assistant Mode, and Scan Mode are three different but interconnected AI experiments. Before getting into any of them, it will be helpful to first explain the architecture.
While some Jet features run entirely on the device, many capabilities rely on network services. For these, the Jet is essentially acting like a thin I/O interface. For example, the Jet runs an "agent harness" locally, but the AI "brain" is external: vision, speech recognition, language models and speech synthesis all call remote APIs.
I knew performing continual processing of the camera would necessarily be burning tokens non-stop, so to save money, I wired all AI to the llama-swap server in my homelab (bonus: late-fall house heater!) The glasses don't have cellular, so out in the world they use my phone as a WiFi hotspot, and connect to these services through a VPN.
I already had coding and general inference models installed, but I needed to set up models for vision, speech recognition, and speech synthesis. For a voice assistant, these needed to be tuned for low latency streaming. I don't use all of these for the Jet, but it gives you an idea of what I have available:
(I keep small models resident, but the larger models can't run simultaneously.)
"Heya, Jet!"
This wake phrase uses a microWakeWord model trained on the Mac. It runs locally on the device beside jetd, and requires less than 2 % of a core.
Because the remote AI models are running on a relatively small server (a 128GB AMD Ryzen AI Max 395+ "Strix Halo"), there's more latency than if I were hitting a commercial frontier model running in a data center. To cover up some of the dead time, I decided to "cheat" by incorporating latency into the character and interaction design. Instead of portraying the glasses as smart, the AI role-plays as "Jet", a somewhat cranky remote NPC operator crewmate that I'm basically calling on the radio. The glasses and slow connection and low-quality camera are just my "gear", part of my decade-old "hardware" that Jet sometimes mocks. Pre-computed voice samples played locally are used as request acknowledgement or for conversational filler when services are slow or fail to respond.
To give Jet's voice some personality, I trained a voice cloning model based on a character that seemed apropos.
This involved an entertaining sidequest building a sample extraction and model training pipeline. A custom toolchain used captions to pre-mark approximate timestamps in source media when the character was speaking, and provided an efficient UI for allowing the user to fine-tune start/end markers, and to select which regions had the best quality for use as cloning samples. (I'm tempted to polish and release this toolchain, it's pretty sweet!)
Different sample selections led to different amounts of emotional intensity in the cloned voice, so I actually provide several variants! A small "annoyance meter" tracks whether Jet is starting to get grouchy, and causes the system to choose one of these alternative voices. (There's a lot more fun work that could be done here!)
With all that out of the way, Describe Mode is a simple mode where I was testing the vision capabilities. "Heya Jet, run analysis" sends the camera's current view to the vision model, with a prompt to describe the scene in detail... and provide snarky voice commentary.
Assistant Mode is a simple agent interface that displays a conversation view, and allows you to scroll back and expand/replay previous messages. You can actually chat with Jet at any time in any mode; the Assistant Mode just presents the dialog history.
Whenever you talk with Jet, there's a tiny agentic loop running, managing memory and context, and providing a small suite of tools for hardware access, web searches, and presenting information back to the user. At the start of each user message, an image is captured and the location is recorded. It's up to the agent to decide whether to use this information in its response.
Scan Mode is the default device AI mode. When active, it continually captures images both at a regular interval, plus whenever the user has changed where they're looking (when the IMU detects a 20º+ head rotation that then stabilizes for more than a second or two). The images are analyzed to extract the bounding boxes of named entities in the scene, which are used to build up a simple "world model" for access by the AI agent.
The general idea was to have Jet act like a NPC in a game, and the named entities in the world model act like the nearby items in an old-school text adventure that you could reference. Concrete example for those readers whose birth year starts with a "2":
> enterYou are inside a building, a well house for a large spring. There are some keys on the ground here. There is a shiny brass lamp nearby. There is food here. There is a bottle of water here.
> get keysOK
Repeated views of the same entities may contribute new information that refines and enhances what is known. A small worker agent continually does data hygiene in the background, performing activities like renaming or merging entities, and expiring those that are no longer relevant.
If you select a particular item in the scan list, it is passed into the conversation context explicitly so that you can discuss it. My hacky approach led to some amusing conversations, but overall, the AI remained as dumb as a box of rocks. The small model I was using didn't exactly help here, but in addition to recording legitimately interesting entities, the vision model cheerfully prioritized random shadows it identified, filed records for painted lines in the road, misread text with confidence, and constantly rediscovered the parable of "Blind Men and an Elephant".
It became clear that my world model needed not just temporal coherence but also spatial coherence. I then spent far too much time napkin-designing a rudimentary SLAM-inspired location identification system suitable for potato-quality cameras... before I decided it was time to call it.
(As predicted, the complexity curve was going vertical.)
Wrapping up Part 1...
This project grew in scope far beyond my initial aspirations. Every new challenge was an addictive puzzle that was hard to put down!
Some interesting(?) takeaways and notes: On vibin' with Claude...
- Claude Code did an epic job at reverse-engineering the Jet. It combined information gleaned from a github snapshot of the original software, with chipset docs, with deep analysis of the running Android system.
- It also crushed it at building a replacement system based on Linux, porting and creating kernel drivers, performing low-level analysis of very fiddly initialization sequences (sometimes doing a/b tests monitoring hardware while watching how Android initialized hardware vs. how the new driver touched it). It built dedicate diagnostic tools and a whole build/deploy pipeline. It even solved a mysterious system-wide memory corruption issue by observing that the segfault data contained pixel data matching the camera's encoding!
- It frequently wanted to give up. For example, it decided that getting GPS data was impossible, and extensively documented its rationale. Subsequent rounds took this explanation as gospel. I later pushed on this alleged blocker with a single prompt, and five minutes later it had implemented a solution.
- The actual reverse-engineering hit no safety rejections at all while using Fable; considering the product is obsolete hardware from a dead company, I think this was appropriate, but I was still pleasantly surprised. Later on, something completely innocuous in the design of the replacement UI started constantly triggering
[cyber]safety rejections. It was incredibly frustrating. My only option was to temporarily switch to Opus, which struggled with the complexity of the system. - Opus (and to a lesser extent Fable, when context filled) was repeatedly over-confident that it had identified the root cause behind issues I'd bring up. It would latch onto plausible explanations without testing obvious ways to falsify the claims. The over-confidence led to documenting "facts" that then confused subsequent rounds. Sometimes the facts were completely wrong! Sometimes they were partially correct, but the implications were over-read. (Example: "enabling the bluetooth radio causes wifi to drop below 1 Mbps because they both use the same interface". It's... truthy, but the TI chip provides a whole system for dialing in coex. And it isn't actually a problem with bluetooth at idle, it's specifically during scanning or heavy data transfer; it just so happens that the default was to aggressively scan when the radio was enabled. This was just a setting, and if it had been dialed in early, many hours of retried testing when ssh went unresponsive could have been avoided.)
- In contrast to how Claude was great at the low-level work, it completely bombed at applying basic architectural hygiene. I'd been blissfully in LGTM mode, until I noticed what should have been a relatively small change yielding hundreds and hundreds of lines of codegen and multiple retests and edits. I dove in, and discovered that not only had it not been using any sort of MVC/MVVM abstraction, but a screen mode - a UI concern - was being treated as the canonical source of truth for some device model data. When access was required outside of the UI, a system was introduced for making screens go into a "background" mode when not in view. And changes from the screen-managed model data were dispatched via an event system. And a convoluted and fragile initialization sequence was used to hand references around the app to the screen whereever the model data was needed. And then there were crazy Law-of-Demeter-violating deep references to the magic screen's data, some of them polling because Claude forgot it had created an event system. And this wasafter I'd provided the app subagent my
module-managerlibrary that enables easy partitioning of functionality with IoC dependency injection and lifecycle management. The original subagent I directed had done a decent job reading my docs and examples and scaffolding the outer modules, but it left no nudges for subsequent rounds, leading to future subagents just building spaghetti instead of following any architectural discipline. Although I appreciate the practicality of a "who cares, as long as it works" philosophy that makes this kind of "bad code" tolerable, there was a clear token-and-time cost to having many thousands of lines of unnecessary slop cluttering the repo. - On the plus side, once I spanked it, it did a complete refactor that took only a couple of hours. It was the kind of complex refactoring where a human team would have said "ugh, this code sucks, but it's wayyyy too complicated to change, we'll just live with it until we do a rewrite for v2"... and then nobody touches it for a decade.
On hardware quirks...
- USB keeps disconnecting. Never got a good solution for this, just had to periodically unplug and replug. Initially there was a power draw issue, but even after ensuring we didn't go over the limit, the Mac would still lose the connection. This was a major productivity killer.
- The glasses hated WiFi channel 1. No idea why, but they basically fell off the network whenever that channel was used. I had to disable my Unifi router's "auto" channel setting.
- Bluetooth and GPS compete with WiFi for I/O. It's pretty wacky. You have to actually decide the prioritization. A keyboard that has gone to sleep sends the Bluetooth driver into a scan mode that will kill WiFi if you don't ensure it only gets to poll at a low frequency.
- The system wedged on about 1 out of 5 soft reboots. This added tedium to reflashes.
- I didn't realize that exposure compensation was clamped to small middle range until the last day I worked on Part 1. (You can see this in the Scan Mode animation above!) Allowing the chip to use the full range unlocked much better image recognition.
- Since I wasn't making any effort to conserve power, my app stack having WiFi and Bluetooth and GPS and the camera and the microphone all running at once (plus doing image and audio data manipulation) inevitably led to thermal throttling. It also did battery life no favors.
On building a local voice agent...
- I feel a little badly for talking smack about Siri and Alexa. An AI using reasoning derived from faulty facts is (of course) far worse than a simpler voice assistant with no reasoning.
qwen3-tts-cloneneeds more kudos. It kicked ass for this project.microWakeWordas well. Many no- commands like*"Heya Jet run analysis"* or*"Heya Jet enable Bluetooth"* were interpreted fully locally.- I passed unrecognized commands read from
microWakeWordto the main agent as a fallback. (Don't do this.) Jet would get annoyed at me for asking him to do things like "run an elephant" ! It would have been better to have the remote ASR model parse the original audio. - A good part of the battle of getting real latency down for an interactive voice agent using local models came down to 1) always use streaming, 2) keep small models permanently resident (TTL=0 for
llama-swap) and 3) pre-warm larger models with a cheap query at carefully chosen key points before you need them. - Pre-computed acknowledgements and conversational filler are fantastic for reducing perceived latency. Ironically, the main thing about them that stood out was that they weretoo fast!
- However, if the agent doesn't know it has "said" these filler words or phrases, you can get awkward or contradictory conversational edge effects (like "Copy that... I didn't get anything. What did you want?"
- It wasn't obvious to me when I started, but one way you can decrease voice latency is by doing speculative branching: you can start producing audio for both success and failure cases in parallel before even starting!
On obsession?
- I don't have a good justification for why I poured so many hours into building this thing. I have no use for it. The optics still suck. I ignored ergonomics, and render text too small to be easily read, especially in bright daylight. The silly AI is pathologically dumb. The hardware can't really handle my use case well, and I'm using my AI server in a profoundly unscalable manner. But... it's fun. And funny. I guess I'd file my motivation in the same category as building aV8-powered barstool . Over-engineering something useless and ridiculous is its own reward! I'm a little burned out for the moment, but I have a few things I still want to explore...
Some Ideas and Plans for Part 2 (if it were to ever happen)
- The world model needs a rethink. And 10x the sophistication. And a way to correct errors. All facts need to record provenance/confidence.
- I'm interested in providing a richer palette of ways an agent can present information back to the user. Perhaps ye olde card metaphor, but the agent can create a variety of different card types, and then the cards can be navigated on the device. Imagine if a response could be a dynamically generated animated GIF, or a tiny ephemeral Lua applet that renders and controls a micro-interface.
- To keep vision snappy, the camera currently captures low-res images at 640x480. This then results in very low-res results in the bounding boxes in scan mode. I'd like to try converting the stream to use the sensor's full 1280x960, and then having some C-based code provide a downsampled version to the Node app, and rescale the first analysis bounding box back into the higher-res image to send for a refinement pass. I'm hoping this will allow more text/labels to be read.
- Maybe port the whole concept to entirely different hardware? 2013 was an eternity ago, there's probably other hackable janky HMDs with better cameras these days! (I'm even curious how far I could get with a completely DIY HMD!)
- Need to support barge-in / interruption in the voice interface.
- Instead of a fixed set of pre-built samples for local acknowledgement / conversational filler / errors, I'd like to try treating them as temporary caches, and during idle periods, render a wider variety of phrases or sounds, in a way that makes them all sound unique.
Until then...
Go check out the GitHub repo to explore the gory details. (Hit me up if you have a Recon Jet - or the presumably compatible Recon Snow2 ski goggles - and want to try applying this code to your own hardware!)
Postscript
In case you were curious if Doom Mode is what you thought it was.
It is.
Acknowledgements and References
This project would have been impossible without the excellent works of many, many other people.
Claude (Anthropic) via Claude Code did all the heavy lifting. I was 90% product manager, 10% architect.
Major credit to the Recon Instruments Team: Kudos, you guys built a fantastic device. The fact that I'm able to use it as a functional wearable computer in 2026 is amazing!
Reverse-Engineering the Jet
- ReconOS full build tree: [https://github.com/gilzhaiek/jet](https://github.com/gilzhaiek/jet?ref=blog.v0.net)
- Stock kernel source: [https://github.com/evandcoleman/jet_kernel](https://github.com/evandcoleman/jet_kernel?ref=blog.v0.net)
- Recon HUD SDK mirrors: https://github.com/c0inz/recon-hud-sdk andhttps://github.com/gstarnet/sdk
- recom3, for the PleaseEnableADB hook: [https://github.com/recom3/api-hud-goggle/issues/6](https://github.com/recom3/api-hud-goggle/issues/6?ref=blog.v0.net)
- XDA "Recon Jet Basic Info" thread: [https://xdaforums.com/t/recon-jet-basic-info.3086703/](https://xdaforums.com/t/recon-jet-basic-info.3086703/?ref=blog.v0.net)
- Kopin WQVGA display: https://www.kopin.com/technologies-products/commercially-available-products/microdisplays/lcd-wqvga-2/
- Recon Jet user manual: https://www.intel.com/content/dam/support/us/en/documents/emerging-technologies/wearable-devices/Recon_Jet_User_Manual_June_2016.pdf
Kernel and system
- Linux 6.18 and the linux-omap work (omap4iss, wlcore, TWL6030/6040, the Epson BT-200 device tree used as reference): [https://kernel.org/](https://kernel.org/?ref=blog.v0.net)
- linux-firmware: [https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git?ref=blog.v0.net)
- wireless-regdb: [https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git](https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git?ref=blog.v0.net)
- Debian: [https://www.debian.org/](https://www.debian.org/?ref=blog.v0.net)
- BusyBox: [https://busybox.net/](https://busybox.net/?ref=blog.v0.net)
- BlueZ: [https://www.bluez.org/](https://www.bluez.org/?ref=blog.v0.net)
- WireGuard: [https://www.wireguard.com/](https://www.wireguard.com/?ref=blog.v0.net)
- wpa_supplicant: [https://w1.fi/wpa_supplicant/](https://w1.fi/wpa_supplicant/?ref=blog.v0.net)
- Dropbear: [https://matt.ucc.asn.au/dropbear/dropbear.html](https://matt.ucc.asn.au/dropbear/dropbear.html?ref=blog.v0.net)
- Zig (zig cc): [https://ziglang.org/](https://ziglang.org/?ref=blog.v0.net)
- musl: [https://musl.libc.org/](https://musl.libc.org/?ref=blog.v0.net)
- Terminus Font: [https://terminus-font.sourceforge.net/](https://terminus-font.sourceforge.net/?ref=blog.v0.net)
- Node.js: [https://nodejs.org/](https://nodejs.org/?ref=blog.v0.net)
- jpeg-js: [https://github.com/jpeg-js/jpeg-js](https://github.com/jpeg-js/jpeg-js?ref=blog.v0.net)
- tz-lookup: [https://github.com/photostructure/tz-lookup](https://github.com/photostructure/tz-lookup?ref=blog.v0.net)
- My Version Zero libraries:@versionzero/module-manager ,@versionzero/configurator@versionzero/schema
Wake word
- microWakeWord: [https://github.com/kahrendt/microWakeWord](https://github.com/kahrendt/microWakeWord?ref=blog.v0.net)
- piper-sample-generator: [https://github.com/rhasspy/piper-sample-generator](https://github.com/rhasspy/piper-sample-generator?ref=blog.v0.net)
- ESPHome micro-wake-word models: [https://github.com/esphome/micro-wake-word-models](https://github.com/esphome/micro-wake-word-models?ref=blog.v0.net)
- TensorFlow Lite Micro: [https://github.com/tensorflow/tflite-micro](https://github.com/tensorflow/tflite-micro?ref=blog.v0.net)
- esp-tflite-micro: [https://github.com/espressif/esp-tflite-micro](https://github.com/espressif/esp-tflite-micro?ref=blog.v0.net)
- pymicro-features: [https://github.com/rhasspy/pymicro-features](https://github.com/rhasspy/pymicro-features?ref=blog.v0.net)
Inference and agent tools
- llama.cpp: [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp?ref=blog.v0.net)
- llama-swap: [https://github.com/mostlygeek/llama-swap](https://github.com/mostlygeek/llama-swap?ref=blog.v0.net)
- Qwen: [https://github.com/QwenLM](https://github.com/QwenLM?ref=blog.v0.net)
- Kokoro: [https://github.com/hexgrad/kokoro](https://github.com/hexgrad/kokoro?ref=blog.v0.net)
- SearXNG: [https://github.com/searxng/searxng](https://github.com/searxng/searxng?ref=blog.v0.net)
- Firecrawl: [https://github.com/firecrawl/firecrawl](https://github.com/firecrawl/firecrawl?ref=blog.v0.net)
- OpenStreetMap: [https://www.openstreetmap.org/copyright](https://www.openstreetmap.org/copyright?ref=blog.v0.net)
- GeoNames (CC BY 4.0): [https://www.geonames.org/](https://www.geonames.org/?ref=blog.v0.net)
Doom
- doomgeneric: [https://github.com/ozkl/doomgeneric](https://github.com/ozkl/doomgeneric?ref=blog.v0.net)
- Chocolate Doom: [https://github.com/chocolate-doom/chocolate-doom](https://github.com/chocolate-doom/chocolate-doom?ref=blog.v0.net)
- id Software for releasing the source in the first place!