winteriscoming
Champion
Yeah, that one passes through the analogue voltage to JVS I/O. As long as the board is powered, regardless of self test or error state, JVS I/O sees wheel movement.
- Thread starter winteriscoming
- Start date
more tests.
9th byte = how much pounding force
pounding to left min to max = 0 - 7f
pounding to right min to max = ff - 80
7th byte = undulation force
5th byte = steering/holding force
3-4th byte seems to be destination pot position like you said, but i can't verify. the driver seems act nothing when i changed them, with or without another parameter changed.
9th byte = how much pounding force
pounding to left min to max = 0 - 7f
pounding to right min to max = ff - 80
7th byte = undulation force
5th byte = steering/holding force
3-4th byte seems to be destination pot position like you said, but i can't verify. the driver seems act nothing when i changed them, with or without another parameter changed.
winteriscoming
Champion
Did you try to make small incremental changes to the destination pot position? For me it seemed to ignore commands if I tried to send a value too far away from the current value.
which parameter used when you increment them?
winteriscoming
Champion
I would have had 5 and 7 at something higher than 10 (I don't think I was seeing any movement or very little lower than that), but I think as long as they were set to something noticeable, I was seeing movement.
The important thing might be to start with a center position so whatever your game initially sends. I see this at the beginning of one of your logs:
ff ff ff 01 01 00 01 00 00 00
So maybe send that and then increase 5 and 7 first, just to confirm they're altering anything. I didn't do too many tests with those, so not sure if it expects to increment them slowly or not. Maybe turn the wheel off center to make sure it's forcing the wheel back into the center.
ff ff ff 01 10 00 10 00 00 00
Once you notice it's forcing the wheel into the center, you can leave 5 and 7 the same and try other positions. I would expect the wheel to just move to whatever position without you having to manually turn it, but I don't have a full setup to be able to confirm.
ff ff e0 01 10 00 10 00 00 00
ff ff c0 01 10 00 10 00 00 00
I don't know if it's useful to you. But Bigpanik at Supermodel worked on an model 3 interface board a while ago. He only made it auto center I think. Check his link http://superusr.free.fr/model3.htm . Maybe you might get a piece of the puzzle from it, maybe not 
winteriscoming
Champion
Thanks for sharing, but it looks like a different protocol.I don't know if it's useful to you. But Bigpanik at Supermodel worked on an model 3 interface board a while ago. He only made it auto center I think. Check his link http://superusr.free.fr/model3.htm . Maybe you might get a piece of the puzzle from it, maybe not
In other news: I received my steering assembly yesterday and the DC motor I have mounted right to it. It's still not an ideal setup since I don't have a steering wheel mounted to the shaft, but vice grips should work well enough to get a meaningful log of activity from WMMT.
winteriscoming
Champion
Good news. This FFB board totally works with WMMT2. I think this game just requires the all clear communication back from the board that WWMT1 apparently doesn't care about.
Based on Dion's logs from WMMT3, I suspect this board may be interchangeable among the games.
Anyway, for my purposes the fact that WMMT 1 and 2 use the same protocol is good, because I can use the same solution for both.
Based on Dion's logs from WMMT3, I suspect this board may be interchangeable among the games.
Anyway, for my purposes the fact that WMMT 1 and 2 use the same protocol is good, because I can use the same solution for both.
freddiefiasco
Professional
So instead of the SEGA MIDI FFB, you can swap in the WMMT FFB and all wiring is the same?
winteriscoming
Champion
No, unfortunately the wiring for the 2 FFB units are quite different. The motors are completely different, too, so it's not going to be feasible to swap into a MIDI FFB setup.
The eventual goal to remedy that is going to be coming up with a protocol translator so everything uses MIDI FFB.
The eventual goal to remedy that is going to be coming up with a protocol translator so everything uses MIDI FFB.
freddiefiasco
Professional
Darn. So you would also need the NAMCO I/O. My goal is similar but mainly, I want to find out what components need to be swapped between SEGA ID2 cab and NAMCO WMMT cabs.
winteriscoming
Champion
To kind of close the loop on this theory, although I haven't tested it, I have a much better understanding of the outputs on the JVS I/O boards due to my custom JVS I/O board that I have been working on. Outputs on the I/O merely sink current to ground. So for a lamp you'd have it wired up with either 5v or 12v going to the positive lead on the lamp (coming from the respective pin for 5v or 12v on the I/O board in the case of Sega I/Os... maybe the same on Namco I/O) and the negative lead from the lamp goes to the output pin on the I/O where it is grounded when the I/O is activated, thus illuminating the lamp.
Therefore, all that needs to happen with this POWER pin from the Namco FFB board is that it needs to get wired directly into the corresponding output (Output 1-1 on the Sega Type 1 I/O), and the I/O will control the POWER pin accordingly.
winteriscoming
Champion
I tested this today with my custom I/O. I wired power into one of the outputs and mapped it as output 1-1 and it successfully drove the POWER line and initialized the Namco FFB board. Had I been using just a Sega Type 1 I/O, it would have needed to be wired into output 1-1, which would probably conflict with the wiring in most other games as this is typically the start lamp.
