Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'rgb'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Welcome to the VPUniverse
    • VPU General Discussion
    • Site News & Announcements
    • The Big Bang
    • VPU Classifieds - Buy / Sell / Trade
    • Pinball Festivals, Groups & Gatherings
  • VPUniverse.com Online Virtual Pinball League
    • League Discussion
  • New Releases
    • B2S New Releases
    • Visual Pinball New Releases
    • Future Pinball New Releases
    • Front End & Support Files New Releases
  • Digital Pinball Cabinets
    • Cabinet Builds
    • Cabinet Discussion
    • PinCab/Pinball Hardware Development
  • Pin2DMD Forums
    • Pin2DMD General Discussion
    • Pin2DMD DMD Colorization Works in Progress
    • Pin2DMD Research & Ideas
  • Planet Visual Pinball
    • Visual Pinball Support
    • Visual Pinball General Discussion
    • Visual Pinball Development
    • Table Development and Releases
  • Planet Future Pinball
    • Future Pinball General Discussion
    • Table Development and Releases
    • Future Pinball Support
  • Artwork
    • Backglass Artwork
    • Feature Requests
    • Playfield Artwork
  • Pinball Front-Ends
    • HyperPin Support
    • Installation Support
    • Pinball X Support
    • Pinup Popper
  • PinMAME
    • Current PinMAME Source
    • PinMAME Development
    • PinMAME Support
  • Real Pinball & Arcade Gaming Discussion
    • Real Pinball Discussion
    • Arcade Gaming Discussion
  • Direct Output Framework
    • Direct Output Announcements
    • Direct Output General Discussion
    • Direct Output Support
  • B2S Development
    • B2S Development Support
  • Console & PC Virtual Pinball
    • Other Virtual Pinball & Gaming Discussion
    • Pinball Arcade
    • Console & PC Gaming Discussion
    • ProPinball


  • Backglass Downloads
    • B2S - For Players
    • B2S - For Developers
    • Animated Backglasses
    • Backglass Resources
  • PinMAME
    • PinMAME Source
    • PinMAME Roms
    • ROM Colorizations
  • Visual Pinball
    • VPU Patching System
    • Visual Pinball - 10.x.x
    • Visual Pinball - 9.x.x
  • VR - Virtual Reality Pinball
    • VR Pinball Install Required Files
    • VR - Visual Pinball X VR Conversions
    • VR - Room Templates
  • Pin2DMD Files
    • Pin2DMD Documentation
    • Pin2DMD Firmware
    • Table Support Files
    • ROM Frame Dumps
    • Pin2DMD Tools
    • Pin2DMD Color Palettes
  • Future Pinball
    • Future Pinball Files
    • Future Pinball Tables
  • Direct Output Framework
  • Pinball Frontend Downloads
    • HyperPin Support Files
    • Frontend Artwork
    • Plugins
    • Media Managers
    • Loading Animations
  • Development Resources
    • Table Resources
    • Table Creation Resources
    • Cabinet Resources


  • Cabinet Building & Configurations
  • DMD Colorization Tutorials
  • VpinMAME
  • Installing PinMAME for SAM Emulation
  • Game Specific Tips & Tricks
  • Future Pinball
  • B2S Tutorials

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 9 results

  1. I inserted an RGB LED into my launch ball button so now i can have 3 colors for 3 different modes PinballX and VP10. The issue I have is this: I want green to be PInballX start button, Red for VP10 Launch Ball, and Blue for VP10 Fire button but the start button in PinballX is to launch a table and the start button in VP10 is to start a game. Could the PinballX Start be moved over to the Launch Ball button for DOF? In the few vpin cabs I have seen, these are the same keyboard inputs and physical buttons. Thanks in advance for any info.
  2. DOF now has support for Philips Hue through PhilipsHueController and AutoConfigurator classes. Massive thanks to arngrim for providing example libraries to start with, and support in DOF Configtool for the Hue, and the I-Pac Ultimate I/O while I'm at it. Please note, this is a fork off the original R3 by lizardking / swisslizard as I've been adding ScheduledSettings, UIO support, tweaks to the I-PAC portion of DOF etc for some time now. Check the link below, and use the latest build if you're feelin' lucky. Backup your entire DirectOutputFramework-directory before toying with this! I take no responsibility for issues, fire, damages, earthquakes etc. https://github.com/rambo3/DirectOutput/tree/ultimateio/DirectOutput/Builds Swisslizard: huge thanks for putting the project on GitHub. I love my I-PAC Ultimate I/O, and with the sources I was able to add in support for it. That is huge. Introduction The Philips Hue family consists of Zigbee / wireless controlled lights, sensors, remotes etc. using a bridge (the Philips Hue "hub"). The framework supports auto detection and configuration of these units. Philips Hue is made and sold by Philips. The class was based off PacUIO.cs, and implementation makes use of Q42.HueApi. It retains the 3-channel RGB style inputs, but converts that over to a single-channel #rrggbb hex string. Pretty much like normal RGB-bulbs in a pincab. Technically a single bridge can control about 50 lights x3 = 150 input channels (sensors are additionally ~60). Distance is covered either directly, or through ZigBee device-hopping where signal travels along devices to reach the finale device. Each device acts individually, but a LED-strip cannot have its LEDs individually controlled; the entire LED-strip acts like a single RGB device, and will light up with the same color value. Setup Before DOF can start communicating with the bridge it will need a valid key. To get a key off the bridge the Link-button on the bridge needs to be pressed, and an dof#pincab "user" needs to be registered in the bridge (whitelist) within 30 seconds. This will return a unique key (for instance "2P4R5UT6KAQcpOjFaqwLDrbikEEBsMIHY6z6Gjwg") which can then be used from that point on. The same registration on another bridge, or even the same, will create a new key and is required if you want to crossfire/SLI two hubs for reducing latency per bridge as more bulbs on the same bridge will introduce latency. To avoid duplicates / spamming the whitelist, and to avoid bugs crashing the bridge, currently this is the suggested approach for getting a key: Step 1: set static IP to bridge Get IP of the bridge. Check your phone Hue App -> Settings -> My Bridge -> Network settings. It should default to DHCP. Change this to a static IP, and make note of it, or check your router for IP. Step 2: whitelist DOF using a browser Open up the bridge API in a browser using your IP, example (replace IP with your static IP): In the "CLIP API Debugger" it should say something like URL: "/api/1234/" with GET, PUT, POST, and DELETE-buttons. Copy&paste the following line into URL-field (not in your browser, but in the CLIP API Debugger): /api Copy&paste the following into the Message Body textfield: {"devicetype":"dof_app#pincab"} Next, walk calmly over to your bridge and press the physical Link button. You now have 30 seconds to hurry back to your browser, and press "POST"-button. Prepare for a second ride. Eventually you should get a username in the Command Response textbox, for example: "ywCNFGOagGoJYtm16Kq4PS1tkGBAd3bj1ajg7uCk". Make note of this. If you need more help, or images, see the Philips Hue API getting started tutorial with screenshots and replace the text with your own. The Name can also be adjusted. Step 3: add IP and key to Cabinet.xml Open up your Cabinet.xml, and add the following lines in the OutputControllers section, replacing the IP and key with your own: <PhilipsHueController> <Name>PhilipsHueControllerPincab</Name> <BridgeIP></BridgeIP> <BridgeKey>ywCNFGOagGoJYtm16Kq4PS1tkGBAd3bj1ajg7uCk</BridgeKey> </PhilipsHueController> Step 4: add lights using http://configtool.vpuniverse.com A bridge can handle about 50 lights. Each light will multiplex RGB (3 channels) on each send, similar to using RGB-buttons on a PacLed64 or UIO. To match your output channels to a specific light, use your Android / iOS Philips Hue app and decide which light you need to control. Each light should have a number in it, for instance "10. Hue lightstrip 1". That 10-number is the light ID. Mapped to the individual RGB-outputs in DOF Config Tool port assignments this means: ((light ID -1) * 3) + 1 = ((10 - 1) *3) + 1 = 27 +1 = 28, resulting in port 28, 29, 30 (R, G, B). If your light ID was 3, you'd map it to port 7, 8, 9. If your light ID was 1, you'd map it to port 1, 2, 3. If you want to delete the key from your bridge, open up CLIP URL again from the URL below, then enter the API-URL (replace both keys with your own, they're the same used twice), then press DELETE: /api/ywCNFGOagGoJYtm16Kq4PS1tkGBAd3bj1ajg7uCk/config/whitelist/ywCNFGOagGoJYtm16Kq4PS1tkGBAd3bj1ajg7uCk Shutdown of lights DOF will shut down lights that have been affected, not the entire light array like an UIO or Teensy. If you have a house / apartment controlled by the same Hue bridge, it should only power down that one light or LED-strip that was affected when exiting a table. The feature was implemented as I found myself in complete darkness after quitting Attack from Mars way too often. Latency This is where things get complicated, and I try to cheat, trick and compensate for wireless issues. Signal communication is reduced as much as possible. Results will vary greatly. I'll try and detail what is going on, why, and how I tried through testing to compensate for it. Latency in milliseconds varies depending on wireless distance and signal strength, device-hopping, LED affected (R, G, or and brightness. A worst case scenario would be to adjust all RGB-channels, including brightness. A connection takes a few hundred ms (done once at init using BridgeKey and BridgeIP), and color sends per-light about 40-800ms+. Typically about 100ms. The latency becomes the DOF Philips Hue bridge refresh rate. Note that Phlips Hue does support controlling a group of lights at the same time using the same color change (not individiaully controlled); I'm not doing that right now, everything is per-bulb. The bridge will at worst case queue commands; this introduces more latency and inconsistencies (colors stuck, stuttery fades). To avoid overloading the bridge, DOF will check connection every 3s and use the last known latency as a transition time for the device to smooth out color changes much like TVs introduce frame interpolation from ~film to native panel refresh through synthesized pixel data. Color transition is a Hue API native command, and once set in motion adjust smoothly regardless of latency. The same latency (say 120ms) will become the DOF Hue refresh rate until the next connection check 3 seconds later, at which point the latency might be 300ms. If latency at any time is below 100ms, this gets reset to 100ms to avoid overloading the bridge. In practice 50ms works, 40 even, for a while. Breathing room and bridge stability has absolute priority. If any color changes occur between refreshes it gets stored locally but not actually sent to the bridge / light until the next color change. This is where colors can get stuck until the next change if latency is also high when that happens. Compensating for latency Any off-states in either R, G or B channel uses a fade the amount of current latency. Any on-states from black in either R, G or B is sent instantly without a fade to attempt to have light on as soon as technically possible. Any R, G, B changes not 0 will transition using fade time the amount of current latency. Using Hue color transitions produces smoother pulsating LAUNCH-button for instance, or color changes in general. Without it colors would change inconsistently due to latency changes of 100, 400, 200, 800ms etc while trying to set the color in a varying time span. Using Hue transitions will attempt to smooth out those changes giving the bulbs something to do while DOF is fighting latency. Practical use Start with one light. Do some testing and benchmarks, and see how far you can push it. First thing I did was crossfire / hook up two bridges and 17 devices; RGB, white, ambience, spots, two LED-strips. Then mapped them all to Undercab RGB complex in configtool. It was an interesting experience. 17 devices is 51 ports and about 6000 lumen. One bridge had 16 lights, the other 1 LED-strip. The single LED-strip was close to ~100ms and responded very well to changes, almost hiding latency completely. The other 16 lights were different; Hue will affect one light at a time when controlled individually, and in this case it took about 2 seconds for all lights to light up one by one. For undercab light, it wasn't bad, and the whole apartment flashed vividly, including the bedroom. I then tried mapping all lights to left (red) and right (blue) flipper. Due to the quick changes, the lights could not keep up. Some commands were ignored as they were issued turn off commands before having a chance to light up. Splitting the lights between the two bridges would have reduced latency, but the Hue API does have support for groups. This increases latency, but will attempt to sync and set all lights simultaneously instead of gradually for each command. Start with 1, take it from there. arngrim suggested undercab light. It's a very good match with one of the newer +1000 lumen LED-strips. Debugging Check your DirectOutput.log file for details if nothing works. It should say PhilipsHueController for those specific commands, whether connection was made, whether your IP and key was read of Cabinet.xml, and connection status so you can check your actual latency to the bridge after a game. Wear and tear The bulbs are not cheap. They will break a whole lot quicker being controlled like flashers. Use common sense. I take no responsibility for broken hardware, damages, risks, downtime, pissed off better halfs etc. Example Config.xml attached, with some extra bonuses. Cabinet.xml pincab_dofhue_20170529_1.mp4
  3. Hello folks. One User asked me today something very nice. He like to use a PCB where the resistor for the HIGH POWER RGB(W) LEDs are all together, for a cleaner look. So I designed a 100x100mm PCB with 5x RGBW (20 resistors). Schematic: VPIN RGBW resistor SCH.pdf Design: Now is my Question: Need anybody else a PCB like that? When YES, I go and Order the PCBs and sell them for 4 USD + parts + shipping. The 4 USD are really just the costs for the PCBs on my side. - Sascha
  4. Version 0.1


    This is a General Schematic for the Pin2DMD with a STM32F407VGT6 Controller. includs: RGB DMD Output (HUB75) real Pinball DMD Input Signal Enancer for real DMD Input SD Card reader very Basic drawin but very usefull, to get all the Pins right. For more (like the Original Eagle file or correction in the Drawing), feel free to contact me.
  5. Hello everyone First of all, thanks in advance to everyone helping me with this! I've been building a Pinball Cabinet for the past few months and I am getting close to "finishing" it. If you want to check it out, use this link. My Pinball Cabinet (updates to come when everything is working) I am currently experiencing two issues with the Direct Output Framework. One shall be addressed here, the other one in this post: DOF issue #2: No flasher-feedback with otherwise working PinballX plugin I've been trying to solve these issues myself for the past few days/weeks, but failed, since I am not very experienced with DOF yet. I do not know whether these two issues are related. --- DOF issue #1: PWM-output on 2nd LEDWiz not working correctly - All RGB toys connected to a 2nd LEDWiz do not output in the full color spectrum. Only 7 colors are possible (red, lime/green, blue, yellow, cyan, magenta, white). It seems that the LEDs three channels are either «ON» or «OFF» and that the PWM/intensity settings are not handled properly by my current DOF setup. - DOF toys affected on the 2nd LEDWiz: RGB flippers (ports 5,6,7), RGB magnasave left (ports 10,11,12), RGB magnasave right (ports, 13,14,15), RGB undercab complex (ports 25,26,27). Those are all RGB toys connected to the 2nd LEDWiz. - When triggered by other software tools (LEDWiz software by GGG, LEDBlinky) all of the above outputs/ports behave normally. When adjusting intensities with those tools, single output colors are dimmable. And using multiple outputs/ports with different intensities results in a wider color spectrum. This is why I believe that my issue is related to my DOF setup or DOF itself and not to my LEDWiz controllers or related hardware (Zebsboards). - RGB toys connected to the 1st LEDWiz are not affected by this issue and light in full color spectrum. Those toys are: 5 flasher outside left throughout 5 flasher outside right. Ports used: 1-15. - When adjusting the «Custom Brigthness» setting in the DOF Config Tool in the Ports assignment tab, the brightness of all my RGB toys adjust properly, but still only with 7 colors for those on the 2nd LEDWiz. --- Further information on this issue and my current DOF setup. - I use this DOF R3 Beta version: DOF R3 Beta Build 5812.27024. As far as I remember, I already had this issue when using DOF R2. - I use this B2S Server version: B2S Server. - I use a two identical GlobalConfig files (globalconfig_B2SServer.xml and globalconfig_PinballX.xml) and the ini-Files created by the DOF Config Tool (directoutputconfig.ini and directoutputconfig2.ini), but no Cabinet.xml or dedicated table config files. - For now I only use 2 LEDWiz, which are listed in the «My Account» tab of the DOF Config Tool. A Teensy is supposed to be added soon. --- Help required As stated above, I am not very familiar with DOF yet and don't see a way to solve this issue myself. That's why I need your help and would greatly appreciate it. I feel that this issue, and the other one mentioned above, are limiting my experience while playing my Pinball Cabinet. So, what can I do to help you guys to help me solve these issues? What additional information, logs, xml-Files, ini-Files, screenshots, videos etc. do you need? Or do you maybe already have a solution or know someone who had the same or similar issues? I'm looking forward to hearing from you guys. Thanks again in advance! --- Best regards from Switzerland fuzgi --- 1st Edit: I just figured out that when I use DirectOutputConfigTester.exe at least the under cab complex RGB toy changes its color (within the full spectrum) when enabling / pulsing different table effects.
  6. Hello Pinball Folks! Here is Sascha.... the #Pin2DMD Shield Hardware Designer. Here is another nice Shield for the LWClone2U Project. As DIY Set, Soldered Set, Single Parts or complete Set with Arduino Leonardo Maybe someone likes it and want to buy one or more. I made that Shield usually for myself as HIGH Current OUTPUT Driver Shield. You can connect everything to it! Shaker, Becan, LED, High Power LED's, Solenoids, etc. For use with any Inductive Load I recommend you my "Flyback Diode Shield" http://vpuniverse.com/forums/topic/2607-flyback-diode-board-for-solenoids/#entry29621 Tech Specs: 22 High Current Output Channels each Channel can run on a Different Voltage all components are THT (Through-hole technololgy) for aesy self repair easy to Install Here some nice Pictures from the Shield: Attached to the Leonardo Board: Test with RGb Strips: And now the Pricing... Oh no, not to expensive! Check the Parts and you see, it is not to expensive! Partlis / BOM: Leonardo OUT PCB - Partlist.pdf I am not a professional Salesman... this is still a Hobby! Set: Soldered PCB 4.00 USD = 1x PCB rev 1.0 19.00 USD = 1x ALL Parts (check the Partlist and compare when you think it is to expensive) 5.00 USD = 1x Soldered 2.00 USD = 1x 4 PCB Stand-Offs for easy mounting (incl. 4x M3 Screw, 4x Wood Screw) Total: 30.00 USD + Shipping with USPS (rates on request, starts with 4.00 USD) Set: Complete PCB with Arduion Lenardo 9.00 USD = 1x Arduino Leonardo (with FREE LWClone2U Firmware) 4.00 USD = 1x PCB rev 1.0 19.00 USD = 1x ALL Parts (check the Partlist and compare when you think it is to expensive) 5.00 USD = 1x Soldered 2.00 USD = 1x 4 PCB Stand-Offs for easy mounting (incl. 4x M3 Screw, 4x Wood Screw) Total: 39.00 USD + Shipping with USPS (rates on request, starts with 4.00 USD) Set: PCB DIY 4.00 USD = 1x PCB rev 1.0 19.00 USD = 1x ALL Parts (check the Partlist and compare when you think it is to expensive) 2.00 USD = 1x 4 PCB Stand-Offs for easy mounting (incl. 4x M3 Screw, 4x Wood Screw) Total: 25.00 USD + Shipping with USPS (rates on request, starts with 4.00 USD) Parts ONLY - select here what ever you need and send me a PM with you wishes! 4.00 USD = 1x PCB rev 1.0 19.00 USD = 1x ALL Parts (check the Partlist and compare when you think it is to expensive) 2.00 USD = 1x 4 PCB Stand-Offs for easy mounting (incl. 4x M3 Screw, 4x Wood Screw) + Shipping with USPS (rates on request, starts with 4.00 USD) And when anybody needs any Kind of PCB, just contact me. We can Design one and I made the Rest for you! Cheers Sascha
  7. From the album: UncleSash Pin2DMD

    The last rev 1.x PCB! LAST version with 2x HUB75!

    © UncleSash

  8. Hi, Is it possible to use more than 5 rgb flashers with dof? ie. One set of 5 in the back of the cabinet and 5 flashers on top of my backbox, I know you can wire them to the same ports but is there a way to get 10(or more) to work separately?
  • Create New...