Devlog 3 - ITS DONE!!!

WE DID IT. THE DREAM JOURNAL IS DONE. SHIPPED. DEPLOYED. REAL. I cannot believe I’m saying this after the Devlog 1 panic session, but here we are.

The Deployment Saga

So Cloudflare and I had a disagreement. Several disagreements. Over multiple hours.

First the build kept failing because my build output directory was wrong in the settings. Locally it builds to one folder, Cloudflare was looking in another, and instead of telling me that nicely it just gave me a vague error and a failed deploy. Cool. Very cool.

Then once the build finally passed, the site deployed and… nothing worked. Blank page. Turns out my environment variables never made it to production. I had them in my local .env file, feeling all safe and organized, completely forgetting that Cloudflare has no idea those exist. Had to go add every single one through the dashboard like a peasant. Twice, because I typo’d one.

At that point my brain was cooked. So I’ll be honest with you all: I let AI handle the rest of it.

The Confession: This Project Is 10% AI

That’s right. I said it. 10% AI, 90% me crying at my keyboard.

Here’s the thing though. This is production. Real users. Real data. And my real credit card attached to that very expensive 2k server. So when the AI started pointing out security issues, I listened, because I do NOT want to wake up to a drained bank account.

What it caught:

• My API key was basically in public. Part of the AI request logic was reachable from the frontend. If anyone opened devtools they could have yoinked it and run up my bill into the stratosphere. Moved everything server side where it belongs.
• No rate limiting. Someone could have spammed the dream analysis endpoint a million times and my card would have personally felt every single request. That’s fixed now.
• Input sanitization. Turns out letting users type literally anything into a box and sending it straight to your backend is a bad idea. Who knew. (Everyone. Everyone knew. I just forgot.)
• Tightened up the CORS config from “allow everything, we’re all friends here” to an actual allowlist.

Sleeping much better at night now.

Other Stuff That Got Done

• Dark theme is IN. My eyes have forgiven me. The contrast actually contrasts now.
• CSS is finally locked in, and I was right in Devlog 1: once that was done, the rest really was smooth sailing.
• The duplicate dream bug from the testing days is long gone. The giant duck dreams rest in peace.
• Production AI is running on the 2k server and holding up. My wallet is still in critical condition but stable.

Where To Get It

It’s available soon! Check the project bio for the link. Go journal your weird dreams. The giant duck one deserves to be written down.

What a journey. From “I have made nothing” to a real live product on the internet. See you all at the next one 🫡

Devlog 2 - Ultra Crunch 2.0

Big progress today. Honestly bigger than I expected given how this week started.
The dashboard is finally up and running, which was the thing I was most worried about. Getting the layout to behave across screen sizes took way longer than it should have. There was one bug where the dream entries would just stack on top of each other and overflow the container, and I spent a good hour and a half convinced it was a CSS grid problem before realizing I had a duplicate key in my component props. Classic. Fixed it, moved on.
The API calls are healthy too. I ran into a weird rate limiting issue yesterday where Cloudflare was flagging my own requests as suspicious traffic, which took some head scratching. Turns out my retry logic was a little too eager and hammering the endpoint on every failed call. Throttled it properly and now everything responds clean.
Storage is working end to end. I can store and write dreams to the database, retrieve them, and the timestamps are behaving. Small win but it feels good.
Right now I’m deep in the Cloudflare worker, tightening up security and stability. This is the boring but critical stuff. I added input validation on the dream entries, set up proper error handling so a single bad request doesn’t take anything down, and locked down a few endpoints that were more open than they should have been. I also found a memory leak in one of the worker handlers that would have slowly eaten the instance over a few days. Caught it early, thankfully.
Next up once the worker is solid: AI based dream generation. The idea is the app will take your logged dreams and help you map patterns, themes, and recurring imagery over time, almost like a journal that talks back to you. That’s the core of what Dream Mapper is supposed to be, so this piece matters a lot.
If everything goes to plan, it ships tomorrow afternoon. Fingers crossed nothing explodes between now and then.
Let’s goooo.

Devlog 1 - IT’S CRUNCH TIME BABY

Stardance is ending and I looked back at my project list and realized… I have made absolutely nothing meaningful. Zero. Nada. So here I am, panic-building a journal for your dreams at the last possible moment. Classic me.

The Idea

A dream journal. You wake up, dump whatever weird nonsense your brain cooked up at 3am, and an AI helps you make sense of it. I’m going for a full commercial product approach with this one. I actually want other humans to use it, so it’s hosted on Cloudflare and will be live by the end of Stardance. Mark my words. I WILL SHAVE MY HEAD, I AM NOT KIDDING, if this project is NOT DONE!!.

What’s Working

• Main screen: done
• Login: done (after a LOT of pain, more on that below)
• Database: up in the back doing its job

The Pain (aka what actually happened)

Login tried to end me. Everything worked perfectly on localhost. Pushed to Cloudflare and suddenly nobody could stay logged in. Sessions just… vanished. Turns out my cookies weren’t set with the right SameSite and Secure attributes, so the browser was politely throwing them in the trash on every request. Spent way too long staring at devtools before figuring that one out.

Then CORS decided to join the party. My frontend and the AI backend live on different subdomains, so every API call got blocked until I fixed the headers. I now know more about preflight OPTIONS requests than I ever wanted to.

Database drama. My first schema was one giant table with everything crammed in. User info, dreams, timestamps, vibes, all of it. Felt smart until I had to actually query it. Redesigned it at like 11am into proper tables, wrote a migration, and immediately hit an error because I typo’d a column name. The error message was not helpful. It never is.

The white theme incident. So the current UI is white. Very white. The contrast is so bad that buttons look like vague rectangles floating in the void. Half my text is basically a eyesore. I keep squinting at my own app, which is generally a bad sign. Switching to a dark theme soon, both for aesthetics and for the health of my eyeballs.

The AI backend money pit. For testing, the AI backend is hosted on Hack Club, which works great except for the occasional cold start where the first request takes long enough for me to question my life choices. Fine for testing though. For production, it’s running on my very expensive 2k server. My wallet is crying. 😭

Honorable mention bug: dreams were saving twice for a while. Forgot event.preventDefault() on the form submit, so the page was reloading AND firing the request. Every dream, duplicated. My test account had 14 copies of “I was being chased by a giant duck.”

Next Up

• Dark theme (top priority, my eyes need it)
• Lock in the CSS
• Polish the AI responses
• Actually ship this thing

Once the CSS is locked in, I genuinely think the rest is smoooooth sailing. The hard plumbing is done, now it’s just making it pretty. Famous last words, probably.

Devlog #1: Horizon I is Taking Shape

Alright, so a lot happened. I finally locked in the first real design for Horizon I, and honestly, it feels good to have something concrete after all the sketching and second-guessing.

The big win this week was getting a rough baseline on costs. I had to run a bunch of different configurations through OpenRocket, which took way longer than I expected. Simulation after simulation, tweaking this, adjusting that. But it paid off. The current design can hit 10km including launch site altitude, which was the target I had in my head from the start.

What’s nice is the payload capacity. I can fit a lot of stuff in there without cramming, and most of the critical systems are tucked into the nose cone anyway, so the main body has room to breathe.

What’s Next

The immediate priority is the flight controller. I need to design it, submit that design, and get it manufactured. While I waiting on funding for that, I can dig into the actual technical challenges:

• Stage separation mechanics
• Nose cone separation
• Parachute deployment (specifically how it untangles itself, which is trickier than it sounds)

And then there’s the flight software. I’m thinking of calling it OpenLaunch. The philosophy is simple: if I’m building something, I’d rather build it for the majority than the minority. Open source, accessible, something others can actually use and build on.

That’s where things stand. More soon.

Devlog 6 — Sept 3, 2026

It’s been a while. My last devlog dropped right after I got back from SF (Outpost), and life immediately piled on, school, work, and a backlog of stuff at home that needed attention first. I’m back in the saddle now, juggling classes and kernel work again.

The bulk of this session wrapped up last night around 3 AM, so I skipped the write-up like my lazy a$$ always does and then and crashed instead. Here’s what shipped:

LAPIC & APIC Driver

Brought up a proper Local APIC and I/O APIC driver. For anyone unfamiliar: this is the hardware interrupt controller on modern x86 systems. It handles inter-processor interrupts (IPIs), timer ticks, and routing external IRQs to the right CPU core. Getting this right is a prerequisite for anything resembling real multiprocessing or precise timing. Including the base for future drivers.

A Real Shell

Finally moved past the “type a command and hope” phase. There’s now a proper shell with argument parsing and a few built-in commands. It’s still early, but it’s no longer a glorified echo loop that has zero stability.

Custom Bootloader

Yes, I’m writing my own. No, I’m not using Limine.

I know Limine is the standard recommendation for hobbyist kernels, and it’s a solid project don’t get me wrong, but I don’t like outsourcing the boot path. The bootloader is the first code that runs on the machine. It’s part of the OS, not a dependency. If I’m building this thing from scratch, I’m building all of it from scratch. Call it stubbornness, call it masochism, either way, I’m doing this from SCRATCH

Current status: the bootloader itself is functional. The handoff to the kernel is where things are still rough as sometimes it’s unstable.

No Screenshots This Time

It doesn’t boot to a usable state yet. The bootloader loads, but the kernel handoff is still being debugged. Once that’s solid, the next devlog will cover the M0.5 milestone I’ve been building toward.

More soon.

Devlog 3 - Multiplayer Actually Works???

Okay, absolute good news is that I got the game running multiplayer. Took a while but I got there.

I didn’t use Godot’s built-in multiplayer features, I’m running a custom Python UDP server instead. Reason is I want full control over the netcode and the freedom to host this however I want later. Right now I’m using NGrok to tunnel connections for testing, which works fine for dev, but I’ll need proper hosting infrastructure before shipping. NGrok isn’t meant for production game traffic and the extra hop adds latency I don’t want.

I implemented AES encryption on the packet layer. It keeps casual packet sniffing out and makes the connection feel more solid, but really, it does basically nothing against actual client cheating, and the encrypt/decrypt overhead on every UDP packet is probably costing me tick rate. Might rip it out later or swap for something lighter if things get sluggish.

Server authority is in for shooting, which is the critical part. Movement is still client-side for now, which yeah… I know that means speed hacks and teleporting are basically free right now. Getting the server to authoritatively handle movement in a game this chaotic is tough, but I’ll need to add at least basic validation or reconciliation soon. “Wildcard” gameplay shouldn’t mean “the client decides where it is.”

Next up: finish the lobby UI, build out a SQL backend for user accounts, and set up a gateway to route players across server instances. I’ve got two Chromebooks I’m testing on, and while they’re fine for small playtests, 500 concurrent players is almost definitely not happening on that hardware. The server process might only eat 50MB, but RAM isn’t the bottleneck: Python’s GIL, CPU load, and network I/O will tap out way before that. If this actually gets traction, I’ll need REAL infrastructure. The Chromebooks are great for prototyping, not production.

Still. The fact that multiple people can connect right now and actually play is pretty hype. This is gonna be chaos.

Devlog 2 - Core Systems Work (Sort Of)

I mean, it works. And tbf, That’s a win right now.

The foundation is in place, albeit held together with metaphorical duct tape. Godot decided to crash on me three times for absolutely no reason, so building this was more of an endurance test than a workflow. But we got there.

What’s Shippable:

Dynamic Inventory UI - Fully built out and functioning. It’s clean, it’s scalable, and it actually does what it’s supposed to do while looking like sh*t.

Overclock Meter - The core wildcard mechanic is alive. The meter builds when you chain movement, tricks, or high-intensity plays in a short window. Fill it up, and Overclock arms itself. Once armed, you can pop it at any moment during a match to slow everyone else down. It’s chaotic, it’s unfair in the best way.

What’s Next:

Overclock isn’t staying a one-trick pony. I’m planning a full suite of variants: time dilation, global weapon disable, and a few others that’ll really make matches unpredictable. The goal is to turn Overclock into a genuine match-altering decision, not just a “press button to win” scenario.

This game is going to be absolutely unhinged in the best way possible.

(P.S. - Yes, the gun thumbnails are placeholder. Yes, I could’ve done better. No, I will not be taking constructive criticism on them at this time.)

(I have yet to disable walking)

Devlog 1

Haven’t really done much but the player can walk (gonna remove that later) and the shooting mechanic works. I need to add walls and stuff along with fixing the gravity.

Ill cya in a bit.

Devlog 1

Kicked off a new tab page project today partly because it’s for a mission, partly because school is moving at a glacial pace and I needed something to actually engage my brain.

What shipped today

Nailed the base minimal look. Clean, no clutter, exactly what you’d want right out of the box. That’s the default skin locked in. Next up: backgrounds, glassmorphism blur effects, widgets, and whatever else feels right.

Catch you in the next one, or maybe not. Depends entirely on whether the bell decides to save me from this lecture.

Frost64 — Devlog 5

July 28, 2026

Paging is broken. :(

Yeah I kinda got too excited..

Four-level page tables PML4, PDPT, PD, PT. Higher half kernel at -2GB. Should work. Doesn’t work.

QEMU triple-faults immediately. Real hardware triple-faults immediately. Something in the table walk is wrong but I don’t know what yet. Probably a physical address somewhere that isn’t actually physical. Or a flag bit I set wrong. Or the TLB flush is in the wrong place. Or all of the above.

I’ve been staring at hex dumps for two hours. The tables look right. They are not right because I crossed referenced the OSDev wiki and my code.

Going to sleep on it. Tomorrow I’ll redo it so I can sleep tomorrow like a baby.

Heres a picture of a cat…

Frost64 — Devlog 4

July 27, 2026

(ACTUAL TIME: 2HRS, 12MINS)

PMM is in. Physical memory manager. I can hand out pages now. It feels weirdly powerful for something so boring and confusing.

Limine gives you a memory map. Usable, reserved, ACPI reclaim, whatever. I walk it, find the usable regions, shove them into a bitmap. One bit per page. 0 = free, 1 = used. 128KB of bitmap for 4GB of RAM. Not efficient but it works. pmm_alloc() finds a 0, flips it, returns the address. pmm_free() flips it back. Done.

Took longer than it should have. Off-by-one in the bitmap index, allocated the same page twice, page fault. Fixed it. Classic.

PIT and keyboard work. I can type while the timer ticks. Multitasking is still far but at least the pieces are there.

Next: paging. Four-level page tables. Higher half kernel. The thing I’ve been dreading since devlog 1.

On Using AI Here

Since AI is a tool now, I’m using it. But vibe coding is wrong and I’m keeping AI work under 30%. So far it’s only cleanup, file fixes, and commentary (because I forget what a certain part does). I check every change. I don’t let it break the rules.

The PMM was different. I wrote one first. Asked Kimi if it was good. It was pure garbage apparently. I’m not familiar with x64 dev, this is all new, and I’m learning while coding. So I let AI rebuild the PMM properly while I studied what it did. I understand it now. It is mine. But I needed the help.

Frost64 — Devlog 2

July 26, 2026

GDT and IDT are in. And it runs on real hardware. Not QEMU. My actual laptop. (so happy)

GDT was easy. 64-bit code segment, data segment, TSS later. IDT took longer. Assembly stubs for every vector, actually handling exceptions instead of triple-faulting into a black screen. The page fault handler just dumps registers and hangs but at least I can see where I died.

Real hardware was the test. QEMU lets you get away with everything. Real silicon doesn’t (flashback when I had a full OS ready but it didn’t work on silicon). Limine boots, framebuffer comes up, interrupts fire.

Next: PIT timer. Need a heartbeat before multitasking is even a thought. Then memory map parsing, frame allocator, and then paging. Four levels. Higher half. The thing that actually kills your will to live.

(Ignore broken bezel, I can’t afford a new laptop. This one is like 9 yrs old at this point.)

Frost64 — Devlog 1

July 26, 2026

OS dev again.

About a year of 32-bit experience. Paging was already the wall. Now it’s x86_64, four-level page tables, and the will to live is at zero. Time to revive an old project called Frost64. I’m using AI for debugging acceleration, keeping generated code under 30% so I can ship.

17 Minutes

I used the Limine barebones template from OSDev Wiki. I AM NOT writing a bootloader from scratch on day one. Framebuffer init, few lines printed. Looks like an OS. Is not an “OS”. But it boots.

What’s Next

GDT — proper 64-bit segments
IDT — so exceptions don’t triple-fault into a black screen (trust me, you don’t want this..)
PIT / APIC timer — timing before multitasking is even a thought
Physical memory map — Limine hands it over, now time to do something with it
Frame allocator — hand out pages somehow
Paging — four levels, higher half, the thing that kills your will to live, it’s not for the weak

First and Last Devlog

Whats good, I made myself a portfolio website. I really want to start making websites for people or apps as I cannot get a job at the ripe age of 14. I need college funds so I am hoping I can freelance.

How I made this really quick

There was some pre-planning to this as I made a base sketch of how i wanted the website to look. I had wayy bigger plans for it and I wanted to fill in the blank space but thats for another date. I got the site up and running really quick because most of the code was copy paste, for example, buttons, cards, badges, etc. Also because i partially used the tailwind framework to make it look better. I personally love their spacing and sizing options as they are flexible. I locked in and produced a quick static website. thanks to inline suggestions.

Why is the css and js in one file?

If I do host this on a real domain, I would use infinityfree for hosting and they have limited “hits” so I cant afford making the website bulky with files or I can run out of usage pretty quickly.

Devlog 1: Project PathSense

BEHOLD the second project I am bringing to OutPost!

PathSense is a lightweight wearable vest designed for the visually impaired. It packs four Time-of-Flight (ToF) distance sensors, a GPS module, three vibration motors, a camera, and a Raspberry Pi 5 acting as the main command center.

Here is how the system handles the heavy lifting:

• The Hardware: The ToF sensors map out the environment up to four meters away, tracking obstructions to your left, right, and center.

• The AI (vague ykyk) : The camera runs a custom Python program for real-time object detection. The software uses the video feed as its primary source of truth. For example, if you are eating, the sensors might get blocked by your arms. The AI intelligently identifies your hands and ignores the sensor data during that time to avoid false alarms.

• The Haptic Feedback: If an obstacle appears on your left, the corresponding motor vibrates. The intensity changes depending on how close you are to the object.

• Audio Input: You can pair the vest with headphones for voice alerts. It will read out what is ahead, like letting you know a person is walking by or screaming “STOP!” if you approach a flight of stairs.Between the computer vision navigation and the GPS tracking, a person can confidently navigate both indoor spaces and busy city streets.

• Smart Navigation: As a massive upgrade, the Raspberry Pi 5 will run a custom navigation engine that combines active GPS coordinates with real-time computer vision pathfinding. Instead of just giving basic turn-by-turn directions, the system uses the camera feed to analyze the ground layout. It will actively look out for obstacles, steer the user away from rough or rocky terrain, and track the edges of sidewalks to ensure they never accidentally drift off the path.

The entire experience is designed to be fully voice-activated through a pair of headphones. The ultimate goal is to build it out like an interactive assistant (with possibility of combining it with the new and improved SIRI for fetching messages) , allowing the user to simply speak their destination and receive continuous, real-time auditory guidance as they walk.

As for today’s progress, there was only one main objective on my radar. I spent the hour designing a custom hardware HAT for the Raspberry Pi 5. This lets me drop standard JST connectors onto the board so all the sensors and motors can plug in cleanly without messy loose wires.

That is all for now. I will update everyone as soon as the grant clears and the manufacturing parts arrive!

Devlog 1

Well the time logged states what happened in this devlog and it’s not much. Mainly because my project is more or less towards the software side, building it will be a whole nother story though.

My project is a Schlieren Imaging Device. It can visualize airflow, heat and soundwaves by sending a pinpoint intensity light through a Plano-Convex lens and a NPBS (Non-Polar Beam Splitter) and out the device. That same light beam will reflect off a First Surface mirror then proceed to bounce back the same path it came from. Pretty confusing right?? I will still need to get this all alligned 😭 That light beam then will get sent through ANOTHER lens and a knife edge to make sure the contrast is good. THEN that light beam will finally HIT the camera!!

Here’s how my project works from the inside:

The ESP32 P4 handles all the important stuff and driving the LED through that AML driver. The pin sockets let me swap things in and out without desoldering, which is critical when you are still figuring out what works.
The USB C port is for charging ONLY, the TPS charging IC manages the battery so we do not overcharge or drain too low. The 5V boost bumps the single cell lithium up to a stable 5V for the ESP32 and the LED, which can pull some real current when cranked up.
The four 1x2 sockets break down simple: one for the battery, one for the LED, one for the power switch, and 1 for the fan, although I am planning on adding some more sockets for the LED fan. Those can get prettyyyy hot.
The rest of the day was spreadsheets and stuff. BOM, part numbers, stock checks, the usual.

Well that’s it for my project. Ill seee y’all when this is funded!

Devlog 2, 3, 4, 5, 6, 7, 8

Pretty long header, huh? Let me catch you up. I am running a dual boot with Arch basically, and my Windows 11 partition gets mad sometimes. A few days back it snapped. Yep, it snapped. It destroyed itself and I don’t have enough time to debug the issue and fix it, so I decided… how hard can setting everything up on Linux be? (Big understatement.) Turns out I recorded from the browser for like 4 hours and then the recording completely crashed on me. Thankful for the Stardance staff though, as they said I can just directly add entries to my journal, so here I am!

I got a limit on how much I can type so I’ll be quick.

Devlog 2

I added a boost converter, fuel gauge IC, and an SD card slot. That’s literally it. The reason? I went through 90 different Reddit forums and a few datasheets later just to find out that my schematic is COMPLETELY unusable. Reason? Because the values I inputted were completely wrong and I forgot to account for the actual traces and distance. Yeah… big mistake.
(I’m just exposing myself at this point)
~5 hours

Devlog 3

Things picked up from here. I proceeded to wire up the Neo M9N and also proceeded to wire up the audio and microphone chips. The GPS module took me the most time. I needed to calculate the actual performance in real-world testing because if I didn’t, I would be fried indefinitely. RF signals are too picky.

~3 hours

Devlog 4

Wired up most of the things I got to the CM4 connectors. Not much I can say here. I spent most of the time trying different layouts on where to put it. I was basically shuffling in between the schematic editor and PCB editor (big mistake later, traces got jumbled).

~1 hour

Devlog 5

I realized I AM COOKED if I don’t finish this ASAP, so I started grinding. I rushed through everything and you’ll see why this was a bad idea in a bit.

Devlog 6

I am done with the whole PCB. Time to run the DRC checker. What can go wrong? (Foreshadowing: everything went wrong.) I got like 500 errors and 300 warnings (actual count). The whole problem? I crammed everything TOO TIGHT. So I spent devlog 6 and 7 cleaning everything up.

~9 hours

Devlog 8

FINALLY, MY PCB IS DONE! For my first PCB, this isn’t too bad, considering I did a more ambitious project. I have no DRC errors anymore, so I ran the project inside a simulation. I checked every signal output and power planes/ground planes. Everything was expected except I ran into problems with the SD card trace. I knew this was coming either way. The traces spanned everywhere and weakened the signal. I fixed it right up though, so in theory this thing will boot and run without issues.

What Did I Learn?

Absolutely nothing. (Jk.) I learned to not RUSH. In this case I absolutely had to because if I didn’t, I wouldn’t make the project deadline. Maybe I should have rushed more gracefully, but now I am 3 textbooks down. I wrote like 90% of my schematics on my textbooks and datasheet references until I screwed that part up by not doing math. I thought it’d give me actual good info, not mathematical nonsense. Oh well. It’s finished and I’m proud that I got a device like this done.

Now the hard part: CHEAP SOURCING. Apparently this won’t be covered if it’s too expensive and the PCB isn’t polished, which I can’t say much about because the PCB looks like sh!t. I was not making a Mona Lisa, bro. Now I can make a total calculation. I’ll use AliExpress because those are the CHEAPEST and fastest part suppliers. JLCPCB gets the rest, and once I get the correct amount I’m sending this in. Meanwhile, tonight I’ll work on the GitHub and demo… which I don’t have, so I guess I’ll make a website for the GPS.

Devlog 1: The 43-Minute Charging Core

Project Context & Architecture

I’m designing a custom handheld navigation device from scratch. The goal is a custom carrier board in KiCad that ties together high-performance computing, location tracking, and power management. Here’s the hardware stack:

• The Brain: Raspberry Pi Compute Module 4 (CM4) — Runs the core OS, custom parsing utilities, and handles all the high-level computing.
• Location Tracking: u-blox NEO-M9N GNSS/GPS Module — Connected to an active external antenna for live coordinates literally anywhere.
• Power Management: BQ25895RTWR (QFN-24) — A highly efficient switch-mode 3A buck charger handling autonomous LiPo charging, direct power-path management, and a deep-sleep “Ship Mode” hibernation circuit to prevent battery drain.
• Power Input & Battery: USB-C Interface & 1S LiPo (via JST-PH) — Hardwired strictly as a one-way power sink (charging input only because I have zero motives to actually use the port for anything else).

The Update

PS: My incompetent brain used plain text boxes for my schematic labels instead of just pressing the L key to make actual net flags.

So, here’s what I got done in exactly 43 minutes: a charging circuit. That’s it. That’s literally all I did. Right now, there is absolutely nothing connecting over to the CM4 compute engine yet. I’m an absolute beginner at physical PCB layout, but I am a certified pro at reading datasheets. If you think about it, it’s the biggest engineering bottleneck of the century. Either way, I need to get this entire hardware project finished by tomorrow to actually get this PCB sent over to JLCPCB, get leads on parts, get it shipped ASAP, and take measurements for the enclosure. (That is if I get actual funding..) I’m currently sitting at a solid 5% completion. This is going to be an absolute sprint. (Not like my teachers once asked me to write a drama script last minute that was like 50% of my grade and I managed to pull off a 30-page script in one night… but yeah.) I’ll see you in a bit when I’ve actually got a few more sheets knocked out.