What's new
By:
Filters

Custom JVS I/O - MEGA JVS

Interesting observation: I noticed the start lamp was not coming on in CTHR when it has been working fine previously and was working in OR2SP only minutes before. I went into the output tests and confirmed the start lamp was never lighting.

What happened?

Well, my guess is that I recently changed my reported number of outputs to match the Type 3, because ID4 and 5 seem to kill outputs if not using a Type 3. I'll have to dig into it more, but I guess with CTHR that it kills outputs if the number is greater than the Type 1. My guess is that if you used a Type 3 on CTHR that you'd lose start lamp illumination.

I was kind of hoping to lock in an all-inclusive feature reply and not have to manage features per title, but I guess I'm running into conflicting cases.
 
Guess who's not going to get much real work done today?

Mega jvs.jpg

I'm very pleased with the results. I notice a couple of header and component labels are missing, but they may have been on an incorrect layer that wasn't exported as part of the silk screen. Also, a weird label, like a part number, ended up on the 26 pin header that I don't recall seeing in Eagle at all... oh well, it will be covered up once the header is installed.

Besides a couple of labeling issues that are probably my fault, I think these came out beautifully.

I ordered them from PCBWAY. I sumbitted the designs on Sunday night and received the boards on Friday. That's pretty awesome turn-around time! They were very affordable, too, making me question whether or not it's worth it to struggle through DIY fabrication methods (even though I had a ton of fun doing so).

I counted the boards and they seem to have included a couple extras! 8o

I'm waiting on a parts shipment that should come today and I'll hopefully be able to assemble and test one out.
 
...and the parts order came in with my official JST power headers.

Here's a dry fit of all major components.

MEGA JVS Dry Fit.jpg

So far it's looking like my layout works. Everything fits anyway!

Time will tell if I think a design revision is needed, but with these large headers, I'm not sure the footprint could get significantly smaller designing around surface mount parts or even integrating Arduino components into the board.
 
winteriscoming said:
...and the parts order came in with my official JST power headers.

Here's a dry fit of all major components.

MEGA JVS Dry Fit.jpg

So far it's looking like my layout works. Everything fits anyway!

Time will tell if I think a design revision is needed, but with these large headers, I'm not sure the footprint could get significantly smaller designing around surface mount parts or even integrating Arduino components into the board.
Click to expand...
amaazing!
 
Is there a significant price difference between the top loading headers versus the side loading headers similar to the NAMCO I/O?

It could probably reduce the depth at which you would need to clear for the top of the board.

Otherwise, it looks good!!!

(You need a MEGA JVS Mascot now.)
 
I honestly hadn't even taken depth into consideration since there's so much room in the back of my OR2SP cab. Is there not ample vertical space in the ID3 cab?

Without putting this board on risers, the depth is comparable to the Type 1 on risers. If risers were incorporated, it's about a half inch extra depth.

I don't think the 90 degree headers would be a drop in replacement, at least for one of these connectors, due to orientation. I think the 60 pin one would bend inwards since pin 1 faces the center of the board, not the edge. Or the issue would be with the 26 pin connector since pin 1 faces the edge. I'm not sure which way the 90 degree headers are oriented. Maybe both orientation options are available?

I honestly haven't figured out a final solution for mounting, but I'm thinking it can be done with nylon washers under the Arduino, using the Arduino's mounting holes, and then install MEGA JVS into the secured Arduino.

Alternatively, the Arduino/MEGA JVS could be secured to a board that has the same footprint as the Type 1 and goes right into the existing mounting holes. I could mill something like that very quickly out of a cheap piece of acrylic or something.

Mounting might be an area that merits a design revision down the line, as I hadn't really taken mounting into consideration very much while designing.
 
If an OR2 cab is similar to ID2/3 the I/O is right under the foot rest. There is about a foot of clearance before you reach the top of the panel so depth is not really an issue. I was more curious on how some users on here will use it for their setups. Mainly in candy cabs or Lindbergh cabs where it's mounted vertically. You have bigger things to worry about than customizations. :)

Adding the arduino to it raises the depth but probably by 5-6 inches. It's really small and looking at your comparison, it could definitely replace the existing JVS location and not skip a beat.
 
winteriscoming said:
Also, a weird label, like a part number, ended up on the 26 pin header that I don't recall seeing in Eagle at all...
Click to expand...
This is apparently a product ID that the manufacturer added to the board, maybe for their purposes during manufacturing for identification and tracking. I double-checked my exports and this ID number was not present, and I see the matching number on my order from PCBWAY. I guess they find an open spot to place it and hope it doesn't interfere with the other information printed on the board. No big deal in my opinion, especially since it gets covered up with the header.

winteriscoming said:
I notice a couple of header and component labels are missing, but they may have been on an incorrect layer that wasn't exported as part of the silk screen.
Click to expand...
I verified that this was the case. It was totally my fault. I went with a default export setting that did not include a layer that had some text in it that was intended for the silk screen layer.

Next time I know to review my exports before submitting.

Overall I'm very happy with the results. I had looked up some reviews from last year maybe and people were complaining about alignment and poor quality silk screening. I have no complaints about the quality of any of it. Some of the smallest text on my board is .032" (.81mm) high and reads clearly. I checked several traces and they register continuity as they should, on both top and bottom when going through vias. I don't think I could be happier with the quality. I'm sure my design was much simpler to process than a complex surface mount design that really pushes them to the limits. I also used wider traces than their minimum since I wasn't needing to go narrower.
 
I got a board assembled and tried it out with an Arduino DUE and a MEGA. It seems to work as planned, except DUE's analog values jump way more than the MEGA's. That's unfortunate because it could mean different code will be needed to accommodate for each board...

The MEGA works great with the smoothing I have already implemented, but the DUE is going to require more smoothing. Maybe they would both work fine with the whatever smoothing the DUE needs.
 
winteriscoming said:
I ordered them from PCBWAY. I sumbitted the designs on Sunday night and received the boards on Friday. That's pretty awesome turn-around time! They were very affordable, too, making me question whether or not it's worth it to struggle through DIY fabrication methods (even though I had a ton of fun doing so).
Click to expand...
The answer to the question is no :) Pcbway is so cheap, especially when you factor in DHL shipping from China that I have changed the way I approach this. Before I was totally OCD and only ordered PCB's that was intended for production - now I find myself ordering stuff just to try out things and test stuff I'm not sure about. It's also good to have a few boards 'under your belt' before pressing the go button on 100+ boards as you normally learn something every time you get boards back.
 
The Arduino DUE is giving me fits!

I wasn't really able to test it thoroughly until I got my order of boards in.

Problem 1: I just found out it's a retired Arduino offering, which kind of sucks, but I suppose clones (which I have) would be available for a while.
Problem 2: Apparently some DUEs have an issue where they won't execute code on the first power-up, requiring a reset first. I've read that this can be fixed with a new firmware programmed using an overly complex method that requires a 2nd Arduino, or the installation of a capacitor in a specific spot. Neither of these are ideal.
Problem 3: DUE seems to be much more susceptible to EMI than the MEGA. I'm getting very frequent and erratic phantom switch hits in OR2 while the FFB unit is on. I don't get this behavior on the MEGA that I've noticed. I'm going to attempt to use a ferrite ring around the input wires to see if that helps.

My main attraction to the DUE is the use of micro USB ports to differentiate from the JVS port, and the onboard native USB port that will be useful in turning cabinet controls into a PC controller, but I'm not sure if I can't address the phantom switches, it might be a no-go anyway.

I'll do some experimentation, but I might be able to debounce the inputs and clean up some of the phantoms.
 
I think I've addressed the DUE's phantom switch hits.

The CPU has some cool built in features that the MEGA doesn't that allow for input glitch filtering. You set it during initialization for each input and don't have to manage it in the code otherwise, which is nice.

My hypothesis is that EMI is to blame for the original FFB issue on the MEGA where I had to add analog smoothing or I got erratic steering behavior. This would explain why I was seeing normal looking analog values in the test menu, with jumps comparable to the Type 1, but when playing it spazzed out. During input tests, the FFB is not on, so it isn't affecting the analog data. In the actual game it is on, and likely causing the issue, though I don't have a setup for debugging that in realtime.

EMI filters in the board design would probably help, but not sure if that will be worth a redesign since it seems like analog smoothing in software helps to address the issue for the most part.

I will do some tests with ferrite rings to see if they help from a hardware perspective.
 
Last edited:
The DUE is growing on me. I've got it working well for games as a normal I/O and I've got the foundation in place to make the DUE recognized as a HID game controller in Windows! I just now got working analog for steering and pedals, along with digital inputs, but I don't currently have anything on my laptop to play... :P I'll mess around with that when I get a chance, but things are looking good.
 
winteriscoming said:
The DUE is growing on me. I've got it working well for games as a normal I/O and I've got the foundation in place to make the DUE recognized as a HID game controller in Windows! I just now got working analog for steering and pedals, along with digital inputs, but I don't currently have anything on my laptop to play... :P I'll mess around with that when I get a chance, but things are looking good.
Click to expand...
I can test it for you. Have everything you need :)
 
I'm not ready to share with others for testing yet. I've still got a little more work to do.

HID controls, at least for a driving cabinet, are now integrated into my base code. USB mode can be toggled by holding in the profile switch for 5 seconds.

I was able to get my laptop to output low res and sync with my monitor in OR2SP and played OutRun with the cab's controls.
OR1.jpg
 
You must log in or register to reply here.
Back
Top