[Hudson] is looking to drive a lot of LEDs. A driver that effectively addresses kilometers worth of LED strips isn’t an easy thing to come by. So he’s in the process of designing his own BeagleBone Cape to do the work. Above you can see the board layout he’s working with. Notice the set of repeating red footprints in the center? Those are pads for 32 RS485 connectors!
Of course this is all in preparation for Burning Man where the mantra seems to be: he who has the most LEDs wins. Well, unless you’re the sort that likes to work with flames. But we digress. The scaling problem that [Hudson] is dealing with hinges around his desire not to include ridiculous numbers microcontrollers and the need to beef up the 3.3V logic levels of the BeagleBone to travel further on the data bus of the strips. By leveraging the RS485 protocol — which is designed to carry data over long distances — he can get away with a single processing unit by adding an RS485 translator at each remote strip connector. He plans to use the BeagleBone’s Programmable Realtime Units feature to address the eight drivers on the cape. But first he has to solve what looks like a doozy of a trace routing problem
Wanting to control a split flap display that was not near a computer [Tom] looked to a common solution for communicating over distances not practical for I2C or SPI. He developed his own hardware and packet format using the RS-485 protocol.
This is part of a larger project he has been working on to feed data to a split flap display that he plans to hang on the wall. RS-485 is designed to work over long distances and overcome noise issues. The core of the communications system is the board seen on the left. It uses a MAX1483 chip, a pair of RJ45 jacks for Ethernet cables, and two terminal blocks for power and communications. There are a few nice things about this. The board acts as a pass-through making it easy to chain nodes together, and the data structure is completely independent of the hardware itself. Because of this [Tom] developed his own packet format that will be a bit more resilient than the Arduino networking scheme we looked at the other day.
This dorm room is ready to entertain, thanks in part to the LED wall sconces that [Joseph] hacked together. Inside each fixture you’ll find three 3-Watt LED modules. For proper heat dissipation he mounted them on sheet metal which he cut out, including some fingers for additional surface area. The shape for the heat sink was chosen to fit behind the diffuser of the sconce, which is an incandescent light fixture with the socket removed.
[Joseph] designed his own control boards for the base station and LED modules. They communicate with each other via RS485, which lets him run CAT-5 cable to each, but the lights do require external power as well. The controller itself is a USB dongle which takes the serial commands from a computer and pushes them out over the RS485 protocol. In the video after the break you can get a good look at the hardware and the overall performance of the system.
Continue reading “LED sconces spice up dorm room parties”
[Diego Spinola] wrote in to tell us about a node communication system he’s been working on called HsNet. The aim is to build a system of nodes that can be made up of small and inexpensive microcontrollers. The problem is that the least expensive controllers often don’t have a hardware UART. HsNet implements the RS485 protocol using a software UART along with a slim and sleek addressing scheme.
The first module developed, seen in the image above and video after the break, is a single channel pulse-width-modulation node using a PIC 12F683. It can be sent commands in the payload of the HsNet packet format. The PWM modules accept three different commands; one is a desired PWM value, another is a delay between steps for the PWM, and the last toggles a blink function.
He has also developed an analog sensor module and an Arduino-based TCP/IC gateway module. Now that the packet communications have been established, it will be rather simple to add nodes based on that groundwork. [Diego] brought these components together to build an interactive wall which can also be seen after the break.
Continue reading “HsNet: Node communications for feature-limited microcontrollers”
[Paul] wrote in to tell us about this LED driver board he’s been working on with a few friends. The collaborators had been unhappy with the Lumens per Watt ratings (or lack of a rating) on low powered LEDs and set out to find a better solution. They picked up the beefy ASMT-MT00 which houses all three diodes in one package, with all the pins on one side of the surface mount package, a heat dissipating tab on the other side, and pushed 30 Lumens per Watt. With that in hand they set out to design a host board for the blindingly bright light.
The board includes a heat sink on the underside. To drive the LEDs [Paul] sourced an LM3407 constant current driver. The manufacture recommends using one of these chips for each of the colors in the LED package. [Paul] built a circuit that allows him to route power around each LED, making the system work with just one low-side driver. From there, an ATtiny2313 provides addressable control via the RS485 protocol. Screw terminals on either end of the PCB allow this to be chained along with other modules, and they’ve already worked out a basic PureData program that will be able to address multiple boards once they finish manufacturing them.
Here’s a serial to Ethernet module that you won’t have to write firmware to build. It uses a Lantronix XPORT module which takes care of all the work for you, including an embedded webserver. Both RS232 and RS485 data buses are connected to the XPORT serial input via a level converter to step the signal down to 3.3V. This solution comes at a price because of the ethernet module, but it would make a nice prototyping tool for testing projects that work on the two serial protocols.