Wavebird Rumble Mod?

[trevor403]

Yes I completely agree. This would be a separate transmitter and receiver mind you for rumble only. The 5v can be taken as a signal from the transmitter side, sent as a signal to a receiver in the wavebird, then on recovering that signal the wavebird closes a connection between a motor and a regulator stepping up the 3V to 5V or we could even use a 3V motor! The point I'm making is that is is possible on account of the fact that rumble is not packed in with the data line.

[trevor403]

As a follow-up, we would fit the rumble and reciever into the wavebird by either franken-casing or replacing the AA batteries with a flat battery and using the extra space for the motor and receiver.

[|RDC|]

The 5v is only 5v. It's power, not any kind of Rumble control signal at all. When the GC is on, there is 5v there, when it's off, it's off, that's all it does.

The Rumble control signal is on the Data line. It's the last bit of the 3 byte command sent to the controller.

[tueidj]

Technically it's at least the last 2 bits.

[|RDC|]

It's the last bit that controls the Rumble, 1 for on, 0 for off.

[tesla246]

Are there not variations in the force of the rumble motor? Sometimes it shakes aggressive, others it rotates at a slower constant rate. Wouldn't that affect the number of bits? Also would modding the standard controller with a wireless receiver/transmitter be a viable option? There may be enough room in the handles amd teh form factor is just that much better. Or would that be too expensive/bothersome/difficult/time-consuming?

[|RDC|]

What about alternating the on/off Rumble bit in a PWM type fashion to lower/raise the motor speed.

Making a new wireless Transmitter/Receiver for the wired controller would also mean designing a way to power it. Be it making a new Transmitter to strip out the Rumble bit and send that to a Receiver in the Wavebird, or designing a new Tx/Rx setup and power supply for the Wired controller to make it wireless, neither of them are a really pleasant option to consider and if either were they would have been done already.

[tueidj]

There's no "strength" setting. It's either on or off (1 or 0) but there's also hard off (2) which makes it stop vibrating instantly instead of gradually slowing.
BTW wavebird controllers use different IDs to regular controllers, games recognize this and know not to send the rumble status. So even after hacking the hardware you'd still need to patch each game...

[tesla246]

Wow, every game needs to be patched? If that is true, wouldn't it be easier to mod the normal controllers with wireless technology? Of course the whole thing needs to be reverse-engineered to accomplish that.

[trevor403]

Wow well this is a huge damper, I've been studying the controller port protocol, and it's actually the last bit in the sequence that tells us if we need rumble. I was going to say we could bug the data line and read the rumble bit but now that I know the controller ID is different that makes things harder. I also take full responsibility for not knowing that the 5v line is always receiving power and the MX chip tells it weather to connect to the rumble or not. Anyways, if we put a patch into swiss (just saying) and have the data line bugged (read only) that could be all we need? We just need an ATMega running at 16Mhz and a logic converter. Hell maybe we could even use a PIC. Anyone think we could brew up a hook for the system and try this out?!

[trevor403]

Also as a reply to what you said tesla246, we already know how the controller works, I'm writing a program on an ATMega to act as a GC controller, and since I'm coding it I can do anything with it, be it wireless rumble or using a toaster as the A button. Anyways I think microcontrollers are way better than modding original hardware.

[trevor403]

also YAGCD mentions that bit 13 of the controller handshake is for Rumble Motor availability, so the console doesn't stop rumble signal using the Wireless identifier, but it stops it using that bit. We can use two bidirectional lines to relay the data line on the Wavebird receiver and to change that bit on the 16 bit controller handshake, then we can read the rumble bit off the gamecube because we are acting as a middle man and send it with some RF device to a motor planted in the wavebird, there solved it! I'm building a proof of concept, waiting for a new logic converter.

[tueidj]

The "controller handshake" that you're talking about IS the controller id. If you change it, the console won't know that the controller is a wavebird and won't initialize the wireless receiver correctly (which involves a lot more than just enabling polling like a regular controller). Don't rely on YAGCD for controllers, it's missing a lot of info and in some cases what little information is present is flat-out wrong. For example if an unset bit 13 meant the controller supports rumble that would mean the GBA, ascii keyboard and Konga controllers support rumble which is obviously wrong.
You're also still ignoring what I said about the motor control being the bottom TWO bits, not just one.

[|RDC|]

I had to dig all of this and the schematic for the wired controller back out and tinker with it again, it's been awhilw. I recall now Q1 being in there paralleled with the motor for a brake, and that all makes sense now as it's controlled by that other bit.

xxxxxx00 = Motor off, no Rumble.
xxxxxx01 = Motor on, Rumble.
xxxxxx10 = Motor Brake on. If the Motor is turned off and the Brake turned on, this makes the Rumble stop quicker by shorting the + and - of the Motor in the controller. If the Motor is not running it does nothing.
xxxxxx11 = Motor on and Brake on. This should not be done as the Motor and Brake are both on in this case. The Motor should be turned off if the Brake is to be applied, ie; 10 should be used.

Going from 01 to 00, the Rumble spins down slowly, makes quite a few revolutions before stopping. Coasting.

Going from 01 to 10, the Rumble stops quicker as the Brake is applied, makes a couple revolutions or less before stopping. Generator with infinite load.

So, only the last bit is necessary to make the Rumble turn on/off. To make the Rumble stop quicker the Brake is necessary, but it has nothing to do with making the Motor run. It should still be taken into account so anything that is done, gets done correctly, as no Brake would make some Rumble events seem much different without it.

[trevor403]

Plans


So pin 7 (it's 2 in the code) on the microcontroller acts as the gamecubes data line. This is a 5v board so I got the logic converter. What order do i wire up pin 7 (actually 2), the logic converter, and the 1KΩ resistor? Tried some different ways but I think my sketch is bad. Will make a github repo.

[trevor403]

My post got deleted but I came to the conclusion the rumble signal inhibition is not decided via controller ID, but rather with a separate bit in the handshake. Even if changing this bit under the Wavebird protocol doesn't work, with a microcontroller, the gamecube can think its talking to a wired controller and we poll and convert in both ways. That would be gamecube to Arduino then over to the wireless receiver and back. Same concept as Gamecube-N64 (poll, decode, re-encode, send) except both sides are gamecube.

[|RDC|]

Power your AT board from the 3.43v (3.3v) of the controller port, it's not a 5v only board, then you can ditch the level converter.

[trevor403]

I would need to swap the crystal to 8Mhz if I wanted to do that, just stuck an LM317 on my breadboard and counted out the resistors to get to 3.43v, soldering on the headers for the logic converter, will have results in an hour or so.

[|RDC|]

In that case, ditch that thing and get yourself a Teensy 3.1 instead. No LM317, no level shifting and you'll really enjoy not having to skirt that 1us issue with a 16MHz setup as you can OC it to 96MHz max.

[trevor403]

You're right the board should be based on 3.3v logic.