spirilis 1,265 Posted March 30, 2013 Share Posted March 30, 2013 Got the inspiration to do this from a coworker who suggested wrapping those WS2811 LED strips around a bottle of water to disperse the light--like he used to do while camping: This uses a custom DMX512-over-nRF24L01+ protocol I cooked up that works seamlessly with my existing "packet" architecture which I use for my Grill Monitor project. The current project is powered by a tablet USB charger and is using one of my defunct draft1-edition F5172 LaunchPad XL boards (the one that couldn't get its XTAL to stabilize thanks to very poor layout on my part... I'm relying on REFO for this). Main reason is to get 5V-native I/O going to that WS2811 DIN line (I've had issues driving those WS2811's with 3.3V levels, I suspect 3.6V works correctly but 3.3V not too well, but I don't have any 3.6V LDO's in my bin at the moment). Quick recap- The "packet" architecture defines a data link layer where information within the nRF24's 32-byte packets is encoded as an 8-bit "program ID" followed by 8-bit payload size definition, followed by that many bytes of payload. I defined a number of program IDs for the use of my grill monitor but I decided to define a range of program IDs for use with DMX512. DMX512 implementation- Program ID code 0x20-0x3F now represent the 512 channels of DMX512, in 16-channel segments, with a final command "0x40" used to COMMIT any updates to those channels (so the general logic flow is, a sender transmits a bunch of packets representing channel updates, then sends a final COMMIT command packet to instruct all listeners to make the new channel data active in whatever manner is appropriate) This is a little different from DMX512's ordinarily "streaming" oriented setup but I think it's flexible and should work well for other future projects. All packets with program ID 0x20-0x40 include the "Start Code" as their very first byte (and for the COMMIT command, i.e. 0x40, it's the only payload). The concept of DMX "universes" is enforced by sending the data to different nRF24L01+ 5-byte RF addresses. The listeners are expected to have AutoACK turned off so the address can act like a broadcast domain. For this code, I'm just using channels 1-3 as R, G, B data and setting all the LEDs in the strip that same value. Start Code 0x00 is used here. I've adapted my Grill Monitor's base station code to include a new "nrfdmx" CLI command that lets me configure channels 1-15 (for simplicity's sake) from a simple command. Very cool being able to login to my Linux server over SSH and changing the color of my lamp! Code for my nrfdmx implementation (including working slavenode code for the F5172 and simple sender code for the G2553, both using my nRF24L01+ boosterpacks)- https://github.com/spirilis/nrfdmx bluehash, pine, yyrkoon and 1 other 4 Quote Link to post Share on other sites
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.