After fixing the export pipeline, one thing became obvious:

Figures are ready.

But something is still missing.

👉 The parameters behind those figures.

Every research paper includes a table like this:

• Modulation scheme

• SNR range

• Channel model

• Number of iterations

• Bandwidth

And today, that table is created manually.

Day 31 starts fixing that.

The Problem

Right now, the workflow looks like this:

• Run simulation

• Open config

• Copy parameters

• Write LaTeX table manually

• Fix formatting

• Double-check values

This is slow and error-prone.

👉 One small mistake = wrong paper.

The Idea

Instead of writing tables manually:

👉 Generate them automatically.

Introducing:

LaTeX Parameter Table Generator

What It Does

Every simulation now has a structured configuration.

From that config, the system generates:

• Clean LaTeX table

• Proper alignment

• Ready-to-use format

Example output:

\begin{tabular}{ll}
\toprule
Parameter & Value \\
\midrule
Modulation & QPSK \\
SNR Range & 0–20 dB \\
Iterations & 10000 \\
Channel Model & AWGN \\
\bottomrule
\end{tabular}

👉 Copy → paste into Overleaf → done.

How It Works — Backend

Spring Boot extracts simulation parameters from stored JSON.

A formatter service:

• Maps keys → readable names

• Formats values properly

• Generates LaTeX string

This is returned via API.

Frontend — Simple but Powerful

Angular adds:

• “Generate LaTeX Table” button

• Copy-to-clipboard option

User doesn’t see complexity.

Just clicks → gets table.

One Challenge

Not all parameters are simple.

Some are:

• Arrays

• Nested configs

• Derived values

Fix: → Flatten + normalize before formatting

Ensures clean output.

Why This Matters

This feature removes a repetitive task.

Instead of:

→ Writing tables manually

You get:

→ Automatic, consistent output

Across multiple experiments — this saves hours.

The Bigger Shift

Now the pipeline is forming:

• Figures → ready ✅

• Tables → ready ✅

Next:

👉 Reproducibility

Because a paper is not complete without it.

What’s Next

Day 32: Reproducibility Package — One Click to Recreate Everything

From simulation → to complete experiment bundle.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 31

Yesterday, the export pipeline was working.

Today was about something different:

👉 Making sure it works every time.

Because “it works on my machine” is not enough — especially for a research tool.

The Reality After Implementation

Once the export feature was in place, small issues started showing up:

• Some charts exported with wrong dimensions

• Font sizes looked different in PDF

• Background was not always pure white

• Large datasets caused slight rendering lag

Individually small.

Together — they break trust.

The Goal for Today

Not adding new features.

👉 Making the existing one stable.

Fix 1 — Consistent Dimensions

Problem: Charts were exporting with inconsistent sizes depending on screen resolution.

Fix:

• Defined fixed export dimensions

• Standardized width/height ratio

• Decoupled export size from UI size

Now exports look identical across devices.

Fix 2 — Font Consistency

Problem: Fonts looked correct on screen but different in exported files.

Cause: Browser rendering vs export rendering mismatch.

Fix:

• Forced font override before export

• Explicit font embedding in PDF

• Standardized font scaling

Now exported figures match expected formatting.

Fix 3 — Background Control

Problem: Some exports had transparent or slightly tinted backgrounds.

Fix:

• Explicit white background layer added before export

• Removed all UI overlays during export

Now every export is clean and paper-ready.

Fix 4 — Handling Large Data

Problem: Heavy simulations caused slow export or lag.

Fix:

• Optimized rendering before capture

• Reduced unnecessary redraw cycles

• Ensured export happens after render completion

One Important Lesson

Building a feature is step one.

Stabilizing it is step two.

👉 And step two is where real quality comes from.

What’s Working Now

• PNG export (high quality, consistent) ✅

• PDF export (proper scaling, fonts fixed) ✅

• Styling override stable ✅

• No UI artifacts in export ✅

SVG still being refined.

Why This Matters

This feature is now:

👉 Not just usable 👉 But dependable

And for research tools, reliability matters more than features.

The Bigger Shift

From: → “Feature works”

To: → “Feature is trustworthy”

That’s the difference between a demo and a product.

What’s Next

Day 31: LaTeX Parameter Table Generator — Turning Config into Paper-Ready Tables

Because figures are only half the story — parameters matter just as much.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 30

Yesterday was all about designing the IEEE Figure Wizard.

Today was different.

👉 Today, the goal was simple: Make export actually work.

The First Step — Getting Data Out of the Chart

At first glance, exporting a chart sounds easy.

But internally, charts are rendered on a canvas.

Which means:

• What you see ≠ what you can directly export

• You need to extract it properly

The starting point was:

canvas.toDataURL("image/png")

This gives a PNG image of the chart.

Simple — but not enough.

PNG Export — The Easy Win

PNG was the first format to get working.

Steps:

• Capture chart canvas

• Convert to data URL

• Trigger download

This worked immediately.

But quality mattered.

So:

• Set maximum resolution

• Ensured clean white background

• Removed UI artifacts

Now PNG export is stable and usable.

The Real Challenge — PDF and SVG

PNG solves screenshots.

But research requires:

👉 Vector formats

PDF Export

For PDF:

• Integrated jsPDF

• Embedded the chart image

• Ensured correct scaling

Problem faced:

👉 Scaling mismatch — chart looked stretched

Fix: → Maintain aspect ratio + controlled dimensions

SVG Export

SVG is trickier.

Canvas doesn’t directly export SVG.

So options explored:

• Chart.js plugins

• Manual conversion

• Alternative rendering strategies

This part required deeper experimentation.

Styling Before Export

One key thing implemented:

👉 Export styling override

Before exporting:

• Font → Times New Roman

• Font size adjusted

• Grid cleaned

• Background forced white

After export: → Original UI restored

User never sees the change — only the result.

Backend Role (Small but Important)

A basic export metadata endpoint was added.

Purpose:

• Store export-related configuration

• Prepare for LaTeX integration

This becomes useful in next features.

What’s Working Now

• PNG export ✅

• PDF export (basic) ✅

• Styling override logic ✅

• Export trigger from UI ✅

SVG still under refinement.

Why This Matters

This is the first feature where:

👉 A user can take output directly from the platform 👉 And use it outside the platform

That changes how the tool is used.

The Bigger Shift

Before: → View results

Now: → Extract results

Next: → Publish results

What’s Next

Day 30: Fixing Edge Cases and Improving Export Quality

Because export is only useful if it works reliably every time.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 29

Yesterday I defined the Publication Pipeline.

Today I focused on the first and most important part of it:

👉 Figure generation

Not just exporting charts — but making them publication-ready.

The Problem

Right now, exporting a chart is easy.

But using it in a research paper?

Not so easy.

Researchers usually:

• Take a screenshot

• Paste into PowerPoint or LaTeX

• Adjust font sizes

• Fix alignment

• Increase resolution manually

This is repetitive and inconsistent.

What Makes a Figure “Publication Ready”?

After digging into IEEE and research paper standards, a few requirements stood out:

• Font: Times New Roman

• Font size: 8–10 pt

• Clean white background

• Proper axis labeling

• High resolution (300 DPI+)

• Vector formats preferred (SVG/PDF)

👉 Most dashboards don’t follow these.

The Design Decision

Instead of letting users manually fix everything, the system should:

👉 Automatically apply publication standards during export

So I defined the feature as:

👉 “IEEE Figure Wizard”

A one-click export system that converts any chart into:

• PNG (high resolution)

• PDF (ready for papers)

• SVG (vector format)

With correct styling applied.

How It Will Work

The export process will have three steps:

1. Temporary Style Override

Before exporting, chart styling is adjusted:

• Font → Times New Roman

• Font size → standardized

• Grid → minimal

• Background → white

2. Format Conversion

Depending on export type:

• PNG → Canvas export

• PDF → jsPDF integration

• SVG → vector conversion

3. Download Ready File

User gets a file that can go directly into:

• LaTeX

• Word

• Research papers

No manual fixes needed.

One Key Challenge

Charts in web apps are optimized for screens — not print.

That creates issues like:

• Scaling problems

• Font mismatch

• Pixelation in exports

So the export system must treat display and export differently.

Why This Matters

This feature directly saves time.

Instead of:

→ 10 minutes per figure

You get:

→ 1 click → ready to use

Across multiple experiments, that’s hours saved.

The Bigger Shift

This is the first feature where:

👉 The output is not just for viewing 👉 It’s for publishing

That’s a major transition.

What’s Next

Day 29: Implementing the Export Pipeline

From design → actual working feature.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 28

After understanding how researchers work yesterday, one thing became obvious:

👉 Everything leads to publication.

No matter how complex the simulation is — its final destination is usually a figure, a table, or a result inside a paper.

But the path to get there?

Messy.

The Current Reality

Right now, the workflow looks like this:

• Run simulation

• Take screenshot of chart

• Adjust labels manually

• Fix font sizes

• Recreate tables in LaTeX

• Double-check parameters

• Hope everything is consistent

This process is repeated again and again.

The Core Problem

The issue is not lack of tools.

It’s lack of integration.

Simulation tools and publication tools live in completely different worlds.

👉 There is no direct bridge between them.

The Idea: Publication Pipeline

Today I defined a clear direction:

👉 Build a “Publication Pipeline”

A system where:

• Simulation → automatically becomes figure

• Parameters → automatically become table

• Results → automatically become reproducible

No manual steps in between.

Breaking It Down

The pipeline will have three core parts:

1. Figure Generation

Export charts in publication-ready format (IEEE, Nature standards)

2. Parameter Tables

Auto-generate LaTeX tables directly from simulation config

3. Reproducibility Package

Bundle everything needed to recreate the result

• Config

• Random seeds

• Environment info

Why This Matters

This is not a “nice-to-have” feature.

This is where real time is lost.

Researchers spend hours:

• Formatting figures

• Rewriting tables

• Reproducing results

👉 Automating this saves real effort.

The Bigger Shift

This is the first true “moat” feature.

Because:

• Simulation tools don’t handle publishing

• Publishing tools don’t understand simulations

This sits exactly in the gap.

What Changes Now

From this point forward:

Every simulation result should be:

👉 Ready to publish 👉 Ready to share 👉 Ready to reproduce

What’s Next

Day 28: Designing the IEEE Figure Export System

The first part of the publication pipeline — turning charts into paper-ready figures.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 27

Yesterday marked the start of Phase 3.

Today was different.

No major feature. No new chart. No visible output.

Just thinking.

The Real Question

If Sionna Visualizer is going to become a research platform, then one thing becomes critical:

👉 How do researchers actually work?

Not how I think they work. Not how tutorials show it.

But real workflows.

What I Observed

After going through discussions, papers, and tools, a pattern became clear:

A typical research workflow looks like this:

1. Run simulation

2. Adjust parameters

3. Run again

4. Compare results

5. Export figures

6. Write paper

7. Re-run everything for verification

This loop repeats multiple times.

The Hidden Problems

The simulation itself is not the hardest part.

The real friction is here:

• No structured way to track experiments

• Parameters are often lost or scattered

• Reproducing results becomes difficult

• Exporting for papers is manual work

👉 The process is fragmented.

What This Means for the Product

This changed how I think about features.

Instead of asking:

→ “What can I build next?”

I now ask:

→ “Where is the friction in the workflow?”

A Key Realization

A dashboard shows results.

A platform supports a workflow.

That’s the difference.

What I’m Optimizing For

From this point forward, every feature should:

• Reduce manual work

• Improve reproducibility

• Make sharing easier

• Fit naturally into research flow

If it doesn’t do at least one of these — it’s noise.

Why Today Matters

This might not look like progress.

But this is the kind of thinking that decides:

👉 Whether a project becomes useful or 👉 Just another demo

What’s Next

Day 27: Defining the Publication Pipeline

Now that the workflow is clear, the next step is to attack the biggest pain point — publishing.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 26

Up until now, Sionna Visualizer has been about one thing:

👉 Making simulation results visible.

Charts, comparisons, exports — all focused on understanding output.

But today, I stepped back and asked a bigger question:

Is this just a dashboard… or can it become something more?

Day 25 is where that answer starts to change.

The Realization

While building and interacting with the community, one pattern became clear:

Researchers don’t struggle with running simulations. They struggle with everything around it.

• Preparing figures for papers

• Reproducing results later

• Sharing experiments with others

• Managing simulation history

👉 The problem is not simulation. 👉 The problem is the workflow.

The Shift

Phase 3 is not about adding more charts.

It’s about solving real research problems.

From this point forward, the goal is:

👉 Turn Sionna Visualizer into a research workflow platform

The First Direction

The first focus area is clear:

📄 Publication Pipeline

Because every simulation eventually ends up in a paper.

And right now, that process is completely manual.

Researchers:

• Take screenshots

• Adjust formatting

• Recreate tables

• Re-run simulations for reproducibility

This is slow. Repetitive. Error-prone.

What’s Coming Next

Phase 3 will introduce features like:

• IEEE/Nature figure export

• LaTeX parameter table generation

• Reproducibility packages

Not as add-ons — but as core functionality.

Why This Matters

This is where differentiation begins.

NVIDIA provides the simulation engine. Sionna provides the algorithms.

But the workflow layer is still missing.

That’s the gap I’m building for.

The Bigger Picture

This is no longer just:

→ “Visualizing simulation results”

It’s becoming:

→ “Helping researchers go from simulation → publication → collaboration”

What Changes From Today

Every feature from now on will be judged by one question:

👉 Does this help a researcher do real work faster?

If not — it doesn’t get built.

What’s Next

Day 26: Thinking Like a Researcher

Before building new features, I need to understand how researchers actually work.

Because building the right thing starts with asking the right questions.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 25

This feature didn’t start with a bug. It started with a realization.

Even when the simulation was correct — sometimes the visualization wasn’t helping.

Colors were there. But clarity was missing.

Day 24 fixes that.

The Problem

Most default charts use generic color schemes.

They work — but not for research.

Issues I noticed:

• Hard to distinguish values in dense regions

• Poor contrast in certain ranges

• Not accessible for colorblind users

• No consistency across different charts

👉 The data was right, but the interpretation was harder than it should be.

What’s New

Sionna Visualizer now supports custom colormaps.

Users can switch between multiple palettes:

• Viridis (scientific standard)

• Plasma

• Inferno

• Cool/Warm

• Grayscale

• Colorblind-safe palette

Each palette is designed to improve readability for different scenarios.

How It Works — Color Mapping Layer

Instead of hardcoding colors, charts now use a mapping function:

value → normalized range → color scale → rendered output

Every data point passes through this pipeline.

This allows:

• Smooth gradients

• Better contrast

• Consistent visual meaning

Frontend — Dynamic Palette Switching

Angular now includes a colormap selector.

When the user switches palette:

• Charts re-render instantly

• No need to rerun simulation

• Same data, different perspective

One Subtle Challenge

Not all colormaps behave the same.

Some exaggerate differences. Some compress them.

Fix: → Normalized value mapping before applying color

This ensures consistency across all palettes.

Why This Matters

In research, visualization is not decoration.

It’s interpretation.

A poor colormap can:

• Hide patterns

• Mislead analysis

• Reduce clarity

A good one can:

• Reveal trends instantly

• Highlight anomalies

• Improve understanding

The Bigger Shift

This feature moves Sionna Visualizer from:

→ “Displaying results” to → “Helping interpret results”

That’s a big difference.

What’s Next

Day 25: Starting Phase 3 — The Shift to a Research Platform

Because visualization alone is not enough anymore.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 24

This feature started from a simple frustration.

You click “Run Simulation” — and then you wait.

Sometimes it finishes in seconds. Sometimes it takes minutes. Sometimes… you’re not even sure if it’s stuck.

There was no way to know.

Day 23 fixes that.

The Problem

As simulations get more complex:

• Higher SNR ranges

• More Monte Carlo iterations

• Larger antenna configurations

The execution time increases — but unpredictably.

For researchers, this creates a real issue:

👉 You can’t plan your experiments efficiently.

What’s New

Before running any simulation, Sionna Visualizer now shows:

• Estimated execution time

• Complexity level (Low / Medium / High)

This estimate updates dynamically as parameters change.

How It Works — Estimation Logic

The estimation is based on three key factors:

Estimated Time ∝ (Number of SNR points) 
               × (Monte Carlo iterations) 
               × (Model complexity)

Each simulation type has a base cost.

That base cost is scaled depending on:

• Modulation scheme (BPSK vs 64QAM)

• Number of samples

• Channel conditions

Backend — Lightweight Prediction Layer

A new estimation service was added in Spring Boot.

Before the simulation runs:

• Request parameters are analyzed

• A heuristic model calculates expected time

• Response is sent instantly to frontend

No actual simulation is triggered here — only prediction.

Frontend — Immediate Feedback

Angular displays a small card before execution:

• ⏱️ Estimated Time: ~2.3 seconds

• ⚙️ Complexity: Medium

This updates live as users change parameters.

So instead of guessing, you now know.

One Small Detail That Matters

During testing, one issue came up.

Very small simulations were showing 0 seconds — which felt broken.

Fix: → Added minimum threshold + rounding logic

Now even fast runs feel intentional, not random.

Why This Matters

This is not just a UI improvement.

It changes how people use the tool.

Before: → Trial and error → Run and wait

Now: → Plan first → Run with intent

The Bigger Shift

This feature moves Sionna Visualizer closer to:

👉 A research workflow tool, not just a simulator

Because in real research:

• Time matters

• Planning matters

• Efficiency matters

What’s Next

Day 24: Custom Colormaps

Because once the data is correct — how you see it becomes just as important.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program Building in Public — Day 23

3. Data Table

For exact numeric inspection — useful for researchers.

Together, these views answer a simple but critical question:

👉 Where is the signal actually going?

Why This Matters

Wireless communication is not just about final results.

It’s about understanding propagation.

Before this, a researcher could see a weak signal — but not explain it.

Now:

• You can identify dominant paths

• Spot weak reflections

• Understand delay spread

• Debug unexpected attenuation

This turns Sionna Visualizer from a result viewer into an analysis tool.

The Bigger Shift

This feature changes how simulations are interpreted.

From:
→ “What is the result?”

To:
→ “Why is this the result?”

That difference is everything in research.

What’s Next

Day 23: Simulation Time Estimation
Before running a simulation — estimate how long it will take.

Because once you start thinking like a researcher,
time becomes as important as accuracy.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer
Live: https://sionna-visualizer.vercel.app

NVIDIA AI Aerial / 6G Developer Program
Building in Public — Day 22

This feature started with a GitHub thread.

A researcher asked about Sionna's performance bottlenecks — how long path computation takes, what hardware is involved, whether it scales. The thread had replies. No solution. Just researchers agreeing the information wasn't visible anywhere.

Day 21 makes it visible.

What Gets Tracked Now

Every simulation in Sionna Visualizer now returns four performance fields alongside the result:

• Duration — exact milliseconds from computation start to finish

• Memory — peak RAM consumed during simulation, in MB

• Compute type — CPU or GPU, detected automatically via torch.cuda.is_available()

• Sionna version — the exact library version that produced the result

These aren't estimates. They're measured during the actual run using Python's tracemalloc for memory and time.perf_counter() for duration.

How It Works — Three Layers

The Python FastAPI bridge now wraps every simulation endpoint in a run_with_performance() helper. Before the Sionna math runs — tracemalloc starts, timer starts. After it finishes — everything stops, peak values extracted, packaged into a PerformanceMetadata object attached to the response.

One bug showed up during implementation: tracemalloc returns raw bytes. Converting to MB requires careful float handling — a rounding edge case was causing crashes. Fixed before it could affect anyone.

Java receives the nested performance JSON, maps it through a dedicated PerformanceDto, and saves all four fields to PostgreSQL alongside the simulation result. Every run from today onwards has permanent performance history.

Angular displays a 2x2 card beneath every chart — duration, compute type, memory, Sionna version. When GPU acceleration is detected, the card gets a teal left border. A small visual signal with real meaning for researchers who care about hardware.

The card also appears on shareable links. A researcher sharing results with a colleague can now show not just what the simulation produced — but exactly how it was produced.

Why This Matters for the Community

Sionna is used for research. Research requires reproducibility. Reproducibility requires knowing your compute environment.

Until today, a researcher sharing a Sionna Visualizer link could show their BER curves but not the conditions that generated them. Now both travel together.

When I reply to the GitHub thread that inspired this feature, I'll link directly to a shared result showing the performance card. That's the complete loop — researcher asks question, tool answers it, researcher sees the answer live.

Day 22 is next. Path loss breakdown chart — the most requested feature on Sionna GitHub with 9 replies on a single thread.

Sionna Visualizer — github.com/Vinu2111/sionna-visualizer Live: [your Vercel URL] NVIDIA AI Aerial / 6G Developer Program

Building features is the exciting part. But Day 20 was about something different — making everything already built feel fast, reliable, and professional.

Three things shipped today. All of them invisible to the end user. All of them essential.

The Problem With No Cache

Every simulation request in Sionna Visualizer followed the same path: Angular → Java → Python → back to Java → PostgreSQL → response. That chain works. But what happens when a researcher runs the same parameters twice?

Without caching: full round trip. Python computes again. Database writes again. User waits again.

Today I added a ConcurrentHashMap-backed cache inside SimulationService.java. The logic is simple — hash the incoming request parameters into a key, check the map before calling Python. Hit? Return instantly and log it. Miss? Proceed normally and store the result. Cache size capped at 100 entries with timestamp-based eviction when full.

No Redis. No external dependency. Just Java doing what Java does well.

The Cold Start Problem on Railway

Railway free tier is generous. But it has one behavior that can frustrate first-time visitors: services spin down after inactivity. The first request after a quiet period wakes everything up — and that wake-up can take 10-15 seconds.

For a research tool, a 15-second spinner on first load is a trust problem.

The fix: a /warmup endpoint in the Python FastAPI bridge that runs a minimal 3-point BPSK simulation. Fast. Lightweight. Just enough to force the container active. Java now calls this endpoint automatically via @PostConstruct on startup — so Python is warm before any real user arrives.

The Spring Actuator health endpoint now reports "python-bridge": "warm" or "python-bridge": "cold" so you can see the bridge state at any time.

The README That Should Have Existed Earlier

47 features. Live deployment. NVIDIA Forums post. Sionna GitHub Show and Tell. And the README was still basic.

That changes today. The new README has: one-line description, live demo links, plain English explanation of what the tool does, features organized in three columns, tech stack table, 3-step Docker quick start, three curl examples for the public API, screenshot placeholders, and a proper author section.

It won't win a design award. But it will tell a Nokia engineer everything they need to know in 30 seconds.

What Day 20 Taught Me

The features you can see get built first. The infrastructure underneath them — caching, warmup, documentation — feels less exciting to build. But it's the difference between a project that works and a project that's ready.

Day 21 is next. Phase 2A begins — simulation performance metadata, built directly from a real researcher question on Sionna GitHub.

PNG for figures. CSV for analysis. JSON for Python scripts. Bulk export for entire simulation history. The bridge between a web dashboard and a research workflow.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 📚 API Docs: https://sionna-visualizer.vercel.app/api-docs 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

Why Export Matters More Than Features

A researcher can run a beautiful BER vs SNR simulation on Sionna Visualizer. They can see the two-curve logarithmic chart. They can share it with a public link.

But if they cannot get that data out of the browser and into their paper — the tool stops at the browser. Day 19 removes that boundary.

Every simulation result can now leave the dashboard in four formats. Each format serves a different research workflow.

The Four Export Formats

PNG — For Paper Figures

One click. The exact chart as rendered — dark theme, teal and coral curves, logarithmic axes, legend — downloads as a high-quality PNG.

Filename is automatically generated with simulation parameters:

• sionna-ber-snr-QPSK-2026-03-21.png

• sionna-beam-pattern-16ant-2026-03-21.png

• sionna-channel-capacity-2026-03-21.png

Using Chart.js toBase64Image() at full quality. No server round-trip. Instant download.

CSV — For Excel and MATLAB Analysis

Every data point exported as a clean CSV with metadata headers:

# Sionna Visualizer — BER vs SNR
# Modulation: QPSK, Code Rate: 0.5, SNR Range: -5 to 20 dB
snr_db,ber_theoretical,ber_simulated
-5.0,0.21322,0.21422
-3.96,0.18497,0.18419
...

BOM character at the start ensures the file opens cleanly in Excel without encoding issues. Works on Windows, Mac, Linux.

JSON — For Python Scripts

The complete raw simulation result with a metadata header:

{
  "_metadata": {
    "exported_from": "Sionna Visualizer",
    "export_date": "2026-03-21T10:30:00Z",
    "live_url": "https://sionna-visualizer.vercel.app",
    "github": "https://github.com/Vinu2111/sionna-visualizer",
    "simulation_type": "BER_SNR"
  },
  "modulation": "QPSK",
  "snr_db": [-5.0, ...],
  "ber_theoretical": [0.2132, ...],
  "ber_simulated": [0.2142, ...]
}

A researcher downloads this, loads it in Python with json.load(), and has all the data ready to plot with matplotlib in seconds.

Copy JSON — For Jupyter Notebooks

Faster than downloading. Click Copy JSON. The full result is on the clipboard. Paste directly into a Jupyter notebook cell. No file management.

History Page Bulk Export

For researchers who run many simulations in a session:

Export Selected — check any simulations in history, click Export Selected, choose CSV or JSON, all files download with 200ms delay between each to prevent browser blocking.

Export All — one click downloads a single combined JSON file containing every simulation in history:

{
  "_metadata": { ... },
  "total_simulations": 12,
  "simulations": [
    { BER_SNR result },
    { BEAM_PATTERN result },
    ...
  ]
}

This file is the complete research session. Load it once. Process all results.

Export on the Share Page

The public shareable results page now shows three export buttons visible to everyone — no login required.

A researcher shares a simulation link with a colleague. The colleague opens it, sees the chart, and downloads the raw data directly. No account needed. No barriers.

This is what makes shareable links genuinely useful for collaboration rather than just screenshot sharing.

The Export Service Architecture

All export logic lives in a single Angular service: ExportService.

Four methods — one per simulation type:

• generateBerCsv(result) — formats BER data

• generateBeamCsv(result) — formats angle/pattern data

• generateModComparisonCsv(result) — formats four modulation columns

• generateCapacityCsv(result) — formats capacity curves per bandwidth

Plus two utility methods:

• downloadCSV(filename, content) — triggers browser download

• downloadJSON(filename, data) — triggers browser download

No backend changes needed. All exports generated client-side in Angular. Zero server load.

Why This Gets You Citations

Here is the research workflow that Day 19 enables:

1. Researcher opens Sionna Visualizer

2. Runs QPSK BER vs SNR simulation

3. Downloads JSON result

4. Loads JSON in Python script

5. Generates plot for their paper

6. Paper gets submitted

7. Paper cites the tool that provided the baseline simulation data

That citation is what builds academic reputation. That citation is what NVIDIA notices. That citation is what Nokia engineers see when they read papers.

Export features are not convenience features. They are the path to academic recognition.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

1. Run any simulation

2. Click Download PNG — save the chart

3. Click Download CSV — open in Excel

4. Click Download JSON — load in Python

5. Go to History — click Export All

6. Open the JSON — your complete research session

Tech Stack

Angular 17 · Chart.js · Angular Material · Java 17 · Spring Boot 3 · PostgreSQL · Railway · Vercel

What's Next — Day 20

Performance optimization and README update. Caching frequent simulations, optimizing Railway cold starts, and updating the GitHub README with all new features, screenshots, and API documentation. After Day 20 the GitHub repo looks complete and impressive to anyone who discovers it.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

C = B × log₂(1 + SNR). Four bandwidth curves. Two charts. Four insight cards. The theoretical foundation of all wireless communications — now live on the dashboard.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 📚 API Docs: https://sionna-visualizer.vercel.app/api-docs 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

The Equation Behind Every 6G Design Decision

In 1948, Claude Shannon proved that every communication channel has a theoretical maximum data rate. No matter how clever your modulation or coding scheme — you cannot exceed this limit.

The formula:

C = B × log₂(1 + SNR)

Where:

• C = channel capacity in bits per second

• B = bandwidth in Hz

• SNR = signal to noise ratio (linear)

This single equation determines:

• Why 6G uses mmWave frequencies (more bandwidth = more capacity)

• Why 5G/6G base stations are placed closer together (higher SNR)

• What the absolute maximum throughput of any wireless link is

• Why increasing bandwidth by 10x matters more than increasing SNR

Every 6G system designer works with this equation daily. Today I made it interactive.

What the Dashboard Shows

Chart 1 — Capacity vs SNR

Four curves — one per bandwidth:

• 10 MHz (white) — Sub-6GHz basic

• 100 MHz (teal) — Sub-6GHz 6G baseline

• 400 MHz (yellow) — mmWave 6G

• 1000 MHz (coral) — mmWave wide channel

Two horizontal reference lines at 1 Gbps and 10 Gbps show the 6G design targets. The intersection of each bandwidth curve with these lines tells you exactly what SNR you need to hit those targets.

Chart 2 — Spectral Efficiency

A single curve showing bits/s/Hz vs SNR — bandwidth independent. This is the fundamental efficiency limit of any modulation scheme. At SNR = 20 dB, the maximum spectral efficiency is approximately 6.66 bits/s/Hz. No modulation can exceed this — not BPSK, not 64QAM, not anything invented in the future.

The Four Insight Cards

Below the charts, four cards answer the exact questions 6G system designers ask:

SNR for 1 Gbps @ 100 MHz The minimum SNR needed to achieve the 6G baseline throughput target on a standard sub-6GHz channel. This is the design floor for 6G base station placement.

SNR for 10 Gbps @ 1 GHz The minimum SNR needed to achieve peak 6G throughput on a wide mmWave channel. This is why 6G mmWave cells need line-of-sight conditions.

Spectral Efficiency @ SNR 20 dB The theoretical maximum bits per Hz at a comfortable SNR. Every real modulation scheme operates below this line.

10x Bandwidth Gain How much capacity multiplier you get from increasing bandwidth by 10x vs increasing SNR. Bandwidth wins every time — this is why 6G went to mmWave.

The Python Math

import numpy as np

def channel_capacity(snr_db, bandwidth_mhz):
    # Convert SNR from dB to linear
    snr_linear = 10 ** (snr_db / 10)
    # Shannon formula
    capacity_bps = bandwidth_mhz * 1e6 * np.log2(1 + snr_linear)
    # Convert to Gbps
    return capacity_bps / 1e9

Four lines. The most important formula in telecommunications. Running in 94ms on Railway free tier.

What Changed Across the Stack

Python Bridge

• New file: channel_capacity.py

• Shannon formula for 4 bandwidth curves simultaneously

• Spectral efficiency computation

• Automatic insight calculation

• New endpoint: POST /simulate/channel-capacity

Java Backend

• ChannelCapacityRequestDto and ResultDto

• 3 new JSON columns on SimulationResult entity

• simulation_type = CHANNEL_CAPACITY

• New endpoint: POST /api/simulations/channel-capacity

• Public API: POST /v1/api/simulate/channel-capacity

Angular 17

• Fourth tab on dashboard: Shannon Capacity

• Bandwidth checkboxes to toggle curves

• Two Chart.js charts side by side

• Four insight cards with real 6G values

• Blue history badge: Capacity

• API docs updated with new endpoint

The Dashboard Now Has Four Simulation Types

Tab 1 — BER vs SNR: Error performance. AWGN + Monte Carlo. Tab 2 — Beam Pattern: Antenna directivity. ULA model. Tab 3 — Modulation Comparison: Spectral efficiency tradeoff. Tab 4 — Shannon Capacity: Theoretical maximum throughput.

These four cover the four most important concepts in 6G physical layer research. Any researcher working on 6G needs all four regularly.

Use It Via the API

import requests

response = requests.post(
    "https://sionna-visualizer-production-50ae.up.railway.app/v1/api/simulate/channel-capacity",
    headers={"X-API-Key": "sk-sionna-your-key"},
    json={
        "snr_min": -10,
        "snr_max": 30,
        "snr_steps": 50,
        "bandwidths_mhz": [100, 400, 1000]
    }
)
result = response.json()
print(f"SNR for 1Gbps on 100MHz: "
      f"{result['insights']['snr_for_1gbps_100mhz']:.1f} dB")

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

1. Login and click the Shannon Capacity tab

2. Keep all 4 bandwidths checked

3. Click Compute Capacity

4. Watch the logarithmic curves appear

5. Read the insight cards

6. Uncheck 10 MHz and 100 MHz

7. See only the mmWave curves

8. Notice how much more capacity mmWave provides

Tech Stack

Python 3.10 · NumPy · FastAPI · Java 17 · Spring Boot 3 · PostgreSQL · Angular 17 · Chart.js · Railway · Vercel

What's Next — Day 19

Export and Download features. Let researchers download their simulation results as PNG, CSV, and PDF. One click. No copy-paste. This is what makes the tool useful for writing papers.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

Any researcher can now call real 6G simulations directly from their Python script. No browser. No login. Just an API key and one HTTP request.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 📚 API Docs: https://sionna-visualizer.vercel.app/api-docs 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

The Shift From Website to Platform

Days 1 through 16 built a web dashboard. You open a browser, run simulations, see charts. That's useful. But researchers don't live in browsers. They live in Python scripts, Jupyter notebooks, and terminal windows.

Day 17 meets them where they are.

Sionna Visualizer now has a public REST API. Any researcher with an API key can call real 6G simulations programmatically and get results back as JSON in milliseconds.

What You Can Do Right Now

import requests
import matplotlib.pyplot as plt

API_KEY = "sk-sionna-your-key-here"
BASE_URL = "https://sionna-visualizer-production-50ae.up.railway.app"

# Run a real BER vs SNR simulation
response = requests.post(
    f"{BASE_URL}/v1/api/simulate/ber-snr",
    headers={"X-API-Key": API_KEY},
    json={
        "modulation_order": 4,
        "code_rate": 0.5,
        "snr_min": -5.0,
        "snr_max": 20.0,
        "snr_steps": 25
    }
)

result = response.json()

# Plot directly in your research script
plt.semilogy(result['snr_db'], result['ber_theoretical'],
             '--', label='Theoretical')
plt.semilogy(result['snr_db'], result['ber_simulated'],
             '-', label='Simulated')
plt.xlabel('SNR (dB)')
plt.ylabel('BER')
plt.title(f"BER vs SNR — {result['modulation']}")
plt.legend()
plt.grid(True)
plt.show()

That's it. One API call. Real simulation. Ready to plot in your paper.

The Three API Endpoints

POST /v1/api/simulate/ber-snr Real AWGN simulation. Returns theoretical and Monte Carlo BER curves for BPSK, QPSK, 16QAM, or 64QAM.

POST /v1/api/simulate/beam-pattern Real ULA antenna simulation. Returns beam pattern data for 8 to 128 antenna elements at any frequency from 1 to 100 GHz.

POST /v1/api/simulate/modulation-comparison All four modulations simultaneously. Returns crossover points and spectral efficiency data.

GET /v1/api/health No auth required. Returns API status and available simulations.

How Authentication Works

The API uses API key authentication — simpler than OAuth, appropriate for research use.

1. Register at https://sionna-visualizer.vercel.app

2. Go to Dashboard → API Keys tab

3. Click Generate Key — give it a description

4. Copy your key: sk-sionna-xxxxxxxxxxxxxxxx

5. Add it to every request as a header: X-API-Key: sk-sionna-xxx

Each key allows 100 requests per day on the free tier. Keys can be revoked from the dashboard at any time.

What Was Built

Java Backend

• ApiKey entity — stored in PostgreSQL with usage tracking

• ApiKeyRepository and ApiKeyService

• ApiKeyAuthFilter — validates X-API-Key header on all /v1/api/** routes

• PublicApiController — three simulation endpoints plus health check

• ApiKeyController — generate, list, and revoke keys (JWT protected)

• Bucket4j rate limiting — 100 requests per day per API key

• HTTP 401 for invalid keys with docs link in response

Angular Frontend

• /api-docs page — publicly accessible, no login required

• Python code examples with syntax highlighting

• Endpoint reference tables with request/response schemas

• API Keys tab on dashboard — generate, view stats, revoke

• API link added to navigation

The API Docs Page

Every serious API needs documentation. The /api-docs page at https://sionna-visualizer.vercel.app/api-docs is publicly accessible — no login required.

It includes the Python quick start example, full endpoint reference with parameter tables, authentication guide, and live API key management for logged-in users.

Why This Matters for Researchers

A researcher using Sionna for their paper now has two options:

Before Day 17: Install Python, install Sionna, write simulation code, debug GPU dependencies, generate plot manually.

After Day 17: pip install requests → one API call → results in 94ms.

For baseline AWGN simulations — which appear in virtually every 6G paper as the reference point — this saves hours of setup work.

Get Your API Key

📚 Full docs: https://sionna-visualizer.vercel.app/api-docs 🔗 Register: https://sionna-visualizer.vercel.app

Tech Stack

Java 17 · Spring Boot 3 · Bucket4j · Spring Security · PostgreSQL · Python FastAPI · Angular 17 · Railway · Vercel

What's Next — Day 18

Channel Capacity Visualization. Shannon's theorem — C = B × log2(1 + SNR). A fourth simulation type showing the theoretical maximum data rate vs SNR for different bandwidths. Every 6G researcher knows this formula. Seeing it interactive on a dashboard is genuinely useful.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev *GitHub: github.com/Vinu2111/sionn

Rate limiting. Circuit breaker. Input validation. Security headers. Health checks. The unglamorous work that keeps a server running when real users arrive.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

Why Day 16 Happened

Yesterday I posted Sionna Visualizer in the NVIDIA Aerial Developer Forums. 2,000+ researchers and engineers from Nokia, Ericsson, Samsung, IIT, and MIT are active there.

If even a fraction of them open the link and start sharing it with their labs — the server needs to handle that. Before Day 16, it couldn't. A handful of simultaneous simulation requests could slow Railway to a crawl.

Day 16 fixed that. No new features. Just making the server robust.

What Was Hardened

Rate Limiting

Using Bucket4j, every IP address is now limited to 10 simulation requests per minute. If the limit is exceeded, the server returns HTTP 429 with:

"Too many requests. Please wait before running another simulation."

Three response headers tell the client exactly where they stand:

• X-RateLimit-Limit: 10

• X-RateLimit-Remaining: [remaining]

• X-RateLimit-Reset: [seconds until reset]

This prevents a single user from accidentally or intentionally hammering the Python bridge.

Input Validation

Before today, sending snr_min: 999 or num_antennas: -5 to the API would cause unpredictable behavior in the Python simulation. Now every request is validated before it reaches the Python bridge:

• SNR range: -20.0 to 40.0 dB

• SNR steps: 10 to 100

• Antenna count: 2 to 128

• Steering angle: -90.0 to 90.0 degrees

• Frequency: 1.0 to 100.0 GHz

Invalid input returns HTTP 400 with the exact field that failed. No stack traces exposed. No internal errors leaked.

Circuit Breaker

Using Resilience4j, the Java backend now has a circuit breaker wrapping every call to the Python bridge.

If the Python bridge fails 5 out of 10 consecutive calls, the circuit opens. For the next 30 seconds, Java stops calling Python entirely and immediately returns HTTP 503:

"Simulation engine is temporarily unavailable.
Please try again in 30 seconds."

This prevents the Java backend from hanging on every request while Python is recovering. The circuit tries again after 30 seconds automatically.

Request Timeout

The Python bridge now enforces a 30-second timeout on every simulation. If computation exceeds that, it returns HTTP 408:

"Simulation timed out. Try reducing the number of SNR steps."

All FastAPI endpoints converted to async using anyio for proper timeout handling.

Security Headers

Every HTTP response now includes:

• X-Content-Type-Options: nosniff

• X-Frame-Options: DENY

• X-XSS-Protection: 1; mode=block

• Referrer-Policy: strict-origin-when-cross-origin

CORS updated from wildcard * to explicitly allow only:

• https://sionna-visualizer.vercel.app

• http://localhost:4200

Health Checks

Java backend exposes /actuator/health — Railway uses this to monitor the service and restart it automatically if it goes down.

Python bridge exposes /health returning:

{
  "status": "healthy",
  "service": "sionna-python-bridge",
  "version": "1.0.0"
}

Angular Error Handling Update

The Angular interceptor now shows specific snackbar messages for each new error type:

• 429: "Too many simulations. Please wait 1 minute."

• 503: "Simulation engine temporarily unavailable. Try in 30 seconds."

• 408: "Simulation timed out. Try fewer SNR points."

• 400: Shows the specific validation error from the backend

The Principle Behind Day 16

Features get people to try your product. Polish gets people to trust your product. Hardening keeps your product running when people actually use it.

All three matter. In that order.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

Tech Stack

Java 17 · Spring Boot 3 · Bucket4j · Resilience4j · Jakarta Validation · Python FastAPI · anyio · Angular 17 · PostgreSQL · Railway · Vercel

What's Next — Day 17

REST API for researchers. A public endpoint that lets anyone POST simulation parameters and get results back as JSON — no login required. Researchers can integrate Sionna Visualizer directly into their Python scripts.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

Run two configurations. Select both from history. Click Compare. See which one wins — automatically.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

The Feature Researchers Actually Need

Every 6G researcher faces the same problem constantly. They run a simulation with one configuration. Then they change one parameter — different modulation, more antennas, different frequency — and run it again. Then they need to compare both results.

Before today, that comparison happened manually. Export the data, open Excel or Python, plot both curves on the same axes, visually inspect which is better. That's 10 minutes of work every single time.

Today I added a comparison tool that does it in 3 clicks.

How It Works

Step 1: Run any two simulations from the dashboard.

Step 2: Go to the History page. Select both using the checkboxes. The first selection highlights teal. The second highlights coral.

Step 3: Click the purple "Compare Selected" button.

Step 4: The comparison page loads with both results overlaid on one chart and a winner card at the bottom.

That's it.

The Overlay Chart

For BER vs SNR comparisons, the chart shows four lines simultaneously:

• Teal dashed — Simulation A theoretical BER

• Teal solid — Simulation A simulated BER

• Coral dashed — Simulation B theoretical BER

• Coral solid — Simulation B simulated BER

Both simulations share the same logarithmic Y axis and SNR X axis. The visual separation between teal and coral makes it immediately obvious which configuration performs better at any given SNR.

For beam pattern comparisons, both ULA patterns overlay on the same polar chart. Teal for Simulation A. Coral for Simulation B. Narrower main lobe = better beamforming = immediately visible.

The Winner Card

Below the chart, a winner card computes the result automatically.

For BER vs SNR: the algorithm compares both theoretical BER arrays at SNR = 20 dB. Lower BER at high SNR = better performance. The card shows: "Simulation A achieves lower BER at high SNR"

For beam patterns: the algorithm compares main_lobe_width values. Narrower beam = more focused signal = better beamforming. The card shows: "Simulation B has narrower main lobe — 8.0° vs 14.2°"

No manual calculation. No spreadsheet. The answer is right there.

What Changed Across the Stack

Java Backend

• New endpoint: GET /api/simulations/compare?id1=X&id2=Y

• ComparisonResponseDto with ComparisonMetadata

• can_overlay flag: true when both simulations are same type

• Security validation: users can only compare their own simulations

Angular Frontend

• New page: /compare with three sections

• Selection panel: dual MatSelect dropdowns from history

• Dynamic overlay chart: 4 lines for BER, 2 lines for beam

• Side by side metrics grid for all parameters

• Winner computation card at bottom

• Share This Comparison button copies URL to clipboard

• Empty state when no simulations exist yet

History Page Upgrade

• MatCheckbox column with maximum 2 selections

• Teal highlight for Simulation A selection

• Coral highlight for Simulation B selection

• Purple Compare Selected button — enabled only when exactly 2 selected

• Compare icon button on each row for quick single-click compare

• Snackbar warning if user tries to select a third simulation

Navigation

• Compare link added to nav menu with compare_arrows icon

Shareable Comparison Links

The comparison page URL itself is the share link:

https://sionna-visualizer.vercel.app/compare?id1=42&id2=67

Copy it. Send it to a colleague. They open it and see the exact same comparison chart. No login required if both simulations have public share UUIDs enabled.

This is what makes the tool genuinely useful for research collaboration.

The Complete Dashboard — Day 15 State

Three simulation types:

• BER vs SNR — real AWGN + Monte Carlo

• Beam Pattern — real ULA antenna math

• Modulation Comparison — all four modulations

Full UX polish:

• Loading states on every action

• Error handling for all failure modes

• Empty states for new users

• Mobile responsive layout

Comparison tool:

• Any two saved simulations

• Overlay chart with winner computation

• Shareable comparison URLs

All saving to PostgreSQL. All generating shareable links. Live on Railway + Vercel.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

1. Register and run a QPSK simulation

2. Run a 16QAM simulation

3. Go to History

4. Select both using checkboxes

5. Click Compare Selected

6. See which modulation performs better at high SNR

Tech Stack

Angular 17 · Angular Material · Chart.js · Java 17 · Spring Boot 3 · Spring Security · JWT · PostgreSQL · Python FastAPI · Railway · Vercel

What's Next

Days 11 through 15 are complete. The core product is done.

Next focus: getting real researchers to use it. NVIDIA Aerial Forums post with live URL. GitHub stars. First external user feedback.

The build phase is complete. The distribution phase begins.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

No new simulation features today. Loading states, error handling, empty states, mobile layout, visual consistency. This is what separates a demo from a product.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

Why UI Polish Matters More Than Features

Days 11, 12, and 13 were about features. Real AWGN simulation. Beam pattern visualization. Modulation comparison. The core simulation engine is now solid.

But features alone don't make a product feel complete. When a researcher lands on your site and clicks Run Simulation — what happens during the 2 seconds it takes to compute? Before today: nothing. The button just sat there. The user had no idea if it was working.

That's not a feature problem. That's a trust problem. Day 14 fixed every trust problem.

What Was Built

Loading States

Every simulation button now shows a MatProgressSpinner while the Python bridge is computing. The button text changes to "Running..." and disables to prevent double-clicks. The dashboard page shows skeleton loader cards on initial load. The history page shows a centered spinner while fetching from PostgreSQL.

Small change. Massive difference in how the product feels.

Error Handling

Four types of errors now handled gracefully:

Simulation errors — MatSnackBar notification at bottom center. Red background. "Simulation failed. Please try again." Dismissable. 5 seconds.

Backend unreachable — Error card replaces the chart area with a wifi_off icon and a Retry button. No more silent blank screen.

Session expired — Auth interceptor catches every 401/403 response automatically. Logs the user out, shows "Your session expired. Please log in again." and redirects to login.

Form validation — SNR Min must be less than SNR Max. Inline red hint text appears if invalid. Run button disabled until form is valid.

Empty States

When a researcher registers for the first time and has no simulation history — they now see a proper empty state with a large icon, a friendly message, and a "Run First Simulation" button that navigates directly to the dashboard.

The dashboard tabs each show a dashed placeholder before any simulation has been run. The shareable link page shows a clean 404 state if the UUID doesn't exist.

Empty states tell the user what to do next. Without them, blank pages feel broken.

Mobile Responsive Layout

The entire dashboard now works on a 375px mobile screen:

• Hamburger menu with MatSidenav — nav links collapse into a side drawer

• Tab labels shortened: "BER/SNR", "Beam", "Compare"

• Charts resize responsively, minimum 300px height

• Parameter forms stack vertically, full width inputs

• History table scrolls horizontally, important columns always visible

Visual Consistency

Global CSS tokens defined in styles.scss:

• Primary: #64ffda

• Error: #ff6b6b

• Warning: #f7b731

• Background: #0a0e1a

• Card background: #0d1117

All cards now have 12px border radius, subtle teal border, and a hover effect that brightens the border. Page transitions use a 200ms fade-in animation on every route change.

Landing Page

Three feature cards added below the hero:

• Real 6G Simulations

• Share with One Link

• Full History

Stats bar: "3 Simulation Types · Real 6G Mathematics · Powered by NVIDIA Sionna · Free to Use"

Footer with GitHub, Hashnode, and Twitter links.

The Principle Behind Day 14

Features get people to try your product. Polish gets people to trust it.

A researcher who runs a simulation and sees a smooth loading spinner trusts the tool more than one who stares at a frozen button. A researcher who gets a clear error message knows the tool is working — even when something goes wrong. A researcher who opens the site on their phone and it works perfectly will use it again.

None of these are simulation features. All of them matter.

Current Dashboard State

Tab 1 — BER vs SNR: Real AWGN + Monte Carlo. Theoretical and simulated curves. Tab 2 — Beam Pattern: Real ULA antenna math. Polar chart. Tab 3 — Modulation Comparison: All four modulations on one chart.

All three polished with loading states, error handling, and mobile layout.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

Open it on your phone. Run a simulation. Watch the loading spinner. Check the history page. See the empty state if you're a new user. This is what production quality UX feels like.

Tech Stack

Angular 17 · Angular Material · Chart.js · Java 17 · Spring Boot 3 · PostgreSQL · Python FastAPI · Railway · Vercel

What's Next — Day 15

Simulation Comparison Tool. Run two different simulation configurations side by side and compare results on the same chart. This is the feature researchers need when testing different antenna configurations or modulation schemes against each other.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

The fundamental 6G spectral efficiency tradeoff. Four curves. Three crossover numbers. Visible instantly.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

The Question Every 6G Researcher Asks

When designing a 6G wireless link, one of the first decisions is modulation scheme. Do you use BPSK, QPSK, 16QAM, or 64QAM?

Higher modulation order means more bits per symbol — more data throughput. But it also means more sensitivity to noise — you need a stronger signal to maintain the same error rate.

Researchers call this the spectral efficiency tradeoff. And they visualize it with one specific chart — BER vs SNR curves for all modulations on the same plot. Today I added that chart to Sionna Visualizer.

What the Chart Shows

Four lines on a logarithmic chart:

• BPSK — white line. 1 bit per symbol. Most robust.

• QPSK — teal line. 2 bits per symbol. Same BER as BPSK.

• 16QAM — yellow line. 4 bits per symbol. Needs more SNR.

• 64QAM — coral line. 6 bits per symbol. Needs the most SNR.

As SNR increases all curves drop toward zero BER — the waterfall region. But they drop at different rates depending on their modulation order.

The Three Numbers That Matter

The Python simulation computed exact crossover points:

BPSK and QPSK are identical in BER performance. QPSK carries twice the data at zero BER cost. This is why QPSK is the default choice in most 6G baseline systems.

16QAM needs 6.8 dB more SNR than QPSK to achieve the same BER. You pay 6.8 dB of signal strength to double your data rate again.

64QAM needs 5.5 dB more SNR than 16QAM to achieve the same BER. Another 5.5 dB for 50% more bits per symbol.

This is the tradeoff every 6G system designer navigates daily. Strong signal environment — use 64QAM, maximize throughput. Weak signal or edge of cell — fall back to QPSK, maintain reliability.

The Curl Test Result

{
  "snr_db": [-5.0, -4.39, ..., 25.0],
  "bpsk":  [0.08259, 0.07185, ..., 1e-07],
  "qpsk":  [0.08259, 0.07185, ..., 1e-07],
  "qam16": [0.18029, 0.17094, ..., 1e-07],
  "qam64": [0.20760, 0.20152, ..., 1e-07],
  "crossover_points": {
    "bpsk_qpsk_same": true,
    "qpsk_advantage_over_16qam_at_snr": 6.8,
    "qam16_advantage_over_64qam_at_snr": 5.5
  }
}

50 SNR points. All four modulations. Crossover points computed automatically.

What Changed Across the Stack

Python Bridge

• New file: modulation_comparison.py

• erfc equations for all four modulations simultaneously

• Automatic crossover point detection

• New endpoint: POST /simulate/modulation-comparison

Java Spring Boot

• ModulationComparisonRequestDto and ResultDto

• New columns on SimulationResult entity

• simulation_type = MOD_COMPARISON

• New endpoint: POST /api/simulations/modulation-comparison

Angular 17

• Third tab added to dashboard: Modulation Comparison

• Four colored lines on logarithmic Chart.js chart

• Insight cards showing crossover points dynamically

• Orange history badge: Mod. Compare

The Dashboard Now Has Three Complete Simulation Types

Tab 1 — BER vs SNR: Real AWGN + Monte Carlo. Theoretical and simulated curves. Single modulation deep dive.

Tab 2 — Beam Pattern: Real ULA antenna math. Polar chart. 8 to 64 antenna elements. 28 to 77 GHz.

Tab 3 — Modulation Comparison: All four modulations simultaneously. Crossover points. Spectral efficiency tradeoff visible instantly.

All three save to PostgreSQL. All three generate shareable links. All three show in history with color coded badges.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

1. Login and click the Modulation Comparison tab

2. Set SNR range from -5 to 25 dB

3. Click Compare All Modulations

4. Watch four curves appear simultaneously

5. Read the insight cards below the chart

6. Share the result with one public link

Tech Stack

Python 3.10 · NumPy · SciPy · FastAPI · Java 17 · Spring Boot 3 · PostgreSQL · Angular 17 · Chart.js · Railway · Vercel

What's Next — Day 14

Dashboard UI polish. Loading states, error handling, empty states, mobile responsive layout. The features are complete — now we make the experience feel production quality for every user who lands on the site.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak

A polar antenna beam pattern chart. 16-element ULA. 8° main lobe. -13.15 dB side lobe level. Real antenna mathematics running in your browser.

Quick Links

🔗 Live Demo: https://sionna-visualizer.vercel.app 🐙 GitHub: https://github.com/Vinu2111/sionna-visualizer 📖 Full Series: vinayak6g.hashnode.dev

What Is a Beam Pattern — Plain English

In 4G networks, antennas broadcast signal in all directions equally — like a light bulb. Every device nearby gets signal regardless of where it is.

In 6G networks, antennas are smarter. They focus signal energy in a specific direction — like a flashlight. This is called beamforming. The antenna knows where you are and points its signal directly at you.

A beam pattern chart shows this. It is a polar chart — circular — where the angle represents direction in space and the radius represents signal strength in that direction. The sharp peak in the center is the main lobe — where the antenna is pointing. The smaller peaks around it are side lobes — unavoidable signal leakage in other directions.

This chart appears in virtually every 6G and 5G research paper ever published. It is one of the most recognizable visualizations in wireless communications.

Today I added it to Sionna Visualizer.

The Math — Uniform Linear Array

The simulation uses the Uniform Linear Array (ULA) model — the standard antenna model in 6G research.

The Array Factor formula:

AF(θ) = |Σ exp(j × 2π × n × d × sin(θ) / λ)| for n = 0 to N-1

Where:

• N = number of antenna elements

• d = spacing between elements (in wavelengths)

• θ = angle in radians

• λ = wavelength at the carrier frequency

The result is normalized to 0 dB at the peak and converted to dB scale. Side lobes appear naturally from the mathematics — they are not added artificially.

The Curl Test Result

16 antennas. 15° steering angle. 28 GHz (mmWave 6G).

{
  "steering_angle": 15.0,
  "num_antennas": 16,
  "frequency_ghz": 28.0,
  "main_lobe_width": 8.0,
  "side_lobe_level": -13.15,
  "array_gain_db": 12.04
}

Three numbers that validate the simulation is correct:

Main lobe width: 8.0° — a 16-element ULA at 28 GHz produces approximately 6-8° beamwidth. This is correct.

Side lobe level: -13.15 dB — this is the famous -13.26 dB first side lobe of a uniform aperture, slightly shifted by the steering angle. Any RF engineer will recognize this number immediately.

Array gain: 12.04 dB — exactly 10×log10(16) = 12.04 dB. Perfect.

What Changed Across the Stack

Python Bridge

• New file: beam_pattern.py — ULA Array Factor computation

• 181 angle points from -90° to 90°

• Accurate 3dB beamwidth detection

• Side lobe masking to find true SLL

• New endpoint: POST /simulate/beam-pattern

Java Spring Boot

• BeamPatternRequestDto and BeamPatternResultDto

• 8 new columns on SimulationResult entity

• simulation_type field — BER_SNR or BEAM_PATTERN

• New endpoint: POST /api/simulations/beam-pattern

Angular 17

• Dashboard now has two tabs — BER vs SNR and Beam Pattern

• Polar Chart.js radar chart with -40 to 0 dB range

• Teal fill with rgba(100, 255, 218, 0.1) glow

• Parameters: antenna count, steering angle, frequency, spacing

• Metrics cards: main lobe width, side lobe level, array gain

• History page now shows type badges — teal for BER/SNR, purple for Beam Pattern

The Dashboard Now Has Two Complete Simulation Types

Tab 1 — BER vs SNR: real AWGN simulation, theoretical + Monte Carlo curves, BPSK/QPSK/16QAM/64QAM

Tab 2 — Beam Pattern: real ULA simulation, polar chart, 8/16/32/64 antenna elements, 28/39/60/77 GHz

Both save to PostgreSQL. Both generate shareable public links. Both show in history with type badges.

Try It Right Now

🔗 https://sionna-visualizer.vercel.app

1. Login to your account

2. Click the Beam Pattern tab

3. Set antennas to 32, steering angle to 30°, frequency to 28 GHz

4. Click Run

5. Watch a real ULA beam pattern render

6. Change antennas to 8 — watch the beam widen

7. Change to 64 — watch it sharpen to a razor

Tech Stack

Python 3.10 · NumPy · FastAPI · Java 17 · Spring Boot 3 · PostgreSQL · Angular 17 · Chart.js · Railway · Vercel

What's Next — Day 13

Multiple modulation comparison. Run BPSK, QPSK, 16QAM, and 64QAM simultaneously and compare all four BER curves on one chart. This is the visualization researchers use when choosing which modulation scheme to use for a given SNR target.

Building Sionna Visualizer in public — 2 hours/day. Follow the full journey at vinayak6g.hashnode.dev GitHub: github.com/Vinu2111/sionna-visualizer Twitter: @gote_vinayak