What's new
By:
Filters

Help with Namco Steering Force Feedback Board (WMMT1/2 and Mario Kart 1/2)

I'm really not sure what to expect for behavior from this FFB board since I don't have everything set up. A test I did was to take gears and the pot off of one of my OR2SP wheels and attach a gear to the DC motor for the Namco board and hold the pot gear up to that during self test. When doing this, if I had the pot held the wrong way, the self test would spin the motor indefinitely, not caring that it was changing pot values (I guess the pot was going the wrong direction). If I flipped the pot over and tried again, it would barely move it and stop the test with success (I assume). However, at no point during the game does it seem to move the motor. I'm not sure since I have to manually hold the pot up to the motor if I'm missing some step where the motor moves and doesn't register pot movement so kills the motor, but I'm a little put off of wanting to go through the trouble of mounting this motor if this is the result I'll get in the end. On top of that, the belt for the OR2SP wheel seems like it's probably too wide for the gear that's on the DC motor currently, so may not even be a good option, assuming I can't transfer the gear from the Sega motor which looks like it has a thicker shaft.

I'm going to see if I can source a wheel assembly that is for this kind of motor and test further with that.
 
i googled for or2sp and it's original driver bd is different. and i also read somewhere this sega driver bd is actually at rs422(?) level. would you mind check that in the host?

also there's possibility the command is different. i don't test anything today yet. maybe tomorrow. will try to record all of comms.
if you can, please log all commands you can get, after you verify if it is at 232 or 422 level.
 
Dion said:
i googled for or2sp and it's original driver bd is different. and i also read somewhere this sega driver bd is actually at rs422(?) level. would you mind check that in the host?

also there's possibility the command is different. i don't test anything today yet. maybe tomorrow. will try to record all of comms.
if you can, please log all commands you can get, after you verify if it is at 232 or 422 level.
Click to expand...
I haven't done any monitoring of the Sega FFB used in OR2SP. I believe it's RS-422 based on the wiring, but don't currently have any RS-422 capable sniffing hardware.

For the record, the Sega FFB connects to a different header than the Namco one.

When I was referring to testing, I meant I was testing the Namco FFB for WMMT.

One way I can make some sense of the communication is when I initialize the values in the test menu for the analogue controls.

The Namco board sends a lot of small strings in response to commands that just seem to be related to wheel position/pot values:
All the way left: 48 00 8B
9 o'clock: 48 01 00
Centered (12 o'clock): 48 01 F1
3 o'clock: 48 02 FB
All the way right: 48 03 65

So the commands from the game/Chihiro during these are like the following (though doing the same test in the same position doesn't yield these same results each time).
All the way left: FF FF C7 01 00 00 00 00 00 00
9 o'clock: FF FF BF 00 00 00 00 00 00 00
Centered (12 o'clock): FF FF 08 01 00 00 00 00 00 00
3 o'clock: FF FF 2D 02 00 00 00 00 00 00
All the way right: FF FF 3D 03 00 00 00 00 00 00

I'm not sure why the game has to send any commands during initialization, though, and why they would have different values.

I haven't wired up for live 2-way monitoring yet to be able to see a proper log of back and forth communication.
 
that's wierd. if sega ffb use 422 level, and it is chihiro based, then how can it be compatible with 232, even if you're running different game (WMMT), but the hardware itself(chihiro) should have a 422 serial converter chip.

btw, i also just have 1 way monitoring.
 
Dion said:
that's wierd. if sega ffb use 422 level, and it is chihiro based, then how can it be compatible with 232, even if you're running different game (WMMT), but the hardware itself(chihiro) should have a 422 serial converter chip.
Click to expand...
I edited this into my last post, so not sure if you saw:
winteriscoming said:
For the record, the Sega FFB connects to a different header than the Namco one.
Click to expand...
The card r/w unit connects to the same header as the Namco FFB, and for sure uses RS-232. I would assume the header for Sega FFB goes to other hardware on the motherboard that is capable of another standard.
 
sorry, got confused.
you're running WMMT game on chihiro, right?
how do you connect the serial line of namco driver to chihiro?
 
Some random commands I get from the game when I assume the motor should be moving the wheel (however I'm never getting motor movement in game in my setup where the motor is on the ground not driving a pot).

During selection in the menu during new game when I assume the FFB would be trying to center the wheel, and I didn't really move the wheel... just selected what was highlighted by default.
FF FF FB 01 04 00 02 00 00 00
FF FF FB 01 0C 00 0A 00 00 00
FF FF FB 01 10 00 0E 00 00 00
FF FF FB 01 64 00 56 00 00 00
FF FF FB 01 7F 00 72 00 00 00
FF FF FB 01 7F 00 7F 00 00 00

During the beginning of a race when I also assume it's generally trying to center the wheel:
FF FF FB 01 60 00 7E 00 00 00
FF FF F9 01 50 00 7E 00 00 00

I might have been hitting the wall during these:
FF FF CF 01 40 00 7E 00 81 00 (this one has a byte populated where the others don't)
FF FF C9 01 40 00 3E 00 81 00

As far as I can tell, the FFB just responds with position, so the only thing we have to decode is the command protocol.
 
Dion said:
sorry, got confused.
you're running WMMT game on chihiro, right?
how do you connect the serial line of namco driver to chihiro?
Click to expand...
Yes, I'm currently testing with MAXIMUM TUNE ver .B (according to system menu) on Chihiro.

J104 (pins 2-4) from the Namco board connects to CN5 (pins 1-3) on the Chihiro. I made my own wiring adapters for it.
 
winteriscoming said:
Some random commands I get from the game when I assume the motor should be moving the wheel (however I'm never getting motor movement in game in my setup where the motor is on the ground not driving a pot).

During selection in the menu during new game when I assume the FFB would be trying to center the wheel, and I didn't really move the wheel... just selected what was highlighted by default.
FF FF FB 01 04 00 02 00 00 00
FF FF FB 01 0C 00 0A 00 00 00
FF FF FB 01 10 00 0E 00 00 00
FF FF FB 01 64 00 56 00 00 00
FF FF FB 01 7F 00 72 00 00 00
FF FF FB 01 7F 00 7F 00 00 00

During the beginning of a race when I also assume it's generally trying to center the wheel:
FF FF FB 01 60 00 7E 00 00 00
FF FF F9 01 50 00 7E 00 00 00

I might have been hitting the wall during these:
FF FF CF 01 40 00 7E 00 81 00 (this one has a byte populated where the others don't)
FF FF C9 01 40 00 3E 00 81 00

As far as I can tell, the FFB just responds with position, so the only thing we have to decode is the command protocol.
Click to expand...
if i were correctly guess, the fifth and seventh byte value are motor force direction.
 
I ordered a used steering assembly with belt that I think is compatible with the DC motor and mount that I have, so hopefully I can do some better WMMT FFB testing without modifying any of my stock OR2SP parts.
 
this is log when insert coin and game start (the steering wheel start activated).
this is log when i hit walls.

so i try control both serial line by pc. and manually grounding the power pin at start up, release the pin. send command (ff ff e4 01 3f 00 3f 00 00 00), it answered with pot position, but the wheel did not activated at all. ok, that's the same situation as yours.

then... i remember that while the wheel activated using original serial line, the red led is off. so i try to send the command from early command(i.e. ff ff fb 01 04 00 04 00 00 00) but no luck too. the red led won't go off, and the wheel not activated.


so then it hit me, that power pin. i should have known that. the "power" word means power of the wheel. so i ground it again, and it works! the red led goes off. the wheel activated. i did not notice this because i sniff incoming command only, if i sniff the receiving channel, then i will notice it would send "C01C01" which means power on.

i test again for sure. so the power pin first need to grounded (passing self check) then it must be released after (because if not, the driver didn't respond to any command). and after that, when the game start, it should be grounded again, so the wheel can be activated.
 
Dion said:
this is log when insert coin and game start (the steering wheel start activated).
this is log when i hit walls.

so i try control both serial line by pc. and manually grounding the power pin at start up, release the pin. send command (ff ff e4 01 3f 00 3f 00 00 00), it answered with pot position, but the wheel did not activated at all. ok, that's the same situation as yours.

then... i remember that while the wheel activated using original serial line, the red led is off. so i try to send the command from early command(i.e. ff ff fb 01 04 00 04 00 00 00) but no luck too. the red led won't go off, and the wheel not activated.


so then it hit me, that power pin. i should have known that. the "power" word means power of the wheel. so i ground it again, and it works! the red led goes off. the wheel activated. i did not notice this because i sniff incoming command only, if i sniff the receiving channel, then i will notice it would send "C01C01" which means power on.

i test again for sure. so the power pin first need to grounded (passing self check) then it must be released after (because if not, the driver didn't respond to any command). and after that, when the game start, it should be grounded again, so the wheel can be activated.
Click to expand...
That accursed POWER pin!!!! :P

Ok, so I'm able to get through self test and then ground the pin again and then boot game and the motor now spins! This is with the motor just sitting on the ground. I pretty quickly get error E07 (not sure off hand what that error is) during the selection process for new game. It does stop spinning when I center the wheel and then spins with different intensity levels as I move off center, but then gives the errror. I'd guess it's spinning too much and the pot value isn't changing enough so it gives up.

EDIT: Per the manual, E07 is potentiometer error. The suggested action is "Replace the potentiometer". :P - So my guess is that since the motor isn't controlling my wheel, it senses that as a pot issue.
 
Last edited:
about the error number. i forgot to mention, that actually i get it from the binary strings you posted. they're actually in order, as follow :

E00 = NO ERROR
START
E01 = OVER FLOW ERROR
E02 = OVER RUN ERROR
E03 = FRAMING ERROR
E04 = PARITY ERROR
E05 = RAM ERROR
E07 = VOLUME ERROR (HARD)
E08 = OVER CURRENT ERROR (HARD)
E10 = VOLUME ERROR
E11 = OVER SPEED ERROR
E12 = MOTOR CURRENT ERROR
E13 = CURRENT SENSOR ERROR
E14 = POWER ERROR
E15 = WATCH DOG ERROR
C01 = POWER ON
C06 = POWER OFF

that's where i knew C01C01 and C06C06 means.
 
I tried WMMT2 and consistently get a wheel error E20 which is the same it gives if nothing is plugged up, even when following the same process that works in WMMT1. The board is giving the same replies for both games, so maybe WMMT2 expects something different.
 
winteriscoming said:
I tried WMMT2 and consistently get a wheel error E20 which is the same it gives if nothing is plugged up, even when following the same process that works in WMMT1. The board is giving the same replies for both games, so maybe WMMT2 expects something different.
Click to expand...
have you try to turn on dipsw3? it just might spit out what the error is.
 
I believe the E20 error is generated by the game, not the board. I can't get that far with DIP3 on since it doesn't accept commands and causes the game to result in E20 in that case, too. I believe E20 is the generic error that the game isn't receiving what it expects (either board isn't present at all or not replying correctly).
 
Interesting discovery: put the board where it is ready for commands and you can send it just one command that it will keep until you send another. You don't have to spam it with commands.

I sent one of the commands from my log and it's been sitting for about 5 minutes with no other commands and it still reacts the same and spins when I turn the wheel off center.

This means the protocol can be decoded much easier with this type of testing. Enter a command and see what the reaction is. Take your time and send another.
 
This kind of testing will be easier in a setup where the motor is mounted to actually control the wheel, but I figured out some of the protocol:

Bytes 3 and 4 specify the position the wheel needs to move to. Any movement one way or the other from that spot and the motor moves in the appropriate direction to try to move the wheel back.

The board seems to ignore commands if you specify the next point too far away from the current point. So you have to send sequential commands to move the goal point further off center.

Center is around F5 01 (for me).

Decrease the F5 to move the wheel left of center and establish a position it needs to try to move to. So F5 01 for center, D0 01 for slightly left of center decremented to 00 01 for leftmost position.

To move right of center, starting at center F5 01, swap 01 to 02 and F5 with 00 and increment 00 to establish a position to move to. So 00 02 for center, 20 02 for slightly right of center incremented to FF 02 for the rightmost position.

Without actually having a controlled wheel to feel, I can't figure out the what the intensity bytes are doing very well and why there are 2. Maybe it's establishing intensity for moving left and right separately?
 
Hmm, commands I'm seeing from WMMT1 in game, while faking the reply, don't seem to be consistent with my findings. It's changing up bytes 3 and 4 differently. I'll have to try to send similar commands to my board and see if I can figure them out.

One thing I think I'm discovering is that the game doesn't care what position the board replies with. I'm faking it with my PC and keep sending it the center position and the game still issues commands based on what's happening in the race. I suspect it's only monitoring the pot via JVS I/O.
 
Last edited:
You must log in or register to reply here.
Back
Top