TheusHen

Hi HN,

This is EEGFrontier V1, an open-source EEG acquisition board I designed as a learning and experimentation project.

The board is built around the ADS1299 (EEG analog front-end) and a Seeed XIAO RP2040. The goal was to design a compact, low-cost board that works with dry electrodes and exposes the full EEG signal chain, from analog front-end to firmware.

I started this project because most affordable EEG devices are either closed-source or abstract away too much of the hardware. I wanted to understand the real constraints involved in EEG design: noise, grounding (REF/BIAS), routing limitations, and what actually happens when theory meets a real PCB.

The repository includes the full KiCad design, firmware, BOM with cost references, and documentation images. This is a V1 board and still evolving. It’s functional, but there are things I already want to improve, especially around shielding and noise mitigation.

This project is primarily educational, but I tried to design it seriously, following datasheets and reference designs while learning where those fall short in practice.

I’m sharing it here to get feedback, criticism, and ideas from people more experienced in EEG, biosignal acquisition, or analog front-end design. Any comments are appreciated.

It's a little expensive too , but I'm applying it at HackClub Blueprint.

Thanks for reading.

I don’t really follow a “standard” education path. I’ve been interested in technology for as long as I can remember and had early access to computers and the internet. I’m about to turn 15 in a few days, and I’ve been programming for almost 6 years now — I started when I was 9.

Most of what I know comes from self-study, experimentation, reading documentation, breaking things, and rebuilding them. I usually learn by doing projects rather than following a fixed curriculum. As for papers, I mostly write by organizing ideas that come to my head and then grounding them with research and practical knowledge. Lately, I’ve been considering writing one about implantable RFID microchips, just to explore the topic more deeply.

Absolutely agreed — and this is an important distinction.

IPv6 gives you global addressability, not guaranteed reachability. Stateful firewalls still exist and inbound-by-default is still rare on consumer networks.

The I6P design explicitly assumes that reality. The motivation for being IPv6-first is not “firewalls disappear”, but that the problem space collapses from many forms of NAT and address/port translation down to mostly predictable stateful filtering.

That’s also why the transport is QUIC/UDP: firewall behavior is far more consistent, hole punching is simpler, and path changes are survivable.

So IPv6 isn’t treated as magic — it’s treated as a cleaner substrate with fewer pathological cases than IPv4 NAT.

Good question — this is probably the most important clarification.

I6P is not trying to replace QUIC or TLS, and it’s not a competing transport. QUIC is the transport.

What I6P provides is a reusable P2P connectivity and transport layer built on top of QUIC, so applications don’t need to re-solve the same problems over and over again:

- Cryptographic peer identity decoupled from IPs - Explicit peer-to-peer session semantics (not client/server) - Built-in chunking, Merkle verification, erasure coding, and resumable transfers - Stream pooling and batching tuned for high-throughput P2P links - Session resumption and 0-RTT specifically for peer reconnections - A clean abstraction boundary so existing apps can integrate without rewriting their logic

You absolutely could build all of this directly on raw QUIC — and many projects do, each in slightly incompatible ways. I6P’s goal is to standardize that layer so P2P apps can focus on application logic instead of reimplementing transport mechanics.

So the niche isn’t “better QUIC”, it’s “QUIC-based P2P without bespoke transport stacks per project”.

Author here.

This article focuses on the transport-layer design, not a torrent client replacement. The goal is to provide a reusable IPv6-native P2P connection layer (QUIC-based, NAT-free) that existing clients or new applications can integrate without touching their higher-level logic.

Feedback on design trade-offs is very welcome.

I built I6P, an IPv6-only P2P connectivity + transport layer in Go. The goal is to simplify P2P by assuming globally routable IPv6 (no NAT traversal), while still providing a solid secure/fast data plane: QUIC over UDP (TLS 1.3), Ed25519 identity binding (PeerID = SHA-256(pubkey)), X25519 + ChaCha20-Poly1305, a symmetric-key ratchet for forward secrecy, plus a transfer pipeline with chunking, Merkle integrity, LZ4 compression, batching, parallel stream pool, and Reed-Solomon erasure coding.