You are browsing as a guest. Sign up (or log in) to start making projects!

yaasshh

@yaasshh

Joined June 1st, 2026

  • 6Devlogs
  • 5Projects
  • 0Ships
  • 0Votes
Open comments for this post

11h 40m 11s logged

Dev log: Phase 18 to now

Phase 18, line shapes. Real spectral lines are not infinitely thin spikes. Atoms move around (Doppler) and get jostled by neighbours (pressure), so each line spreads into a bell shape called a Voigt profile. We added that, plus a zoom so you can actually look at one line up close. The useful trick here was a flux-closure check: whatever area the line has before broadening, it must still have after. That check caught two grid bugs that were completely invisible on screen.

Phase 19, optical depth. Up to here, every line was treated as if the light escaped freely. In a thick gas the strong lines saturate, so doubling the number of atoms stops doubling the brightness. That relationship is the curve of growth. Big lesson: classify which regime a line sits in by the physics, not by eyeballing the slope of the curve. Also, the wavelength window has to widen as the column gets thicker, otherwise you clip the wings you are trying to measure.

Phase 20, absorption. The mirror image of emission: shine a continuum through the gas and look at what is missing. The trap here was that 14 hydrogen lines land on only 6 distinct wavelengths, so matching a computed profile to its source line by wavelength alone silently pairs up the wrong ones. We key on the transition instead.

Phase 21, Hartree-Fock. The biggest chunk. Instead of a fitted screening formula, each electron now feels a potential built from all the others, solved over and over until it stops changing. This gets us sulfur and chlorine, which the old fitted model could not touch at all, and ions with no preset. Two things worth remembering: the solver’s own error bar was lying to us and needed re-deriving, and the thing that finally made convergence fast was not a clever algorithm but the right mixing constant.

Phase 22 and cleanup. Made features honest about what they apply to. The classical ghost and the force-law lab only make sense for one-electron atoms, so they now explain themselves instead of erroring on a screened atom. Fixed He+ breaking every API call, because the “+” was never URL-encoded. Unknown systems say so instead of spinning. Currently fixing hint text that escaped its panel on narrow screens.

0
0
3
Open comments for this post
Reposted by @yaasshh

20h 57m 4s logged

Atom_Sim: Physics Simulator Dev Log

An atom simulator built on one rule: Every number has a label (exact, numerical, approximation, counterfactual, or visual_liberty). Unlabeled numbers are treated as bugs.

Stack: Python physics engine -> React + Three.js frontend.

Phase Logs

Phases 1–3: The Hydrogen Foundation

  • Hydrogen Core: Uses exact math for energies and wavefunctions. Validates its electron clouds using statistical KS tests.
  • Numerical Solver: Solves the Schrödinger equation for custom shapes. It calculates its own accuracy by halving the grid spacing.
  • Constants Lab: Allows changing fundamental constants (hbar, e, c). It proves that changing individual units changes nothing if the ratio between them stays the same.
  • Classical Ghost: Shows old Bohr orbits collapsing, proving why classical physics cannot explain atoms.

Phases 4–6: Altered Potential & Real Atoms

  • Fake Physics: Simulates universes with non-standard forces (like Yukawa or power laws) under a clear warning banner.
  • Screened Atoms: Models elements from Helium to Argon using historic 1974 data. If an element (like Sulfur or Chlorine) lacks clean data, it is left out entirely rather than guessed.

Phases 7–12: Fields, Relativity & Nuance

  • Dirac Math: Tracks exact relativistic shifts and highlights what the math misses (the Lamb shift).
  • External Fields: Simulates atoms splitting under magnetic fields (Zeeman effect) and electric fields (Stark effect).
  • Hyperfine: Models the 21 cm hydrogen line using the precise electron-to-proton mass ratio.

Phases 13–17: Light, Speed & Thermodynamics

  • Fast Math: Uses a custom integration trick to calculate atomic lifetimes exactly and 13x faster.
  • Doublet Ratios: Proves via quantum math (Wigner 6j) why certain spectral lines are twice as bright as others.
  • Heat Sliders: Combines Saha and Boltzmann equations to turn raw rates into actual visible light. Dragging the temperature slider smoothly hands Lyman lines over to Balmer lines.

Phase 18: Line Profiles (Current Work)

Replaces infinitely sharp lines with realistic Voigt profiles using three combined factors:

  1. Natural Width: A Lorentzian shape caused by how fast an excited state decays.
  2. Doppler Width: A Gaussian shape caused by thermal motion. Works perfectly for normal hydrogen, positronium, and muonic hydrogen.
  3. Instrumental Width: A Gaussian blur based on the user’s chosen telescope or sensor resolution.

Note on Missing Physics: Collision/pressure broadening is not simulated. Instead of a text disclaimer, the app calculates how large that missing effect would be and prints the raw margin of error right next to the chart.

Core Development Rules

  • No Smoke Tests: Every physics feature must pass an automated math test.
  • No Live Fetches: All reference data is saved locally with a hard citation.
  • No Silent Approximations: If the code cannot calculate something honestly, it stops and prints exactly what data is missing.
0
1
76
Open comments for this post

20h 57m 4s logged

Atom_Sim: Physics Simulator Dev Log

An atom simulator built on one rule: Every number has a label (exact, numerical, approximation, counterfactual, or visual_liberty). Unlabeled numbers are treated as bugs.

Stack: Python physics engine -> React + Three.js frontend.

Phase Logs

Phases 1–3: The Hydrogen Foundation

  • Hydrogen Core: Uses exact math for energies and wavefunctions. Validates its electron clouds using statistical KS tests.
  • Numerical Solver: Solves the Schrödinger equation for custom shapes. It calculates its own accuracy by halving the grid spacing.
  • Constants Lab: Allows changing fundamental constants (hbar, e, c). It proves that changing individual units changes nothing if the ratio between them stays the same.
  • Classical Ghost: Shows old Bohr orbits collapsing, proving why classical physics cannot explain atoms.

Phases 4–6: Altered Potential & Real Atoms

  • Fake Physics: Simulates universes with non-standard forces (like Yukawa or power laws) under a clear warning banner.
  • Screened Atoms: Models elements from Helium to Argon using historic 1974 data. If an element (like Sulfur or Chlorine) lacks clean data, it is left out entirely rather than guessed.

Phases 7–12: Fields, Relativity & Nuance

  • Dirac Math: Tracks exact relativistic shifts and highlights what the math misses (the Lamb shift).
  • External Fields: Simulates atoms splitting under magnetic fields (Zeeman effect) and electric fields (Stark effect).
  • Hyperfine: Models the 21 cm hydrogen line using the precise electron-to-proton mass ratio.

Phases 13–17: Light, Speed & Thermodynamics

  • Fast Math: Uses a custom integration trick to calculate atomic lifetimes exactly and 13x faster.
  • Doublet Ratios: Proves via quantum math (Wigner 6j) why certain spectral lines are twice as bright as others.
  • Heat Sliders: Combines Saha and Boltzmann equations to turn raw rates into actual visible light. Dragging the temperature slider smoothly hands Lyman lines over to Balmer lines.

Phase 18: Line Profiles (Current Work)

Replaces infinitely sharp lines with realistic Voigt profiles using three combined factors:

  1. Natural Width: A Lorentzian shape caused by how fast an excited state decays.
  2. Doppler Width: A Gaussian shape caused by thermal motion. Works perfectly for normal hydrogen, positronium, and muonic hydrogen.
  3. Instrumental Width: A Gaussian blur based on the user’s chosen telescope or sensor resolution.

Note on Missing Physics: Collision/pressure broadening is not simulated. Instead of a text disclaimer, the app calculates how large that missing effect would be and prints the raw margin of error right next to the chart.

Core Development Rules

  • No Smoke Tests: Every physics feature must pass an automated math test.
  • No Live Fetches: All reference data is saved locally with a hard citation.
  • No Silent Approximations: If the code cannot calculate something honestly, it stops and prints exactly what data is missing.
0
1
76
Open comments for this post

9h 12m 30s logged

I’ve been working on a personal project called PartSourcer. Essentially, it’s a database, a bit beautified, but a database nevertheless, that scours the internet for major electronic component distributors in bulk, such as Mouser, DigiKey, JLCPCB, and LCSC. It goes through all of these major component databases, fetching real-time data from API keys I generated myself, and outputs the components and their prices.

So far, I have the frontend and most of the backend done. The next step is to actually implement the Mouser and DigiKey API keys. I have the Mouser one ready; DigiKey is a bit more confusing to get, but I will get it. I already have the LCSC and JLCPCB integration working for each component, showing real-time stock and unit prices per item.

I’m going to keep a very early version of the project open source under the MIT license. Later on, I plan to remove the MIT license and host it on the internet for free, but it won’t remain open source. Only that very early version will stay under the MIT license.

Moving forward, my roadmap for the project includes:

  1. Completing the actual API implementations.
  2. Implementing a side-by-side comparison tool.
  3. Adding a large-scale, bulk BOM (bill of materials) upload feature.
  4. Creating a price history chart.
  5. Implementing a “browse by category” feature.
  6. Adding a “biggest savings this week” section to show people where the best deals are and what they can save money on.
0
0
3
Open comments for this post
Reposted by @yaasshh

3h 46m logged

It’s a wonderful day. I feel like I am completely finished with this project—or at least finished to some extent—because I still need to get the PCB, solder everything, and test it properly. However, I’ve done as much as I can to the best of my abilities for now.

I am definitely proud of the work that led me here. It has been close to 50 hours of work over a month. It was a long month with a lot of school and personal things going on, but I powered through it. I made a lot of mistakes and had to redo the entire thing twice, which led me to a breaking point at one stage, but I pushed through and I’m proud of that.

I have checked everything and gone through all the materials. Regarding the next steps:

  1. PCB Manufacturing
    After the discount, this will be around $20–$30. I am hoping to get funding for that.

  2. Individual Parts
    The rest of the money will be for the components. I’ll get those from AliExpress or somewhere similar where I can buy in bulk for very cheap. I’m not opting for Digi-Key because I was having a lot of trouble going through their system. On AliExpress, I can get most of what I need for around 60–80 AED (approximately $25). Buying in bulk means I can keep extra parts for other projects, which will reduce the funding I need later on.

All the PCB files, schematics, and Gerber files have been pushed to GitHub. I’m hoping to get the funding as soon as possible so I can start working on this ASAP.

I am really looking forward to the next project, which should include the sensor itself. The faster this gets done, the sooner I can start working on that next project much more efficiently.

P.S. Basically, I have put close to or above 50 hours of work into this project over a month of work, averaging almost two hours every day.
I’m proud of this, and for those who don’t believe me, everything is documented on Macondo (the Hack Club challenge). You are free to view the journals over there. However, I will also be adding a journal.md to my GitHub in a bit.
Not right now, though, as I am severely burned out from this project. I need to start a new project and put my mind to something else for a while. I hope I get the funding for this because I really want to move on to the actual hardware aspect, start soldering, and actually test it out. I will be using this in multiple other projects as well.

So yeah, thank you for reading.

0
1
21
Open comments for this post

3h 46m logged

It’s a wonderful day. I feel like I am completely finished with this project—or at least finished to some extent—because I still need to get the PCB, solder everything, and test it properly. However, I’ve done as much as I can to the best of my abilities for now.

I am definitely proud of the work that led me here. It has been close to 50 hours of work over a month. It was a long month with a lot of school and personal things going on, but I powered through it. I made a lot of mistakes and had to redo the entire thing twice, which led me to a breaking point at one stage, but I pushed through and I’m proud of that.

I have checked everything and gone through all the materials. Regarding the next steps:

  1. PCB Manufacturing
    After the discount, this will be around $20–$30. I am hoping to get funding for that.

  2. Individual Parts
    The rest of the money will be for the components. I’ll get those from AliExpress or somewhere similar where I can buy in bulk for very cheap. I’m not opting for Digi-Key because I was having a lot of trouble going through their system. On AliExpress, I can get most of what I need for around 60–80 AED (approximately $25). Buying in bulk means I can keep extra parts for other projects, which will reduce the funding I need later on.

All the PCB files, schematics, and Gerber files have been pushed to GitHub. I’m hoping to get the funding as soon as possible so I can start working on this ASAP.

I am really looking forward to the next project, which should include the sensor itself. The faster this gets done, the sooner I can start working on that next project much more efficiently.

P.S. Basically, I have put close to or above 50 hours of work into this project over a month of work, averaging almost two hours every day.
I’m proud of this, and for those who don’t believe me, everything is documented on Macondo (the Hack Club challenge). You are free to view the journals over there. However, I will also be adding a journal.md to my GitHub in a bit.
Not right now, though, as I am severely burned out from this project. I need to start a new project and put my mind to something else for a while. I hope I get the funding for this because I really want to move on to the actual hardware aspect, start soldering, and actually test it out. I will be using this in multiple other projects as well.

So yeah, thank you for reading.

0
1
21
Open comments for this post
Reposted by @yaasshh

9h 58m 56s logged

I have been working on a custom macro pad, which is based on the HackPad. I had an idea of making it usable with external apps through APIs and other integrations.

I completed the PCB quite a while ago. I have put about 14 hours of total work into this, although I have only logged close to 10 hours. The other four hours were unlogged because I was working on a different laptop, but that is fine since it is only a few hours.

The device itself is a macro pad with:

  1. Six MK-style switches
  2. One rotary encoder
  3. An OLED screen

The PCB is quite impressive; I added some silkscreens to make it look aesthetically pleasing, which I hope will come across well in the finalized product. I designed the case in three parts:
(a) The base
(b) The plate
(c) The top part that encloses everything

The top part leaves space so that the screen can be viewed, making for a really nice, aesthetic-looking piece of hardware.

I have decided to call it Maestro because it fits the theme I have going for it. It is going to be something I use in my daily life to shorten my work time and streamline my workflows. I am pretty excited for the funding to go out so I can start working on this.

0
1
15
Open comments for this post

9h 58m 56s logged

I have been working on a custom macro pad, which is based on the HackPad. I had an idea of making it usable with external apps through APIs and other integrations.

I completed the PCB quite a while ago. I have put about 14 hours of total work into this, although I have only logged close to 10 hours. The other four hours were unlogged because I was working on a different laptop, but that is fine since it is only a few hours.

The device itself is a macro pad with:

  1. Six MK-style switches
  2. One rotary encoder
  3. An OLED screen

The PCB is quite impressive; I added some silkscreens to make it look aesthetically pleasing, which I hope will come across well in the finalized product. I designed the case in three parts:
(a) The base
(b) The plate
(c) The top part that encloses everything

The top part leaves space so that the screen can be viewed, making for a really nice, aesthetic-looking piece of hardware.

I have decided to call it Maestro because it fits the theme I have going for it. It is going to be something I use in my daily life to shorten my work time and streamline my workflows. I am pretty excited for the funding to go out so I can start working on this.

0
1
15
Open comments for this post

1h 4m 46s logged

So first Dev-Post,

I am building a signal recorder for electromyography (EMG) signals, which are essentially the electrical impulses that muscles produce when you contract or relax. I am recording those signals through electrodes on an arm that will be connected to a circuit I am currently working on.

My plan is to:

  1. Create and test the circuit
  2. Convert it into a PCB that I can manufacture to be quite small
  3. Integrate it into a bunch of my own projects
  4. Make it open source so other people can use it in the future

So far, two stages have been completed:

  1. Stage Zero: 2.5V bias circuit
  2. Stage 1: INA (instrumentation amplifier) circuit and setup
  3. Stage 2: 20Hz notch filter
0
0
4

Followers

Loading…