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.
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”.
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.
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.
Thanks for sharing. I want to ask you something: I understand that with IPv6 the idea is that every household receives several of IPv6 addresses so that every single IoT device has their unique IPv6 address and there is no NAT needed.
Would it be possible to use a dozen of IPv6 addresses at the same time? Like send one UDP packet over certain IPv6 interface, next packet over another IPv6 interface, and so on. If both sending and receiving end have access to multiple IPv6 addresses I can see how this significantly increases complexity for tracking.
Could you split up the traffic across dozens or hundreds of IPv6 source addresses?
> Could you split up the traffic across dozens or hundreds of IPv6 source addresses?
Yes
> I can see how this significantly increases complexity for tracking
Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.
If you assign a subnet to a host, or allow the host to claim multiple addresses via ND from the link subnet, then you can use as many addresses as you want. You could give every process on your machine its own IPv6 address for example.
Yes, and if your host has access to several IPv6 addresses and maybe an IPv4 address it'd be nice to have something like wireguard actually utilize all of them in some random order. Same on the receiving end, wireguard server listenes both on IPv4 and IPv6 at same time and internally puts received packets in the proper order.
I feel this would create significant struggles for any surveillance software because most firewalls I know are modeled on a source address / target address basis.
If you have access to enough source IPv6 addresses you might even put your whole wireguard traffic into ICMP packet payload?
The biggest tracking hurdle is to figure out if the ISP that handed out the block of addresses is handing out /64s, /56s, or /48s. The network provided to you is functionally the same as the IP address assigned to you with IPv4.
In theory I could rent an IPv4 /29 (of which 6 addresses are usable) for like 20 euros a month from my home ISP to cause the same confusion but I doubt it'd confuse trackers to use those.
I thought most ISP's give out at least /64's for free these days? Telia gives out a /56, although unfortunately there's no way to migrate them. This was a big deal for my homelab when I was moving, as I had to manually update all prefixes everywhere. A pain in the ass.
ISPs do, cloud providers often give smaller ranges.
Re: renaming all the prefixes, that's why I use a ULA within my home network. Not as useful if you want your services available from the outside if you move ISPs (NAT66 can help on the inside but you'd still need to update all DNS records to use the new prefix). I'll stick with my ULA + VPN fallback for now, I don't expect the prefix to change more than once every five or six years.
If you want a static prefix with a changing prefix, you're probably better off with getting a Hurricane Electric tunnel. Or if you want to go hard on the IPv6 homelab hobby, get your personal IPv6 address space and a bring-your-own-IP business ISP.
By convention they're supposed to DHCP you at least a /64 if not something wider. I don't believe there's any expectation it be static (although it typically is AFAIK) and there are some providers that defy expectations by handing out narrower slices (up to and including /128).
There's totally expectation of it being static, because why wouldn't it? They cut the ranges up at distribution switches and that's it. We're talking about IPv6 after all. There's absolutely zero benefit to dynamically-allocating ranges for ISP's here, in fact that would make things more complicated, and only serve to add additional load to the routing tables.
Networks are supposed to do egress filtering to prevent any packets with fake IPs from ever leaving the network. In practice it's not always so, but it mostly is. So you'd be limited to fake IP addresses in your own network, and doing so might raise alerts depending on the network infrastructure you live in.
Packets with fake source address can easily be spotted, and will raise an alert. In terms of using multiple interfaces for a single service it might be easy to hack together in a python script, but last time I checked the linux kernel support for bundling multiple interfaces is limited to redundancy and failover.
What I'd like to have is a single service dynamically using many network interfaces with randomized packet timings and randomized packet scheduling (5 packets on first interface, pause on 2nd, some on third interface, sometimes send traffic simultaneously).
If you want to hide you need to be in a place where you can do these kinds of stuff. Getting a peering without source filtering is possible, but even getting the simple version might be too hard for most.
While a situation like that is really annoying, I bet it's still generally following the rule of one /64 per network. What you're not getting is control over your IPs on that network.
It is more than convention, the /64 is the minimum allocation to support SLAAC. If you're getting less than a /64 you're not getting full support for IPv6.
Well you're not getting support for SLAAC but I didn't understand that to be a core requirement to qualify as a functional IPv6 implementation.
Regardless, my point is that allocations narrower than /64 exist in the wild for better or worse. So do IPv6 NAT implementations for that matter. If you assume either of those things don't exist then you might be in for a surprise.
I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?
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.
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.