What's new
To do list:

1. Integrate features into profiles since some games behave differently according to features reply.
2. Come up with a better structure for adding profiles.
3. Wire up my unused fighter cab and test non-driving games to ensure playability with games that have more digital buttons.
4. Experiment with optional I2C output to display current profile information. Little I2C OLED displays can be had for under $10.
 
Ok, so EMI is definitely causing the analog jumpyness... and the source is the FFB unit, even when it's not in use. When the unit is powered on, even in games that don't use it, the analog values get jumpy. If I unplug the board, the analog values stay very steady.

I'm kind of pulling my hair out trying to figure out a hardware/physical solution. I went so far as to separate the wiring from the FFB unit and the digital/analog input wires. I even moved the FFB board to a different spot, further way from the I/O board. I've tried ferrite rings on both ends of the power wires going to the FFB and both ends of the steering wires. None of this seems to have helped very much.

The jumpyness doesn't appear to be so bad that it negatively impacts gameplay, but now that I know the source, it's something I'd love to be able to address. I'm not sure what else I can do, though, besides redesigning the board with more components to help with EMI filtering.
 
I went so far as to separate the wiring from the FFB unit and the digital/analog input wires. I even moved the FFB board to a different spot, further way from the I/O board.
Maybe you're going about that backward and the solution is the make sure the grounds are shared or even the 5V reference if possible.
 
I went so far as to separate the wiring from the FFB unit and the digital/analog input wires. I even moved the FFB board to a different spot, further way from the I/O board.
Maybe you're going about that backward and the solution is the make sure the grounds are shared or even the 5V reference if possible.
Hmm, I can check on shared grounds, but as far as I can tell, the FFB unit has its own transformer and does not take 5v as an input.

The only 5v wire I'm seeing on the schematics is the one going to the rotary encoder on the FFB motor. Besides that, there's not really a common 5v to reference because the MEGA JVS references analog voltage from its own internal regulator and is 5v for the MEGA 2560 and 3.3v for the DUE.
 
could you draw your power supply distribution? the ffb is namco str pcb?
 
the ffb is namco str pcb?
The FFB unit is the Sega MIDI FFB.


could you draw your power supply distribution?
What are you wanting to see? The cabinet is wired as a stock OR2SP cabinet.

I'm taking all connectors that normally go into the Type1 I/O board and plugging them into my board. The 12v connector goes to the Arduino's regulator and regulates it down to whatever it needs (5v and 3.3v). The 5v connector is only being used for powering output lamps. All grounds on all connectors are shared.


It may ultimately not be an issue worth spending too much time on. I've been playing WMMT2 with the FFB board powered on (obviously not used in this game as it's not compatible), and the jumps for the in-game test menu shows only about a jump of 4 for steering in either directions out of a full range of -384 to 384. The jumps seem to be insignificant when figuring in the entire range. Trying to control the wheel in increments of 4 is very difficult. The slightest movment off center usually puts it into the high teens or low 20s, so the jumps are relatively insignificant.
 
Ok, I'm officially going to call my analog jumps "good enough", because I just plugged my Type 1 I/O back in and booted up WMMT2 under the same test conditions and see similar jumps in values. It sometimes even gets into double digits when resting at the center. If the stock board is allowed to jump that much, so can mine! :thumbsup:
 
THIS IS MY PREORDER SPOT.. I call first... :thumbsup: :thumbsup: :thumbsup: Remember that when you start taking pre-orders.
 
It may ultimately not be an issue worth spending too much time on. I've been playing WMMT2 with the FFB board powered on (obviously not used in this game as it's not compatible), and the jumps for the in-game test menu shows only about a jump of 4 for steering in either directions out of a full range of -384 to 384. The jumps seem to be insignificant when figuring in the entire range. Trying to control the wheel in increments of 4 is very difficult. The slightest movment off center usually puts it into the high teens or low 20s, so the jumps are relatively insignificant.
Just to add to this, when you are adjusting the range for FFB on WMMT2, I notice that the range for the WMMT2 (namco) steering wheel is a lot less than on ID. I'm not sure which cab is similar to the OR2SP steering wheels range but you may either be going over the full range or you may have a smaller range to deal with altogether. I can only turn maybe 90 degrees in either direction on a WMMT1/2 cabs' wheel as opposed to SEGA ID3 cab which has a higher turning radius.
 
It may ultimately not be an issue worth spending too much time on. I've been playing WMMT2 with the FFB board powered on (obviously not used in this game as it's not compatible), and the jumps for the in-game test menu shows only about a jump of 4 for steering in either directions out of a full range of -384 to 384. The jumps seem to be insignificant when figuring in the entire range. Trying to control the wheel in increments of 4 is very difficult. The slightest movment off center usually puts it into the high teens or low 20s, so the jumps are relatively insignificant.
Just to add to this, when you are adjusting the range for FFB on WMMT2, I notice that the range for the WMMT2 (namco) steering wheel is a lot less than on ID. I'm not sure which cab is similar to the OR2SP steering wheels range but you may either be going over the full range or you may have a smaller range to deal with altogether. I can only turn maybe 90 degrees in either direction on a WMMT1/2 cabs' wheel as opposed to SEGA ID3 cab which has a higher turning radius.
OR2's wheel seems to be about spot on for matching the range in WMMT. If I initialize it correctly in the center, I can get to the min and max positions that notify me that the left and right are OK, and it's just at the physical stopping point for the OR2 wheel on either side.
 
It turns out that using these $10 tiny OLED displays is pretty easy:
LCD display.jpg

What's nice is that you don't have to constantly refresh the screen in the code. Just set it when you need to and leave it alone until you need to change it.

I'm thinking for in-cabinet use, this display could go inside the coin door, right next to the profile button.

I'll support these displays in the code, but I didn't account for them in the board design, so there's not a convenient header to plug right into. You'll have to solder 4 wires to the current version of the MEGA JVS board.
 
This took about forever to figure out!
Mega JVS logo on LCD.jpg



I had to move to a different LCD library since the one I started on isn't compatible with the DUE. It's a lot less intuitive to use, but it'll work. I'll have to test on the MEGA 2560 to ensure it still works there.

My hope is that I can program this in such a way that you'll use the same code for both MEGA and DUE, but additional DUE specific functionality will be automatically excluded when compiling for MEGA.
 
that little screen is awesome. I had no idea you could get a display that for cheap.
 
To do list:

1. Integrate features into profiles since some games behave differently according to features reply.
2. Come up with a better structure for adding profiles.
3. Wire up my unused fighter cab and test non-driving games to ensure playability with games that have more digital buttons.
4. Experiment with optional I2C output to display current profile information. Little I2C OLED displays can be had for under $10.
I have completed items 1, 2 and 4, but do want to incorporate a couple more things into profiles like suppressing byte 2 in analog data, and special case management, like where a profile might utilize gear shifting states or require scaling on the steering channel, etc.

It wasn't on the list, but I had mentioned it in another post. I am happy to report that I've figured out how to make the Arduino IDE ignore DUE-specific code when compiling for MEGA 2560. That means no need for separate branches of code to manage.

Unfortunately I seem to have done something in my latest code that messed up inputs on the MEGA because currently I can get to the service menu but it immediately exits, as if the button were being pressed again... but oddly enough it doesn't just sit there and cycle between entering and exiting the service menu so I'm a little confused about what's happening there. I can't get into the input tests to see how the switches are being read. I'll load up some older code when I get a chance and see if the issue goes away, and then compare to my new code.
 
Programming these boards can be a bit frustrating at times... Something caused the program to freeze up on the DUE and I couldn't even track down exactly what it was. I loaded up an old sketch and piece by piece added all the new features back in and it works fine... :S

I still haven't gotten a chance to get back into the MEGA issue.
 
Man, I almost feel like I'm back at square one, fighting with the code once it starts communicating with the mainboard. I've introduced something that breaks it now when reading/reporting switches. :(

It's something to do with the way I'm storing and applying profiles since that's the only major change that should have an impact here. I'll get it figured out eventually. It just sucks that my recent free time has been devoted to these new bugs instead of progress.
 
Back
Top