Readers who were firmly on Team Nintendo in the early 2000’s or so can tell you that there was no accessory cooler for the Nintendo GameCube than the WaveBird. Previous attempts at wireless game controllers had generally either been sketchy third-party accessories or based around IR, and in both cases the end result was that the thing barely worked. The WaveBird on the other hand was not only an official product by Nintendo, but used 2.4 GHz to communicate with the system. Some concessions had to be made with the WaveBird; it lacked rumble, was a bit heavier than the stock controllers, and required a receiver “dongle”, but on the whole the WaveBird represented the shape of things to come for game controllers.
Given the immense popularity of the WaveBird, [Sam Edwards] was somewhat surprised to find very little information on how the controller actually worked. Looking for a project he could use his HackRF on, [Sam] decided to see if he could figure out how his beloved WaveBird communicated with the GameCube. This moment of curiosity on his part spawned an awesome 8 part series of guides that show the step by step process he used to unlock the wireless protocol of this venerable controller.
Even if you’ve never seen a GameCube or its somewhat pudgy wireless controller, you’re going to want to read though the incredible amount of information [Sam] has compiled in his GitHub repository for this project.
Starting with defining what a signal is to begin with, [Sam] walks the reader though Fourier transforms, the different types of modulations, decoding packets, and making sense of error correction. In the end, [Sam] presents a final summation of the wireless protocol, as well as a simple Python tool that let’s the HackRF impersonate a WaveBird and send button presses and stick inputs to an unmodified GameCube.
This amount of work is usually reserved for those looking to create their own controllers from the ground up, so we appreciate the effort [Sam] has gone through to come up with something that can be used on stock hardware. His research could have very interesting applications in the world of “tool-assisted speedruns” or even automating mindless stat-grinding.
I have 4 of these for the old Gamecube never knew they were called “wavebirds”
Same here.
Really? I mean…it does say “WaveBird” right on the front of the controller.
People ain’t got logic bruh
Its name is a reference to “Dolphin”, the GameCube’s development codename.
I find that hard to believe, considering how big a deal official wireless controllers were at the time. The marketing bombardment for them was pretty significant, atleast in my teenage mind when these were the hot new GC accessory.
love the disclaimer :
It sounds like a pretty dry disclaimer actually. In the US, the DMCA (1998) outlawed copyright circumvention with a few specific exceptions. Copyright law here has been crazy for a long time.
Would love to see the TASBot team use this for some future GDQ TAS blocks.
I can’t even link to wikipedia without my comment getting screened?
Anyway, the 21,31 code is a type of ‘BCH code’. POCSAG also provides the explanation for why the bits are transmitted over the air in “transposed” manner (all the LSbits, then the 2s bits, then the 4s bits)—BCH can only correct 2 bits, so you want to distribute any RF noise over multiple protected words.
Thanks so much for the info! The longest step in this whole thing was trying to figure out what kind of code the FEC was, even after I could successfully decode/reencode it, because I couldn’t find any example of a BCH codeword-message pair anywhere. Even the Wikipedia article on BCH codes has an entirely blank section for encoding. I just had to guess that it was a polynomial-based cyclic code and search the polynomial, which led me to the Wikipedia article on POCSAG (which confirms the code is cyclic, but fails to mention it’s a BCH code).
Good to hear I was correct about the reasoning behind the interleaving though! (You don’t by any chance happen to know why the *CRC* is interleaved, do you? That made no sense to me.)
Beautifully done. Reminds me of my final year project, which involved all that RF protocol jazz (FEC, interleaving, framing, DSSS) on an FPGA. Very impressive detective work there – it is reverse engineering like this that make for great learning experiences!
so pumped for this! I still have my original wavebird, one of the best electrical products I’ve ever owned, which is why I held onto it. What a quality product from Nintendo that never failed me or my brother in many hours of gaming. I still use mine with my PC sometimes through a sketchy chinese game controller adapter.
Are you saying there are other, 3rd party, receivers that connect to the Nintendo Wavebird? I need a receiver!
My favorite controller of all time. Effectively infinite range (a big deal at the time), incredible battery life, 100% reliability. I love this thing.
Nintendo’s controllers have (had) incredible range. I remember testing my Wii’s controller range when I first got it. I managed to get all the way down to the mailbox before it stopped responding.
I don’t know about WiiU or Switch, though.
Wii U is not that great, but that is because it has to be capable of transmitting a video signal reliably between the base unit and the controller. I don’t recall much information of the specifications, but considering this it is likely using 5ghz to keep that transmission speed up at all costs. Noticeably weaker range when I have tested it.
The Wii U’s controller actually runs wifi. There’s a hidden SSID, slightly-off-standard wifi connection from the Wii U to the controller. And the video is slightly-off-standard h.264.
I doubt this will ever be used for TAS, since that relies heavily on frame-perfect inputs, and if the input is off by even one frame at any point or the wrong input is received, it desyncs and screws the whole run, and you simply aren’t guaranteed that kind of precision with wireless technology, which is why error correction is needed in the first place.
Yeah, it was somewhat hopeful thinking to suggest that this might one day be used in a TAS, but I don’t think it can’t be done.
The frame rate of PAL is 25 FPS, while the WaveBird transmission interval is 4ms (frequency of 250 Hz), so that’s 10 (re)transmissions per frame – and my understanding is if any of those 10 gets through, that’s what the WaveBird receiver reports to the game when polled – though note I’m making the assumption that one “game frame” equals one “video frame.” (With NTSC’s higher 29.97 FPS rate, this is only an 8x factor, but still high enough that the probability of a missed frame of input during a <1hr. speedrun is low.)
Were someone to develop a "TASBird" transmitter, they'd probably change the transmit timings slightly – say, for PAL, 3.5ms per WaveBird packet during the middle of a frame and a 2.5ms silent "guard interval" at the beginning and end of each frame to allow for timing error so inputs don't bleed into adjacent frames.
The last challenge is finding the frame boundaries and any clock skew between the physical GameCube and the software playing back the TAS pattern, but this is a problem faced by anybody trying to do a TAS outside of an emulator. My guess is they usually use the controller polling interval to deduce the console framerate, but since there is no "polling" a WaveBird, some ingenuity will be necessary on the part of whoever's doing the TAS, like:
1. Make the TAS so short (e.g. a credits warp) that clock skew won't have time to meaningfully disrupt it.
2. Design the TAS pattern itself to be tolerant of input frames being duplicated/deleted.
3. Monitor the video output (with a webcam, capture card, or specialized microcontroller) to figure out the frame boundaries and keep the TAS transmitter synchronized.
No matter how you slice it, it's kind of a crazy challenge, but the sorts of people who want to do TAS runs on a real console instead of an emulator are also the sort to love these kinds of problems. I'd be up for it myself, but I'd need someone to teach me how to exploit these kinds of glitches. (And I'm more interested in using this as a vector for modding games and loading homebrew without needing to risk damaging the GC hardware.)
Thanks for the awesome tutorial! :) Quality stuff dude!