734 replies to this topic

[kruuth]

The pinscape is a fine idea but I'm saying they it could use a little improvement that's all. I never said that it was bad, hence why I was talking about fixing the driver. The idea of an optical controller with no moving parts that also handle button input at that price is great. My only concern is that the resolution of the sensor is too high for this application. That's why I'm suggesting reducing the resolution in hardware or changing the driver to throw out black bands between the start and finish point. I understand it's a hobbyist tool and I'm glad mjr came up with it.
What I find strange is that the ccd image looks perfect then I run the calibration and it suddenly had banding.

[mjr]

MJR, this is a really great project with the critical flaw of the banding problem.  

 

I suspect you're focused on the wrong thing here.  It's guesswork without gathering some data, but my guess is that the "banding problem" isn't the source of the jumpy behavior.  The software tolerates a fair amount of pixel noise as long as you have good overall contrast between the light and shadowy areas.  I suspect the jumpiness is caused by something you're not seeing because it's happening too quickly to see on the viewer.  E.g., it could be very brief flickering in your light source, or momentary electrical noise.

 

 

 If lowering the resolution on it would help, that might be the answer, since you really only need 8-16 points to get enough for vpin to handle the rest.  

 

You can, but I wouldn't recommend it.  Open config.h and find this line (about line 227):

 

const int CCD_NPIXELS_SAMPLED = CCD_NPIXELS / 8;

 

That selects the default resolution of 160 pixels (1280/8).  You can reduce the resolution by increasing the divisor - just make sure the result divides evenly.  Values of 16 (80 pixels), 20 (64 pixels), 32 (40 pixels), 40 (32 pixels), 64 (20 pixels) would all be valid.

 

160 pixels is actually about the minimum resolution you want for good results in VP, though.  That produces about 50 dpi, which is on the order of the on-screen pixel pitch, so each "step" of the physical plunger is approximately one pixel on the screen.  Anything below this will start to show visible stepping between positions as you move the plunger.  Equally importantly, the resolution determines how much control you have over the ball speed.  If you reduce the resolution too far, you might as well just use a launch ball button, because you won't leave yourself much control over release speed.  The whole point of a mechanical plunger to me is faithful simulation for skill-shot tables.

 

Anyway, that's all kind of beside the point, because I'm pretty sure it won't help with your problem.  Whatever's going wrong for you is most likely caused by transient noise.  If you reduce the number of pixels, you'll have the same amount of transient noise hitting fewer pixels.

Edited by mjr, 19 April 2016 - 04:33 AM.

[kruuth]

Right now I'm using an led light that's been masked off pretty well. There isn't much other light in there that I can see. The only other light sources were the coin light and the two lit buttons. I was under the impression that Led didn't have noise but I can introduce slide power source in there. What can I do too get more data to help fix this? Like I said, I'll get a perfect black/ white threshold that will suddenly go south after I run the config and it starts showing bands.

Edited by kruuth, 19 April 2016 - 08:28 PM.

[kruuth]

Ok.  I wanted to post an update to my issue and I hope it helps people in the future.  Maybe it's my sensor, or maybe it's the light, but I found something interesting out.

 

Do NOT use white light. 

 

I got an assortment of colored LED bulbs today, and plugged them all up.  With yellow and white light, I was able to recreate the banding effect very quickly.  However, with red, green, and blue I managed to get no bands at all.  I did, however, need to move the light a lot closer.  Now the bulb is about 4 inches away from the sensor.  All of my previous bulbs were white as well, and I tried masking them off several ways, with different tinting gels, and poking small holes for the light to get through.  Since I don't have the dexterity to solder I used a BA9S bulb here:

 

http://www.ebay.com/...=STRK:MEBIDX:IT

 

I had a bunch of jacks sitting around that accept these things.  You just run 12v off something.

 

One thing I have noticed though, I have a small white bar at the top of the sensor.  While the plunger will travel back and forth just fine, if I go into the test table I have to pull the plunger back a little bit because if I don't then the ball will just launch at full speed the moment it appears.  Is there some sort of workaround for this?  I'd hate to have to tweak every single table.

[Mace]

Read my last post Kruuth, I covered these areas, your plunger needs adjusting to leave a larger white area. The nice way is to move the light and sensor, the quick way to find out how far to move things is to pop a washer or two under the outside spring until it's right. Then take them out and move the sensor by the same amount.

[NobodyYouKnow]

The spectral sensitivity of the TSL1410 is heavily weighted toward the Infrared and Far IR (see image), The visible portion of the spectrum runs from about 450nm to 750nm. IR band runs from about 750nm to 1,000nm. I stuck on a snippet of the visible light portion of the spectrum to make this a little more visual. Anywhere in the visible spectrum, the minimum response is .5 or better. It is a testament to the sensitivity of these sensors that they can operate from such a wide range of colors.

 

 TSL1410 Spectral Response.png   102.86KB   6 downloads

[kruuth]

I did read the post. Notice I said I moved it. That's in spite of the movement that I'm getting the issue. I would not have mentioned it has I not tried that.

[kruuth]

Ok.  I moved it yet again.  Before I had about 10% white space at the front of the plunger and now I have closer to 20%.  Still I have the exact same issue with the ball auto-launching.  I set the value for zeb's auto-launch to 2.0 in the config and built and it continues to do the same thing, the first ball launches fine, all of the subsequent ones just fire the moment that they drop in there.  Here's a video to illustrate what I mean:

 

 

Should I be using the joystick config on top of the official config?

[mjr]

Ok.  I wanted to post an update to my issue and I hope it helps people in the future.  Maybe it's my sensor, or maybe it's the light, but I found something interesting out.

 

Do NOT use white light. 

 

I got an assortment of colored LED bulbs today, and plugged them all up.  With yellow and white light, I was able to recreate the banding effect very quickly.  However, with red, green, and blue I managed to get no bands at all.  

 

I'm glad you found a light source that's working better for you.

 

I suspect the problem you were having with the white bulb is that a white LED is actually *three* LEDs in one - a red, a blue, and a green, balanced to produce a combined output that looks white to the human eye. The three sub-LEDs are usually side by side in the device, so each one will be at a slightly different angle relative to the target.  That could be what was creating all of the weird optical artifacts - you might have been having red, green, and blue fringes at the edge of every shadow because of the slightly different incident angle.  The pixels in this sensor have a 400 dpi pitch, so they can see fine details like this that might not be visually obvious to the eye.

 

My advice based on my own experience is always to use one of the standard small 20-30 mA LEDs.  Those are monochromatic, and they usually have a narrow focus that throws all of the light in one direction.

 

 I did, however, need to move the light a lot closer.  Now the bulb is about 4 inches away from the sensor.  

 

That might be because the bulb you have is designed for a more omnidirectional light distribution (i.e., a lot of the light is being wasted because it's not aimed at the sensor).  4" is closer than I like to have the bulb, but if you're getting good results, no reason to fix what ain't broke.

 

 

Ok.  I moved it yet again.  Before I had about 10% white space at the front of the plunger and now I have closer to 20%.  Still I have the exact same issue with the ball auto-launching.  I set the value for zeb's auto-launch to 2.0 in the config and built and it continues to do the same thing, the first ball launches fine, all of the subsequent ones just fire the moment that they drop in there.  Here's a video to illustrate what I mean:

 

 

Should I be using the joystick config on top of the official config?

 

Hmm... did you by chance run calibration in the Windows joystick control panel?  The little snippet you showed of it looks like you did, because it looks like the resting position is near the negative maximum point (the leftmost/red part of the bar graph).  The resting position should be at the ZERO point, which is depicted in the Windows panel as the halfway point on the bar graph.

 

If you did calibration in the Windows control panel, you should delete it.  Go to Properties -> Settings and click Reset to default.  Then run calibration in the *Pinscape* setup program instead.  Follow the on-screen instructions for that.  When you go back to the Windows control panel, the Z axis should be at the halfway point when the plunger is at rest.

 

If I'm interpreting the video correctly, that's probably causing the weird launching behavior you're seeing.  VP thinks the plunger is infinitely far forward when it's at rest, which is probably making it detect a collision with the ball as soon as it creates a ball.  If you fix up the calibration that should hopefully stop happening.

[kruuth]

Ok so don't run the windows controller configuration. Sorry I missed that one.

I can understand that about the white light but it happened on several types but you're probably correct. I'll Go back and kill the configuration and start from scratch.

Right now I'm just happy I'm not getting the stripes again.

Yeah the bulb is more of a directed light now.

Edited by kruuth, 24 April 2016 - 12:22 AM.

[kruuth]

Wiped the config in windows and then re-ran the official tool.  Working perfectly now.  the .2W LED I linked works great so far.  I tried moving the bulb a littler farther from the sensor and get the same effect.  Does the configuration instructions say to not perform the windows config?  

[Les73gTx]

Yes it does say NOT to use the windows configuration. Also I found that EVERY time you move the light source you have to run the included configuration tool that MJR provides. If you do not the smoothness and consistent repeatability becomes less accurate. If I can offer some helpful advice .... read the instructions MJR made in the first post again. He has done an great job of putting down exactly what needs to to be done to make this work.

Sent from my SAMSUNG-SM-G870A using Tapatalk

[Sneetch]

Hooray kruuth! I have been reading this thread a lot just to see how you were coming along. It has been an educational read for me for sure. And should I ever build another pin cab I think I would give mjr's offering a shot. Kudos for getting it working and kudos to all the support others gave along the way. Such a great community.

[kruuth]

Yes once working it's nice. The guy that made this is willing to solder more together on request for a fee

[kruuth]

Say, I have gone through a fair number of my tables and they don't have support for the controller but do support the enter key.  Is there documentation on adding support for an analog plunger?

[Les73gTx]

Yup read the thread again it is there. Sorry I don't have time to find it for you.

Sent from my SAMSUNG-SM-G870A using Tapatalk

[mjr]

Say, I have gone through a fair number of my tables and they don't have support for the controller but do support the enter key.  Is there documentation on adding support for an analog plunger?

 

Here you go:

 

http://www.vpforums....=33238&p=327625

 

I'm afraid I haven't come up with a 100% mechanical process - it takes some manual examination of each table's layout and scripts.  The complication is that it's not just a matter of "adding" support; you also have to find and delete all of the "anti support" that people bake into their table scripts.  The semi-recipe linked above is pretty easy to apply once you get the hang of it, though.

Edited by mjr, 03 May 2016 - 11:12 PM.

[Les73gTx]

Ok mjr I have a problem that I do not think is my cab and I have eliminated it down to the Freescale board. I have PinballX  for my frontend and after installing this setup I have a problem with attract mode starting up again after the first table is played and you exit back to the frontend.  Attract mode works fine after starting PinballX as long as I don't play a table. But after that first table is played attract mode will not work again until the next reboot. I have been able to narrow it down to the freescale board by unplugging it and running .... attract mode works fine if the board is unplugged. I suspect that PinballX is seeing a keystroke from the board (self zeroing/leveling code maybe) but I am not sure on that; so I asked for someone over on the PinballX site to look over the log files and see what is causing the problem. Not sure if you can test this or even figure out what is happening but I will update you with the exact cause when I find out from PinballX support. 

[mjr]

Ok mjr I have a problem that I do not think is my cab and I have eliminated it down to the Freescale board. I have PinballX  for my frontend and after installing this setup I have a problem with attract mode starting up again after the first table is played and you exit back to the frontend.  Attract mode works fine after starting PinballX as long as I don't play a table. But after that first table is played attract mode will not work again until the next reboot. I have been able to narrow it down to the freescale board by unplugging it and running .... attract mode works fine if the board is unplugged. I suspect that PinballX is seeing a keystroke from the board (self zeroing/leveling code maybe) but I am not sure on that; so I asked for someone over on the PinballX site to look over the log files and see what is causing the problem. Not sure if you can test this or even figure out what is happening but I will update you with the exact cause when I find out from PinballX support. 

 

Okay, let me know what they find.  Attract mode uses the LedWiz output?  If so then my best guess is that PBX is doing a USB device enumeration that's getting hung up somehow.  I obviously have no way to debug their code because it's all closed-source, so hopefully they can figure it out!

[Les73gTx]

Yes in PinballX you can use the LedWiz to flash lights and run toys for a set time .... but really what it is not doing is going into the random shuffle of tables every 45 seconds after it is idle for 2 minutes. They call it an attract mode. Has nothing to do with the LedWiz other than a plugin to run the lights when the attract mode starts.
No word from Tom over there yet but another admin thinks that it is seeing some kind of nudge reading and keeping the cab "active" so it never goes idle.

Sent from my SAMSUNG-SM-G870A using Tapatalk

Edited by Les73gTx, 04 May 2016 - 06:29 PM.