Today's blog post focuses on programming. When the project was initially started a draft of Python code to control the LED's was completed. That code had to be abandoned because the controller was changed from a PI to Geekcreit Mega 2560. Before I retired, I recall how critical it is to have clearly defined requirements before starting a coding project. This project had a number of moving parts that had the potential to impact the code. A perfect example is writing the Python code in order to use a Raspberry Pi and then using a different controller. Sorry no Python on Arduino. The Python coding writing exercise wasn't a complete throw away. The coding process did provide the concept and framework of how the fireworks light display might work.

 

 

I am not a programmer. I am more of a code resurrectionist. I don't write code I reclaim code. I have sufficient programming skills to cull code from different source and kludge them together to make something work. This Arduino project put those skills to the test. My initial foray into the Arduino code, I was able to get the house keeping stuff, like pin assignments and variable definitions completed.

 

Being able to install the Mega on the perfboard used to hold the RGB LED limiting resistors created some opportunities. The resistor could be connected directly to the MEga GPIO's. I failed to realize left to right changes when the Mega board was installed. The pin locations when the Mega is face up are not in the same location when the Mega is face down. The LEDs didn't go to the correct pins. I resolved that issue, to discover board orientation is important for counting left to right or right to left for pin assignments. After four revisions of a spreadsheet pinout matrix, it was finally got it right, I think? Remember those variables I programmed. I had to update those every time I changed the matrix. Another orientation issue came as a result of the display panel. Counting positions from the back of the display is different than counting from the front of the display.  Ouch, more code revisions or you live with it. You'll see.

 

I hacked enough initial code on the Mega to light each RGBLED OFC's individually. I tested the perf board and controller by inserting an RGBLED in the connectors. I didn't use the RGBLED OFC's. You can't replaced the LED in the assembly if it is damaged because it is all superglued together. I discovered not only is left to right important for pins but top and bottom is also. My son-in-law came into my workshop while I was trying to resolve these issues and just walked out shaking his head. "You do this for fun?" was all I heard him say. I got the issues resolved so the code reflects the physical layout. I did discover two hard wired mistakes that I will need to correct once I am near a soldering iron.

 

My biggest stumbling block (I called a life-line to resolve it) was creating a programming structure to select colours, that could then be fed into a method from an RGB LED control library. Who knew an array can be constructed of arrays of values. Arrays, structures and enum are programming tools I have minimal to no understanding of. My life-line was a programmer co-worker/friend I worked with before retiring. I sent him my question and two coffees later on his end, he sent me back a "try this". IT WORKED! He also passed along the code rand()%3 which I learned was an easy way to generate a random number from 1-3. The shite you can do, when you know actually know what you are doing.

 

 

The display has six light structures made of, three burst, two light cannons and one falling stars. Each burst has three rings. Each ring has an RGB LED, the launch cannons are LED strip and the falling stars are three single colour LED's.

 

Burst 1 & burst two are preceded by the a launch cannon. Starting with the inner rings first, each burst light outwards. When burst three outer ring lights, the falling stars light. The drawing demonstrates the left to right problem I indicated earlier. From the back of the display panel burst 3 is on the right. I left the assignment rather than change the code.

 

There are seven colours supported. The colour selection for each ring RGB LED OFC is random. The burst lighting order is random. The display is triggered by a button. One complete sequence (all three bursts) takes a little over 12 seconds.

 

The code is now ready for testing. From a coding perspective there are no doubt ways to make it more efficient. When I texted my coding buddy about this his responded by saying "clarity over brevity". I kinda like both in code but for now, a major hurdle I had trepidation about working on, actually works.

 

Next steps is to see what the code looks like driving the display. I'm not sure of the falling stars. I created a light pattern with an RGB LED while I was working on the code, that I kinda liked. I don't know what it will look like on the display.

 

 

With the Mega controller mounted on the perfboard it looks like I might have sufficient room to install a DFModule. Recall there was a scope creep request was for sound. In the past I have successfully used the DFModules with Nano's. If this solution works it might be fairly easy way to incorporate the sound request. The power supply assembly I designed has both a voltage to run the Mega (12VDC) and a lower supply voltage (5VDC) for the DFModule. I had some concern regarding the 200ma current limit on the Mega considering I have close to 30 LED's.  The external PS for the DFModule removes any additional load. I'm not lighting all LED's at once so it shouldn't tax the regulator chip on the Mega. See you on the next blog post.