Hacker News

https://rootkid.me/works/spectrum-slit

https://archive.md/vk8ov

Capitol One statement: https://investor.capitalone.com/news-releases/news-release-d...

Brex statement: https://www.brex.com/journal/brex-and-capital-one-join-force...

https://constellation-io.com/). We built an AI system that predicts satellite link failures before they happen. Here's a video walkthrough: https://www.youtube.com/watch?v=069V9fADAtM.

Between us, we've spent years working on satellite operations at SpaceX, Blue Origin, and NASA. At SpaceX, we managed constellation health for Starlink. At Blue, we worked on next-gen test infra for New Glenn. At NASA, we dealt with deep space communications. The same problem kept coming up: by the time you notice a link is degrading, you've often already lost data.

The core issue is that satellite RF links are affected by dozens of interacting variables. A satellite passes overhead, and you need to predict whether the link will hold for the next few minutes. That depends on: the orbital geometry (elevation angle changes constantly), tropospheric attenuation (humidity affects signal loss via ITU-R P.676), rain fade (calculated via ITU-R P.618 - rain rates in mm/hr translate directly to dB of loss at Ka-band and above), ionospheric scintillation (we track the KP index from magnetometer networks), and network congestion on top of all that.

The traditional approach is reactive. Operators watch dashboards, and when SNR drops below a threshold, they manually reroute traffic or switch to a backup link. With 10,000 satellites in orbit today and 70,000+ projected by 2030, this doesn't scale. Our system ingests telemetry at around 100,000 messages per second from satellites, ground stations, weather radar, IoT humidity sensors, and space weather monitors. We run physics-based models in real-time - the full link budget equations, ITU atmospheric standards, orbital propagation - to compute what should be happening. Then we layer ML models on top, trained on billions of data points from actual multi-orbit operations.

The ML piece is where it gets interesting. We use federated learning because constellation operators (understandably) don't want to share raw telemetry. Each constellation trains local models on their own data, and we aggregate only the high-level patterns. This gives us transfer learning across different orbit types and frequency bands - learnings from LEO Ka-band links help optimize MEO or GEO operations. We can predict most link failures 3-5 minutes out with >90% accuracy, which gives enough time to reroute traffic before data loss. The system is fully containerized (Docker/Kubernetes) and deploys on-premise for air-gapped environments, on GovCloud (AWS GovCloud, Azure Government), or standard commercial clouds.

Right now we're testing with defense and commercial partners. The dashboard shows real-time link health, forecasts at 60/180/300 seconds out, and root cause analysis (is this rain fade? satellite setting below horizon? congestion?). We expose everything via API - telemetry ingestion, predictions, topology snapshots, even an LLM chat endpoint for natural language troubleshooting.

The hard parts we're still working on: prediction accuracy degrades for longer time horizons (beyond 5 minutes gets dicey), we need more labeled failure data for rare edge cases, and the federated learning setup requires careful orchestration across different operators' security boundaries. We'd love feedback from anyone who's worked on satellite ops, RF link modeling, or time-series prediction at scale. What are we missing? What would make this actually useful in a production NOC environment?

Happy to answer any technical questions!

I didn't write a single line of code.

Of course no-code doesn't mean no-engineering. This project took a lot more manual labor than I'd hoped!

I wrote a deep dive on the workflow and some thoughts about the future of AI coding and creativity:

http://cannoneyed.com/projects/isometric-nyc

https://web.archive.org/web/20250831074424/https://www.theat...

https://archive.ph/GBZBf

If you’ve tried plotting AI-generated images, you probably know the struggle: generic tracing tools (like Potrace) trace the outline of a line, resulting in double-strokes that ruin the look and take twice as long to plot.

What I tried previously:

- Potrace / Inkscape Trace: Great for filled shapes, but results in "hollow" lines for line art.

- Canny Edge Detection: Often too messy; it picks up noise and creates jittery paths.

- Standard SDXL: Struggled with geometric coherence, often breaking lines or hallucinating perspective.

- A bunch of projects that claimed to be txt2svg but which produced extremely poor results, at least for pen plotting. (Chat2SVG, StarVector, OmniSVG, DeepSVG, SVG-VAE, VectorFusion, DiffSketcher, SVGDreamer, SVGDreamer++, NeuralSVG, SVGFusion, VectorWeaver, SwiftSketch, CLIPasso, CLIPDraw, InternSVG)

My Approach:

I ended up writing a Python tool that combines a few specific technologies to get a true "centerline" vector:

1. Prompt Engineering: An LLM rewrites the prompt to enforce a "Technical Drawing" style optimized for the generator.

2. Generation: I'm using Flux.2-dev (4-bit). It seems significantly better than SDXL at maintaining straight lines and coherent geometry.

3. Skeletonization: This is the key part. Instead of tracing contours, I use Lee’s Method (via scikit-image) to erode the image down to a 1-pixel wide skeleton. This recovers the actual stroke path.

4. Graph Conversion: The pixel skeleton is converted into a graph to identify nodes and edges, pruning out small artifacts/noise.

5. Optimization: Finally, I feed it into vpype to merge segments and sort the paths (TSP) so the plotter isn't jumping around constantly.

You can see the results in the examples inside the Github repo.

The project is currently quite barebones, but it produces better results than other options I've tested so I'm publishing it. I'm interested in implementing better pre/post processing, API-based generation, and identifying shapes for cross-hatching.