-
Notifications
You must be signed in to change notification settings - Fork 0
About the System
We had a number of requirements for our circuit boards. The driver board needed three separate 1A channels which could drive 64 LEDs each, which would have an isolated system to trigger a camera shutter. The LED boards had to both sink the 5W of power from the LEDs and contain three separate colors. Since these aren't common requirements for consumer-level prototype boards, we designed custom circuit boards for this solution.
In addition, we had to wire the dome for all 192 LEDs with wiring that was modifiable but that would not compromise the lighting much. All of that had to fit in a robust and concise form-factor.
(See Schematic, further documentation)
Since not all LED colors will operate at similar amperages, we needed three constant-current drivers on one board. Beyond that, we wanted robust connectors that would handle the maximum voltages and currents our system might see and wanted isolated camera triggers. For all these needs, we created a custom driver board. This driver board was implemented as a shield for an Arduino Mega.
(See Schematic, further documentation)
The three LEDs needed to be mounted on the dome on a board that would sink much of their heat. For this, I designed another circuit board around the same size as the common star shaped boards, but capable of holding three LEDs in a common-anode configuration, just like 4-lead RGB LEDs. Electrically, this is very simple; the only challenges were in thermal considerations and creating a robust mounting and wiring design.
These boards were not designed for long-term on-time and will get very hot after a little while without any active cooling, so try not to run LEDs over 20 seconds.
(See Schematic, further documentation)
For our wiring, we chose to create a typical 3-color LED array, common in electronics in the form of RGB arrays (LED displays typically use these). While there are other configurations with lesser hardware requirements, they get extremely complex in wiring and driving, making maintenance more difficult.
(See further documentation, GUI Guide)
The code for this design was created with the goal of having an intuitive GUI for users who would be primarily non-technical. The capabilities of the code include:
- A multi-page GUI
- Running 'patterns' on the LEDs on the dome with these customizations:
- Pattern types: 'All Column' Scans (goes through each LED, moving down columns first), 'All Rings' Scans, Individual Rings, and Individual Columns.
- Skipping a certain amount LEDs to run faster scans, while keeping the LED locations balanced (ex. running every other LED)
- On-time
- Off-time
- A 'profile' system for the above settings, stored in non-volatile memory.
- Allows the user to pick a profile and run immediately when choosing the above settings.
- Three profiles for each individual scan type, 12 total.
- Custom names (see below)
- 'Usable' LED configurations, stored in non-volatile memory.
- Stores the three LED array configurations so that if only half an array is actually populated, the system knows about the missing LEDs and can account for them when running scans.
- Shutter controls, stored in non-volatile memory.
- Multiple settings: delay time before triggering, Active level for shutter (high/low), on time
- 8 shutter profiles for storing shutter settings, similar to the LED settings profiles above.
- Custom names (see below)
- Non-volatile storage for all convenience settings, including:
- Serial baud rate
- Default color channel
- Touch position calibration
- Diagnostics mode
- Linkable shutters, allowing for all colors to trigger all shutters, instead of individual channel shutters.
- Custom names for all the above profiles and for channel colors, set with a GUI touch keyboard so the user doesn't need additional parts.