ESP32-C6 Wi-Fi Logger with Browser GPS + Heat Map Dashboard

This project is an ESP-IDF firmware for the Seeed Studio XIAO ESP32-C6 that turns the board into a self-hosted, secure Wi-Fi scanning logger. It creates its own access point, serves a responsive HTTPS web UI, logs nearby Wi-Fi access points, optionally tags rows with GPS coordinates (provided by the client browser), and exposes battery status from the on-board LiPo input.

The end result is a pocket Wi-Fi “survey” tool: scan, track, export logs as CSV, and generate a heat map view to visualize RSSI vs location.

Project overview and feature set: :contentReference[oaicite:1]{index=1}

What it does

• AP + Station mode so the device can serve the dashboard while scanning nearby Wi-Fi networks.
• HTTPS web interface using a bundled certificate/key for local secure access.
• Single scan and continuous tracking modes.
• CSV export for analysis and archiving.
• Persistent logging to SPIFFS at /spiffs/logs.csv.
• Battery monitoring via ADC with voltage/percentage/status shown on the dashboard.
• Heat map generation (Leaflet-based) to visualize logged RSSI data.

Feature list: :contentReference[oaicite:2]{index=2}

How “GPS” works in this project

This is an important implementation detail: GPS coordinates are captured via the client browser (phone/laptop) when you open the dashboard and grant location permissions. Those coordinates are then attached to scan rows so they can be plotted later.

Web UI usage steps (including location permission): :contentReference[oaicite:3]{index=3}

Hardware notes

• Target board: Seeed Studio XIAO ESP32-C6 (or compatible ESP32-C6 module).
• Battery sense: LiPo input is read via ADC1 channel 0 (GPIO0) through a divider matching VOLTAGE_DIVIDER_RATIO (default 2:1).
• Optional external antenna control: GPIO14 (configured in init_wifi_ap).

Hardware section: :contentReference[oaicite:4]{index=4}

Build & flash (ESP-IDF)

The repo targets ESP-IDF v5.5 (or the matching version referenced by the project). On Windows, initialize the ESP-IDF environment first (e.g., run export.ps1 from your ESP-IDF install).

Prerequisites and environment notes: :contentReference[oaicite:5]{index=5}

idf.py build
idf.py -p COM6 flash
idf.py -p COM6 monitor

Replace COM6 with the serial port on your machine. Use Ctrl+] to exit monitor.

Build/flash/monitor commands: :contentReference[oaicite:6]{index=6}

Using the web UI

1. Power the device and connect to the Wi-Fi network XIAO-Logger (default password: ChangeMe123).
2. Browse to https://192.168.4.1/ and accept the self-signed certificate warning.
3. Grant Location permission in your browser if you want GPS-tagged scan rows.
4. Use Single Scan for a one-time snapshot, or Start Tracking to log continuously.
5. Use Download CSV to export logs (or Clear to reset).

Web UI workflow and defaults: :contentReference[oaicite:7]{index=7}

Battery telemetry

The dashboard’s Battery card shows live voltage, percentage, and status. Per the implementation notes, the UI refreshes battery info periodically from the device endpoint.

Battery update behavior: :contentReference[oaicite:8]{index=8}

Heat map workflow (why internet is required)

Heat map rendering uses Leaflet libraries that load from a CDN. That means you typically need an internet connection at the moment you generate the map. A practical workflow is:

1. While connected to XIAO-Logger, run scans so the log includes GPS-tagged rows.
2. Stop tracking (if active) and disconnect from the logger network.
3. Connect your phone/laptop to the internet (cellular or another Wi-Fi).
4. Revisit https://192.168.4.1/; when the map libraries are available, return to the logger LAN as needed.
5. Press Generate Heat Map. If CDN loading fails, the UI prompts you to reconnect to the internet and retry.

Heat map workflow notes: :contentReference[oaicite:9]{index=9}

Data storage and endpoints

• Logs append to /spiffs/logs.csv (SPIFFS partition).
• /download streams the current log file.
• /clear clears the log contents.

Storage and endpoints: :contentReference[oaicite:10]{index=10}

Customization

• Wi-Fi SSID/password: edit main/main.c (WIFI_SSID, WIFI_PASSWORD), rebuild, and flash.
• Battery calibration: adjust VOLTAGE_DIVIDER_RATIO (and ADC definitions) if your hardware divider differs.
• TLS certificate/key: replace cert.pem and key.pem and rebuild (embedded via EMBED_TXTFILES).

Customization section: :contentReference[oaicite:11]{index=11}

Security and privacy notes

• The dashboard uses HTTPS with a self-signed certificate, so browsers will show a warning the first time. This is expected for local-only devices.
• GPS is collected only if the user grants browser permission; treat your exported CSV as sensitive if it includes location traces.

Source code

GitHub: https://github.com/error0327/ESP32-C6-WifiGPS-HeatMap

License

MIT License (with additional third-party licenses inherited via ESP-IDF and managed_components).

License note: :contentReference[oaicite:12]{index=12}

---

Suggested Blogger labels: ESP32-C6, ESP-IDF, XIAO, WiFi, GPS, Heatmap, Leaflet, IoT

Meta description: ESP32-C6 Wi-Fi scanning logger with HTTPS dashboard, browser GPS tagging, SPIFFS CSV export, battery telemetry, and Leaflet heat map visualization.

M5Stick-C Wi-Fi Spectrum Explorer (and SSID Tracker)

I built a small firmware project for the M5Stick-C that continuously scans the 2.4 GHz Wi-Fi band, visualizes channel congestion as a histogram, and lets you drill into the strongest nearby networks (SSID, RSSI, channel). There’s also a lightweight tracking mode that estimates distance to a selected SSID using RSSI.

Pocket-sized Wi-Fi visibility: quick scans and a clear spectrum view on the M5Stick-C.

What it does

• Periodic active scans of nearby Wi-Fi networks across channels 1–13.
• Histogram “spectrum” view showing how congested each channel is.
• Detail view listing the strongest networks with RSSI (dBm) and channel.
• Manual rescan on demand.
• Battery indicator with live percentage on screen.
• Tracking mode: lock onto an SSID and display RSSI + estimated distance.

Spectrum view (channel congestion)

The default screen is a simple histogram across channels 1–13. It gives an at-a-glance picture of where the band is crowded, so you can quickly spot quieter channels.

Spectrum view: channel congestion histogram (2.4 GHz, channels 1–13).

Detail view (SSID / RSSI / channel)

Press Button A to open the network list. Scanning pauses so the list stays stable while browsing. The firmware shows the strongest networks with RSSI (dBm) and channel.

Detail view: strongest SSIDs with RSSI (dBm) and channel.

Tracking mode (follow a selected SSID)

From the detail list, long-press Button B to lock onto the highlighted SSID and enter tracking. This view refreshes faster and shows the current RSSI plus an estimated distance.

Tracking view: live RSSI updates + distance estimate for the selected SSID.

Build & flash (PlatformIO)

python -m platformio run
python -m platformio run --target upload

Source code

GitHub: https://github.com/error0327/M5STICK-C-Wifi-Tracker

---

Suggested Blogger labels: ESP32, M5StickC, PlatformIO, WiFi, IoT, Embedded, Maker

Evolving Security Practices: Embracing DevSecOps in 2023

Introduction:

 

In the ever-changing landscape of technology, cybersecurity remains a critical concern for

organizations across industries. The need for robust security measures has given rise to the

concept of DevSecOps – an approach that integrates security practices into the entire

software development lifecycle. As we step into 2023, DevSecOps has become a pivotal

strategy for organizations to ensure the security and reliability of their digital products

and services. This article explores the significance of DevSecOps and the key developments

in its implementation in 2023.

 

The Evolution of DevSecOps:

 

DevSecOps is an extension of the DevOps methodology, which emphasizes collaboration and integration

between development, operations, and other cross-functional teams. In the past, security was often an afterthought

in the software development process, leading to vulnerabilities and delays in addressing security issues. However,

with the rise in cyber threats and data breaches, organizations recognized the need to integrate security practices

seamlessly into the development pipeline.

 

In 2023, DevSecOps has gained significant traction as organizations understand the importance of proactive

security measures. It has transformed from a buzzword to a fundamental approach for building secure and

resilient software. Instead of treating security as a separate phase, DevSecOps advocates for security to be

embedded into every step of the software development process, from planning and coding to testing and deployment.

 

Key Elements of DevSecOps in 2023:

 

1. Shift-Left Approach: In DevSecOps, security considerations are moved earlier in the development process,

aligning with the "shift-left" principle. This approach ensures that security practices, such as code analysis,

vulnerability scanning, and threat modelling, are incorporated from the initial stages of development.

By catching vulnerabilities early on, organizations can reduce the risk of potential security breaches.

 

2. Automation and Continuous Security: Automation plays a vital role in DevSecOps. Organizations leverage

automation tools and techniques to enforce security policies, perform continuous security testing,

and monitor the infrastructure. Automated security scans, code reviews, and vulnerability assessments enable

developers to identify and address security issues promptly, reducing the time-to-resolution and enhancing overall security posture.

 

3. Collaboration and Shared Responsibility: DevSecOps fosters a culture of collaboration among developers,

operations teams, and security professionals. It promotes shared responsibility for security,

breaking down silos and ensuring that security measures are integrated at each stage of the

development pipeline. Security experts work closely with development teams, providing guidance

and implementing secure coding practices.

 

4. Containerization and Microservices Security: With the widespread adoption of containerization

and microservices architectures, DevSecOps focuses on securing these modern environments.

Organizations implement security measures specific to containerization technologies, such as

Docker and Kubernetes, to ensure the integrity and isolation of containerized applications.

Microservices security involves securing individual services, implementing strong authentication

and authorization mechanisms, and monitoring service interactions.

 

Benefits and Challenges of DevSecOps:

 

Implementing DevSecOps practices brings numerous benefits to organizations.

By integrating security from the outset, organizations can reduce the risk of security

breaches, comply with regulations, and protect sensitive data. DevSecOps also enables

faster and more reliable software releases, as security issues are detected and resolved

earlier in the development cycle. Additionally, the collaborative nature of DevSecOps

enhances communication and knowledge sharing among teams.

 

However, implementing DevSecOps is not without challenges. Organizations may face

cultural resistance to change, where security and development teams need to align their

processes and mindset. Skill gaps in security expertise can pose hurdles, requiring organizations

to invest in training and upskilling their workforce. Furthermore, selecting and integrating the

right security tools and technologies is crucial for an effective DevSecOps implementation.

 

Conclusion:

 

As cyber threats continue to evolve, organizations must prioritize security throughout the software development lifecycle. Dev

 

Kubernetes Ingress with Nginx Example

What is an Ingress?

In Kubernetes, an Ingress is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. You configure access by creating a collection of rules that define which inbound connections reach which services.

This lets you consolidate your routing rules into a single resource. For example, you might want to send requests to example.com/api/v1/ to an api-v1 service, and requests to example.com/api/v2/ to the api-v2 service. With an Ingress, you can easily set this up without creating a bunch of LoadBalancers or exposing each service on the Node.

Which leads us to the next point…

Kubernetes Ingress vs LoadBalancer vs NodePort

These options all do the same thing. They let you expose a service to external network requests. They let you send a request from outside the Kubernetes cluster to a service inside the cluster.

NodePort

NodePort is a configuration setting you declare in a service’s YAML. Set the service spec’s type to NodePort. Then, Kubernetes will allocate a specific port on each Node to that service, and any request to your cluster on that port gets forwarded to the service.

This is cool and easy, it’s just not super robust. You don’t know what port your service is going to be allocated, and the port might get re-allocated at some point.

LoadBalancer

You can set a service to be of type LoadBalancer the same way you’d set NodePort— specify the type property in the service’s YAML. There needs to be some external load balancer functionality in the cluster, typically implemented by a cloud provider.

This is typically heavily dependent on the cloud provider—GKE creates a Network Load Balancer with an IP address that you can use to access your service.

Every time you want to expose a service to the outside world, you have to create a new LoadBalancer and get an IP address.

Ingress

NodePort and LoadBalancer let you expose a service by specifying that value in the service’s type. Ingress, on the other hand, is a completely independent resource to your service. You declare, create and destroy it separately to your services.

This makes it decoupled and isolated from the services you want to expose. It also helps you to consolidate routing rules into one place.

The one downside is that you need to configure an Ingress Controller for your cluster. But that’s pretty easy—in this example, we’ll use the Nginx Ingress Controller.

How to Use Nginx Ingress Controller

Assuming you have Kubernetes and Minikube (or Docker for Mac) installed, follow these steps to set up the Nginx Ingress Controller on your local Minikube cluster.

Installation Guide

1. Start by creating the “mandatory” resources for Nginx Ingress in your cluster.

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml

2. Then, enable the ingress add-on for Minikube.

   minikube addons enable ingress

3. Or, if you’re using Docker for Mac to run Kubernetes instead of Minikube.

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

4. Check that it’s all set up correctly.

   kubectl get pods --all-namespaces -l app=ingress-nginx

This has set up the Nginx Ingress Controller. Now, we can create Ingress resources in our Kubernetes cluster and route external requests to our services. Let’s do that.

Creating a Kubernetes Ingress

First, let’s create two services to demonstrate how the Ingress routes our request. We’ll run two web applications that output a slightly different response.

	kind: Pod
	apiVersion: v1
	metadata:
	name: apple-app
	labels:
	app: apple
	spec:
	containers:
	- name: apple-app
	image: hashicorp/http-echo
	args:
	- "-text=apple"
	---
	kind: Service
	apiVersion: v1
	metadata:
	name: apple-service
	spec:
	selector:
	app: apple
	ports:
	- port: 5678 # Default port for image

view rawapple.yaml hosted with ❤ by GitHub

	kind: Pod
	apiVersion: v1
	metadata:
	name: banana-app
	labels:
	app: banana
	spec:
	containers:
	- name: banana-app
	image: hashicorp/http-echo
	args:
	- "-text=banana"
	---
	kind: Service
	apiVersion: v1
	metadata:
	name: banana-service
	spec:
	selector:
	app: banana
	ports:
	- port: 5678 # Default port for image

view rawbanana.yaml hosted with ❤ by GitHub

Create the resources

$ kubectl apply -f apple.yaml
 $ kubectl apply -f banana.yaml

Now, declare an Ingress to route requests to /apple to the first service, and requests to /banana to second service. Check out the Ingress’ rules field that declares how requests are passed along.

	apiVersion: extensions/v1beta1
	kind: Ingress
	metadata:
	name: example-ingress
	annotations:
	ingress.kubernetes.io/rewrite-target: /
	spec:
	rules:
	- http:
	paths:
	- path: /apple
	backend:
	serviceName: apple-service
	servicePort: 5678
	- path: /banana
	backend:
	serviceName: banana-service
	servicePort: 5678

view rawingress.yaml hosted with ❤ by GitHub

Create the Ingress in the cluster

kubectl create -f ingress.yaml

Perfect! Let’s check that it’s working. If you’re using Minikube, you might need to replace localhost with 192.168.99.100.

$ curl -kL http://localhost/apple
apple

$ curl -kL http://localhost/banana
banana

$ curl -kL http://localhost/notfound
default backend - 404

Summary

A Kubernetes Ingress is a robust way to expose your services outside the cluster. It lets you consolidate your routing rules to a single resource, and gives you powerful options for configuring these rules.

By : https://matthewpalmer.net/