Helped define the technical scope: NOAA signal reception, decoding, simulated network transfer, and security comparison.
SDR NOAA Weather Image Transmission System
Transmission project combining SDR reception, NOAA weather-image decoding, GNS3 network simulation, encrypted transfer, and Wireshark validation.
Key highlights
- Combined radio reception, image decoding, Linux automation, network simulation, and security validation in one end-to-end workflow.
- Moved from GNU Radio to SDR++ when reception quality and noise handling became a practical blocker.
- Used Bash, OpenSSL, SCP, and Wireshark to turn decoded images into a testable secure-transmission workflow.
What I handled
Worked on the collector/server workflow where decoded SatDump images were organized, encrypted, transferred, decrypted, and exposed from a web server path.
Used the project constraints as part of the final explanation instead of hiding them: radio noise, tool choice, and the limits of a lab-grade security setup.
Documented the solution through a final report, cahier des charges, poster, and English extended summary.
Results & evidence
End-to-end workflow
Timeline
Receive and decode
Capture weather satellite signals with RTL-SDR, improve the reception workflow, and decode usable images with SatDump.
Move through the lab network
Use a GNS3-based collector/server environment to transfer the decoded images instead of keeping the work local.
Protect and validate
Encrypt images, transfer them through SCP, decrypt them on the server, and compare traffic visibility with Wireshark.
Overview
This project was a telecom and transmission case study built around weather satellite imagery. The objective was to receive NOAA-style weather signals with an SDR receiver, decode the captured signal into images, then move those images through a simulated network with a security layer.
It is one of the strongest projects for my portfolio because it mixes several domains that usually stay separated in school exercises: radio reception, Linux scripting, network simulation, secure transfer, and technical documentation.
Context
The project started from a simple but demanding goal: capture weather-satellite data, transform it into usable images, and demonstrate how the result could be transferred securely through a network environment.
The project brief included:
- signal reception with SDR hardware
- satellite tracking and decoding workflow
- a simulated infrastructure with GNS3
- a web server to expose the resulting images
- traffic analysis with Wireshark
- comparison between unprotected and protected communication paths
What I worked on
I contributed to the practical workflow that connects the radio part to the network part:
- preparing the SDR reception and decoding workflow
- using SDR++ and SatDump after GNU Radio proved difficult in the noisy environment
- organizing decoded images into clear folders such as APT, AVHRR, and metadata
- scripting image encryption and transfer from a collector machine
- preparing the server-side decryption workflow
- documenting the project through a report, project brief, poster, and English summary
Architecture / approach
The intended pipeline was:
- receive the signal with an RTL-SDR device
- use SDR++ to handle the reception workflow
- decode the signal into images with SatDump
- store the decoded files on a collector VM
- encrypt the images with OpenSSL
- transfer encrypted files to a server through SCP
- decrypt files on the server side
- make the final images available through a web server
- analyze network visibility with Wireshark
This approach made the project more than an SDR demo. It became a complete transmission workflow with networking and security concerns.
Technical decisions
Switching from GNU Radio to SDR++
GNU Radio was explored first, but the reception workflow was difficult to exploit cleanly in the lab conditions. SDR++ gave a more practical interface and made it easier to manage noise and signal visibility.
Keeping the transfer workflow scriptable
The collector/server flow was automated with Bash scripts so the project was easier to repeat and explain. The scripts handled file organization, encryption, transfer, and server-side decryption.
Treating Wireshark as proof, not decoration
Wireshark was not only listed as a tool. It was part of the validation logic: observe what traffic exposes, then compare it with the protected transfer path.
Proof available
The uploaded project archive contains useful proof material:
- cahier des charges
- final report
- poster
- extended English summary
- SDR hardware / software references
I would not publish all raw files directly on the portfolio. The cleaner approach is to publish selected screenshots, diagrams, and sanitized extracts.
Results
The project demonstrates that I can connect telecom experimentation with a network/security workflow. The strongest result is not just a decoded image; it is the ability to explain the chain from signal reception to secured transmission and validation.
Limits and improvements
This was a lab project, not a production-grade satellite receiving station. The main limitations were:
- radio noise and reception quality in the environment
- lab-grade encryption and certificate handling
- simulated network rather than a deployed production infrastructure
- need for cleaner public screenshots before publishing proof assets
Future improvements could include a cleaner web gallery, stronger HTTPS certificate handling, better automated logging, and a clearer comparison dashboard for Wireshark observations.
What this project demonstrates
- telecom curiosity and practical SDR experimentation
- ability to adapt tools when the first approach is not productive
- Linux scripting and automation mindset
- network simulation with GNS3
- security validation through traffic observation
- technical documentation discipline