Light Buttons with LED Hardware/Software - COMING SOON!!!

[DinoRoger]

One more thing left on the web site to do. Does anyone know any easy to configure, secure, and free e-mail server software?

[Lilwolf]

what OS are you hosting on?  At home or at another location?

What OS?  Assuming not Linux (because you wouldn't have to ask)..

And why do you need an email server running?  

[Valiam Arkais]

One more thing left on the web site to do. Does anyone know any easy to configure, secure, and free e-mail server software?

I use openwebmail.  It has worked good for quite some time.

-VA

[DinoRoger]

I am hosting on a local system at my business using Windows XP. A PostNuke module/block would be awesome but any other free software will work.

[DinoRoger]

Some new progress:

Just finished a seperate software piece that can run as a screen saver or as a regular exe that will perform the attract mode.  It is eiter sound activated or you create your own attract mode with delay statements.

The program uses allot of CPU but in idle mode why would you need the CPU.

The program will detect sound from the microphone.

Will report back with more details as I create them. Still trying to finish the web site.

[TheGatesofBill]

What do you expect this to cost when its ready?

[DinoRoger]

What do you expect this to cost when its ready?

Have not figured that out yet. Once I build the final prot-type I will gather all parts and manufacturing costs and decide on a price. A may even have combos like pre-wired lighted buttons and such.  I am working my hardest to make this a user friendly top quality product.

[KevSteele]

I've got to say I'm very excited about the possibilities of this project. It sounds very cool, and the more lights, the better  

Kevin

[DinoRoger]

Web site is finaly online. Please go and register on the forums. New details about the project can be found here:

http://lamearcade.com

[TheGatesofBill]

Registration is all messed up. You're going to have to disable account registration (or fix the e-mail). Either way, please active my account.



EDIT: How to disable the emailer:

Open up includes/emailer.php, find "global $phpEx, $phpbb_root_path;", add "return true;" under it & that should fix the problem. It should end up looking like this:

Code: [Select]

//
// Send the mail out to the recipients set previously in var $this->address
//
function send()
{
         global $phpEx, $phpbb_root_path;
         return true;

         if ( $this->address == NULL )
         {
                message_die(GENERAL_ERROR, 'No email address set', '', __LINE__, __FILE__);
         }

         if ( !$this->parse_email() )
         {
                 return false;
         }

[DinoRoger]

Your account ia active now. I think the problem is with the timeout delay. If you dont wait for about 30 seconds after clicking submit the e-mail doesnt get sent. I wil try your suggestion here in a few minutes, Thanks I am new to PostNuke and the forum.

[TheGatesofBill]

If you make the change I suggested, make sure you disable e-mail activation. Also, I've never used PostNuke, but I'm pretty familiar with phpBB, so if you need help with anything, let me know.

[DinoRoger]

Ya I tried what you mentioed but was getting errors every time I tried to register. it was probably because I didnt disable the e-mail activation like you mentioned.

[jdjuggler]

What ever happend with the project?
Anyone know?
JD

[KevSteele]

I wish I knew - the site's gone, and nothing.

I was/am very excited about this project, and now I'm regretting not asking to be on the beta test team (if there is one anymore!)

Kevin

[mr.Curmudgeon]

Me too.

I'm building my cab with the assumption that the LAME Aracade lighting system will be available at some point in the future. I will cry if he drops this project. It's one of the things I'm most excited to include in my machine.


Hope all is well....

[mccoy178]

Time to bring this idea back to life.  With the driver board being released last month, lets get some things going here.

[TheGatesofBill]

Actually, that was for driving just three LEDs off of the I-PAC, representing the keyboard lights. Unless I misunderstood, which is possible. I wish this was still around, I would have loved to play with it.

[Chris]

Time to bring this idea back to life.

[mccoy178]

I know the driver board is limited, I just like the idea of what this guy had going.  I am hoping one of the more savvy members can take this to the next level.  I felt the driver board may just bring attention back this way.

[Buddabing]

Time to bring this idea back to life.

[Chris]

What would be really nifty, although it may take USB, is to be able to have LED's ganged in groups of three (red, green and blue) with ideally at least three brightness levels (full, dim, off).  This would theoretically allow you to tell the button what color to be.  Of course, it would require clear translucent buttons to pull off...

--Chris

[Popcorrin]

Budda I am glad to hear you are still working on this!  I can hardly wait to try it out. 

[KevSteele]

Excellent news! I'm glad the idea lives on, and good luck Buddabing!

[quarterback]

I'm also considering an optional upgrade to 40 LEDs which will allow the bling bling strobe effects on that fancy control panel for which I can't find the link.

Is this it?

That's the ArcaLux

[Lilwolf]

I found a board that handled 64 leds back a while ago.. but it was pretty !@# expensive! 

I can't wait to see what you come up with... But why build it into your mame build?  Control.dat + a middleware piece or just another app would really be better don't you think? 

Also be nice for non-mame emulators.

[Buddabing]

I'm also considering an optional upgrade to 40 LEDs which will allow the bling bling strobe effects on that fancy control panel for which I can't find the link.

Is this it?

That's the ArcaLux

That's it. It was pretty cool, but $600. 

If I were to sell these, it would be much less.

In addition to MAME I would create a middleware application to control the LEDs.

[versapak]

Did the original project actually hit a road block and die, or did

[Popcorrin]

Buddabing I was wondering if you were going to design the software to light up led's for the joystick directions?  That way if a person was to place 8 led's around the joystick he could use your software to light 2, 4, or all 8 of the led's to signify whether the game is 2, 4, or 8 way?

If this were implemented I think a person could also use that feature along with a slight modification to the led driver board to automatically switch modes on Groovy Game Gear's 49-way joystick usb interface making a cabinet even more user friendly.  If you aren't familiar with the 49-way interface there is a description here.   http://forum.arcadecontrols.com/index.php/topic,32747.0.html

[Trimoor]

To get past the limitations of available I/O lines, wire the LEDs in a matrix.  Most of you think of ghosting and blocking when you hear the work "matrix", but if done properly, and it works quite nicely.

The classic PIC16F48 has 13 I/O lines, giving you a 6 x 7 matrix.  This can control up to 84 LEDs.  Yes, 6x7=42, but remember that LEDs are diodes: if you reverse the polarity of the current, you can light a different LED.  Bipolar LEDs do this.

To solve the ghosting problem, you must scan the matrix.  This means only one row and column are activated at a time.  Before you go on about flickering, it would be doing this at 1-2 MHz.  Take a look at your monitor.  It's only scanning at 60-100 Hz.

The drawbacks of the matrix is that there is no common ground.  Every LED must have two wires leading to the controller.  It isn't too hard to do, but it takes longer.  The wiring harness can make this simple for users, but it might be rather expensive.  The controller board would have 84 pairs of header pins (like the kind on a motherboard power switch header), and the user would have 84 little jumper cables.  These cables would have a PC connector on each end, matching the header pins.  The two wires would be different colors to indicate polarity.  The user would plug one end into the board, and the other onto the LED (the pins happen to be the same type as the header pins, albeit a little longer.)

As for cholin's (my) idea, it would still work, but it would be a horrible rat's nest under there.  The best way to do this would be to implement the LED controller on the same board as the keyboard encoder.  That way, the LED controller would "know" what was being pressed, and act accordingly.

[Lilwolf]

Just because I always bring this up.

Any consideration for hotswap control panels?  If someone wanted to run the lines, would your board be able to support it?

And.. How many people would really care about more then 40 LEDs?  Would there be a chance for simplifying the wiring if the numbers went down?  For instance... The LPT encoder (other thread) I was able to change the circuits around slightly so that groups of 12 buttons acted like they had a common ground.   So for instance instead of 6x7 you could have 3x14 matrix... and have three groups of 14 where each group has their own 'ground'... That will probably be doable for most and will work well.   

Last... GOOD LUCK!   I would love to see one of these going!

[tetsujin]

The classic PIC16F48 has 13 I/O lines, giving you a 6 x 7 matrix.  This can control up to 84 LEDs.  Yes, 6x7=42, but remember that LEDs are diodes: if you reverse the polarity of the current, you can light a different LED.  Bipolar LEDs do this.

I don't think that's true.  I designed a LED matrix circuit not too long ago using a PIC using just an m*n matrix - I wanted to expand it to m*n*2 but the idea didn't seem to work.

Consider input lines used to drive an M*N*2 matrix of LEDs.  The "M" axis I'll call "x" and the "N" axis I'll call "y".  There's a set of LEDs at the intersections of the matrix - A(x, y) is the LED with anode on "x" and cathode on "y", B(x, y) is the LED with anode on "y" and cathode on "x"  (So A(x,y) and B(x,y) are two separate LEDs in the same place, with opposite polarity).

Now, assuming the outputs of X and Y are typical two-state digital lines, how do we light only A(x,y) while leaving all other LEDs off?

Basically, you set x high and y low.  Now, since A(x, y+1) is not to be lit, (y+1) must be high.  So how do you prevent B(x+1, y+1) from lighting?  (x+1) would need to be high, to prevent current from flowing through that LED.  But if (x+1) is high, and (y) is low, then A(x+1, y) will light up.

[ErikRuud]

Something like this should work for driving LED's in a matrix.  It does not have any provision for doubling up the LED's, but 256 led's should be enough.

http://www.codemercs.com/Downloads/AN1.pdf

[mccoy178]

Man I wish I understoood this stuff.  I have so many neat ideas, just can't do anything with them!  Frustrating.

[Trimoor]

There's really no need for special chips.  Use a pic and a multiplexer to drive everything.

tetsujin, I don't quite understand your description, but if I remember correctly, PIC I/O lines actually have three states: high, low, and float.  To light an LED, set one of it's pins to high, the other low, and everything else to float.

Also, look into charlieplexing.  It might be applicable here.

[cholin]

I was thinking about this all day.  If I knew a little more about what chips did what, I would be able to help.  Firstly, Trimoor will probably answer this one:  are all chips programmable at least once?  You do write your own code to the chip, right?

If so, then what we can do, is put some USB or serial interface (or both with a chip to detect activity) and from there, it will go to a chip that controls the matrix.  We can send simple text through the connection to a chip, and depending on the text sent, we can turn stuff off and on.  I don't see a need to *scan* a matrix because we're not reading information.  My idea is that a person can use a program (such as lamemame or whatever) to send a string of numbers through the serial port, like DINO said.  The main chip will read this string, and with the code we wrote into it, the chip will set some lines to high, some to low (Im assuming one side needs to be high, one side needs to be low).  This will cause a slight problem though wont it if we need to light up some LEDs in strange areas because if a line is already high, we can't set it to low at the same time, so therefore, we can only light so many at a time.  Im probably wrong, but if I had the money, I would be the first person to develop this.

[tetsujin]

tetsujin, I don't quite understand your description, but if I remember correctly, PIC I/O lines actually have three states: high, low, and float.  To light an LED, set one of it's pins to high, the other low, and everything else to float.

Depends on the PIC maybe.  The ones I've used don't have that, at least I don't think so.

[Trimoor]

The PIC line of microcontrollers can all be programmed many times.  You must write your code in assembly (ack!) or you can buy a ridiculously overpriced compiler.

Serial interface is trivial, USB probably isn't worth the trouble as it requires more hardware and computer drivers, and leaves out DOS.  Send a string of ASCII characters to the chip, which it interprets to determine which LEDs to light.  Send an uppercase letter to turn it on, and a lowercase letter to turn it off.  Or you could program it for larger commands such as all on/off.  All customization/LED configuration should be done at the computer end for simplicity.

The actual LEDs are either controlled by the microcontroller, or by a multiplexer.  The multiplexer will allow more LEDs, but it brings up the cost.

Scanning the matrix is necessary, but is done by the chip, not the host computer.  You won't notice a difference, but it uses many fewer ports.  This is done to eliminate ghosting.

Some of the PICs on microchip's site have up to 70 I/O lines in a $5 surface mount chip!  This might be the chip we need.  70 LEDs without a matrix, so we can use a common ground.  Or you could matricize them for 1,225 LEDs!

[tetsujin]

The PIC line of microcontrollers can all be programmed many times.  You must write your code in assembly (ack!) or you can buy a ridiculously overpriced compiler.

There's also SDCC, which I use for some of my stuff:  It's a little flaky sometimes (especially for 14 bit PICs - I think 16 bit PIC support is better) but it's useful.

http://sdcc.sf.net

Assembly can be tricky until you get the hang of it.  The whole deal with branching being done by "skip next instruction if such-and-such bit is set" is one I have some trouble with.  Otherwise, though, it's really not that bad.