# Project export: AetherNode
This document was generated by HackStack to give an AI agent context about a hackathon project. Sections are labeled with their provenance; content marked as truncated was cut to keep this document small.
## Project metadata
- Hackathon: TreeHacks 2026
- Tagline: AetherNode powers the next generation of space data centers by intelligently scheduling compute around orbital physics.
- Devpost: https://devpost.com/software/aethernode
- GitHub: https://github.com/jeylinnn/treehacks2026
- Demo: https://drive.google.com/file/d/1ddfFnk-yus3qbqjamSpyFm2AWho2X8El/view?usp=sharing
- Video: https://www.youtube.com/embed/bo2t0RF9yMw?enablejsapi=1&hl=en_US&rel=0&start=&version=3&wmode=transparent
- Team: 2 GitHub contributor(s) — AnonymousTerminator (2 commits), sidhantsinghvi (2 commits)
## Devpost submission (written by the team)
### Inspiration
Artificial intelligence is scaling rapidly, and the infrastructure that powers it is approaching real physical limits. Data centers already consume roughly four percent of total electricity in the United States, and by 2030 demand from AI and cloud workloads is expected to at least double. Many facilities also rely on water intensive cooling systems in regions facing water stress. Space offers a fundamentally different energy environment. In low Earth orbit, systems receive approximately 1,361 watts per square meter of direct solar radiation outside Earth’s atmosphere. However, orbital platforms operate under strict constraints, including eclipse periods roughly every ninety minutes, limited battery storage, extreme thermal swings, and intermittent ground communication windows. We were inspired by a simple question: what if compute in space were scheduled around physics instead of assuming unlimited power and cooling? Instead of treating sunlight, temperature, and connectivity as side conditions, we wanted to make them the core of decision making. That vision became AetherNode.
### What it does
AetherNode is a physics aware orchestration system for orbital edge computing. Rather than assuming compute can run continuously, it treats sunlight availability, thermal headroom, battery state, and communication windows as hard operational constraints. Our system simulates an orbital data center and continuously generates telemetry such as temperature, power levels, eclipse versus sunlight phase, and ground station connectivity. The orchestration engine evaluates these constraints in real time and determines whether high intensity AI workloads can safely execute. If temperature approaches critical limits or simulated battery levels drop during eclipse, workloads are paused or deferred. When conditions improve, compute resumes automatically. The system behaves like a mission control layer that dynamically adapts to environmental constraints. A live dashboard streams telemetry and scheduling decisions over WebSockets, allowing users to observe mission control logic operating in real time.
### How we built it
We built AetherNode using a Python backend powered by FastAPI. The system leverages asynchronous execution through asyncio to continuously evaluate system constraints and update scheduling decisions without blocking other processes. Telemetry values are generated and processed by the backend, then passed through scheduling logic that determines whether workloads should run, pause, or resume based on defined thresholds and state transitions. The frontend dashboard was built using HTML, CSS, and JavaScript. It connects to the backend via WebSockets to visualize system state, including thermal conditions, orbital phase, power status, and job execution decisions.
### Challenges we ran into
One of the biggest challenges we faced is simply how new this field is. Orbital data centers are still largely theoretical, and only in the past few years have major players like Google, Starlink, and Blue Origin begun seriously exploring large-scale space infrastructure. There is no established playbook for how compute should actually be orchestrated in orbit, no mature frameworks to study, and no production systems to benchmark against. That meant we could not rely on existing case studies or best practices. We had to dig through research papers, mission reports, and technical documentation to piece together realistic constraints around orbital mechanics, eclipse cycles, solar radiation, thermal dissipation, and ground station visibility. Because this ecosystem is still emerging, we were building from first principles rather than adapting an existing cloud architecture. Another challenge was thinking carefully about differentiation. Large aerospace and technology companies are exploring space infrastructure, satellite networks, and launch systems. However, most focus on hardware, connectivity, or transportation. We had to clearly define how AetherNode is different. Instead of competing on hardware or launch capability, we focused on the orchestration layer, the software intelligence that schedules compute around physics itself. That required us to think deeply about what layer of the stack remains unsolved and where software innovation can create meaningful leverage. Balancing ambition with practicality was also difficult. We wanted the concept to feel technically grounded and differentiated from massive aerospace players, while still building something achievable within a hackathon timeframe. This forced us to make disciplined design decisions and focus on demonstrating the core insight clearly.
### Accomplishments we're proud of
We are proud that we transformed a highly theoretical concept into a working, interactive prototype. Instead of simply discussing orbital compute at a high level, we built a functioning orchestration layer that dynamically responds to simulated sunlight cycles, thermal limits, and connectivity windows in real time. We successfully created a live mission control system that streams telemetry and scheduling decisions through an asynchronous backend. The system continuously evaluates environmental constraints and adapts compute behavior automatically, demonstrating that physics driven scheduling can be implemented in software today. Most importantly, we approached space-based computing as a systems orchestration problem rather than purely a hardware challenge. That conceptual clarity is something we are especially proud of.
### What we learned
We learned that constraint driven design is fundamentally different from traditional cloud architecture. Most modern infrastructure assumes stable power, cooling, and connectivity. Designing for orbital environments forced us to treat variability as the default state rather than the exception. We also learned how to architect asynchronous backend systems that evaluate state continuously while maintaining real time user interface updates. Coordinating telemetry generation, scheduling logic, and live dashboard streaming deepened our understanding of distributed systems thinking. Beyond technical skills, we learned how to scope an ambitious systems level idea into a focused, demonstrable prototype while maintaining conceptual depth.
### What's next
The next step is integrating real orbital data so scheduling decisions align with actual satellite trajectories and eclipse predictions. This would ground the system in real world orbital dynamics rather than purely simulated cycles. We also plan to move from threshold based logic to predictive optimization models that forecast thermal and power trends, allowing compute to be scheduled proactively instead of reactively. In the longer term, we envision expanding AetherNode to coordinate multiple orbital nodes, enabling distributed, energy aware constellations that intelligently balance workloads across satellites.
## README (from the GitHub repository)
# AetherNode
A Vite + React + TypeScript web app that renders a Cesium 3D Earth with a continuously orbiting satellite and a deterministic mission control simulation panel. All telemetry is derived from formulas and toggles (no randomness).
## Run Locally
```
npm install
npm run dev
```
Open the URL printed by Vite (usually http://localhost:5173).
## Simulation Model
The sim runs at 10 Hz. Orbit time is accelerated to a 120-second loop for visibility.
### Inputs
- `orbitPhase` advances from 0..1 based on sim time.
- `sunlight` is derived from orbit phase unless forced by toggles.
- `contactWindow` is derived from proximity to the Ground Station unless forced by toggles.
- Toggles: Sunrise, Eclipse, Thermal Warn, Thermal Halt, Cool Down, Blackout, Link Up, Solar Flare.
### Output Signals
- **Sunlight status**: `SUNLIGHT` or `ECLIPSE`.
- **Lux (0..1000)**: based on sunlight and Solar Flare; forced to 0 by Eclipse or Blackout.
- **Thermal status**: `OK`, `WARN`, or `HALT` from CPU temp and thermal toggles.
- **CPU Temp (°C)**: evolves each tick by a thermal equation.
- **Network**: `UP` when in contact window (unless Blackout), `DOWN` otherwise.
- **Contact Window**: `CONTACT` or `NO CONTACT` based on proximity.
- **Job**: `OK` or `FAILED` based on thermal limits.
- **Outbox**: pending data count that increases with compute and drains when network is `UP`.
- **Last Action**: rule-based agent action for the current tick.
### Thermal Equation
Each tick:
```
cpuTemp += (heat_in - cooling_out) * deltaSeconds
```
Where:
- `heat_in = baseHeat + workloadHeat (+ solarFlareHeat)`
- `workloadHeat` increases when jobs run (higher in sunlight).
- `cooling_out` increases when Cool Down is toggled or the agent chooses a cooldown action.
- CPU temp is clamped to 20..95°C.
### Agent Policy
Every tick, the agent decides:
1. If `cpuTemp > 88` or Thermal Halt is toggled: `thermal halt`
2. Else if `cpuTemp > 80` or Thermal Warn is toggled: `cooldown`
3. Else if `contactWindow` and outbox > 0 and network `UP`: `downlink`
4. Else if `sunlight` and thermal `OK` and network `UP`: `run job`
5. Else: `noop`
Each action writes an event log entry with a timestamp.
## Toggle Effects
- **Sunrise**: Forces sunlight `true` (overrides orbit-derived darkness unless Eclipse is also on).
- **Eclipse**: Forces sunlight `false` and Lux to 0.
- **Thermal Warn**: Forces thermal status `WARN` and biases the agent to choose `cooldown`.
- **Thermal Halt**: Forces thermal status `HALT` and immediately fails any running job.
- **Cool Down**: Increases cooling output, helping CPU temperature recover.
- **Blackout**: Forces contact window `false`, network `DOWN`, and Lux to 0.
- **Link Up**: Forces contact window `true`, network `UP`.
- **Solar Flare**: Increases heat input and Lux.
Precedence rules:
- `Eclipse` overrides `Sunrise` for sunlight and Lux.
- `Blackout` overrides `Link Up` for contact window and network.
## Cesium Scene Notes
- Earth imagery is provided by OpenStreetMap tiles (no Cesium Ion token required).
- The Sun lighting model is enabled to create day/night shading.
- The satellite follows a circular LEO path (inclination 55°) with a visible orbit track.
- A Ground Station marker is placed near 34.7°N, 120.6°W.
## Detected evidence (automated analysis)
Indexed codebase: 19 recognized source files, 49 KB.
- CSS (language) — detected in the code
- HTML (language) — detected in the code
- React (technology) — detected in the code
- TypeScript (language) — detected in the code
- Docker (technology) — claimed on Devpost, not found in the code
- Google Gemini (technology) — claimed on Devpost, not found in the code
- JavaScript (language) — claimed on Devpost, not found in the code
- OpenAI (technology) — claimed on Devpost, not found in the code
- Python (language) — claimed on Devpost, not found in the code
## Codebase structure (from repository index)
### Files (22 of 22)
```
index.html
package.json
README.md
src/App.tsx
src/cesium/cesium.css
src/cesium/CesiumView.tsx
src/index.css
src/main.tsx
src/sim/history.ts
src/sim/model.ts
src/sim/store.tsx
src/sim/types.ts
src/sim/whatif.ts
src/ui/GlassSelect.tsx
src/ui/MissionControl.tsx
src/ui/Pills.tsx
src/ui/TelemetryPanel.tsx
src/ui/ToggleButton.tsx
src/vite-env.d.ts
tsconfig.json
tsconfig.node.json
vite.config.ts
```
### Dependencies
- package.json: @types/react@^18.3.12, @types/react-dom@^18.3.1, @vitejs/plugin-react@^4.3.4, cesium@^1.123.1, react@^18.3.1, react-dom@^18.3.1, recharts@^2.12.7, typescript@^5.6.3, vite@^7.3.1, vite-plugin-cesium@^1.2.2
### Recent commits (newest first)
- Change project name in README
- Delete v1 directory
- Create .gitkeep
- 3d version working
## Key source files (fetched from GitHub, selected and truncated for size)
### package.json
```
{
"name": "sun-sync-sim",
"private": true,
"version": "0.1.0",
"type": "module",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"dependencies": {
"cesium": "^1.123.1",
"recharts": "^2.12.7",
"react": "^18.3.1",
"react-dom": "^18.3.1"
},
"devDependencies": {
"@types/react": "^18.3.12",
"@types/react-dom": "^18.3.1",
"@vitejs/plugin-react": "^4.3.4",
"typescript": "^5.6.3",
"vite": "^7.3.1",
"vite-plugin-cesium": "^1.2.2"
}
}
```
### src/main.tsx
```typescript
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import './index.css';
import './cesium/cesium.css';
// Cesium asset base path for Vite
(window as unknown as { CESIUM_BASE_URL?: string }).CESIUM_BASE_URL = '/cesium';
ReactDOM.createRoot(document.getElementById('root')!).render(
);
```
### src/App.tsx
```typescript
import CesiumView from './cesium/CesiumView';
import MissionControl from './ui/MissionControl';
import TelemetryPanel from './ui/TelemetryPanel';
import { SimProvider } from './sim/store';
export default function App() {
return (
Orbit is simulated. Contact window toggles automatically when the satellite is near the ground station.