Neopixel library too slow?

The shape of the Digital Rothko splotches are just not fading in fast enough and things seem to really slow down in the IDE’s serial monitor. This is after I simplified the number of operations as much as possible by re-orienting them from the drawcirclemaster, drawcircle and circle functions. So then I just did basic shapes: two rectangles and four lines — should be faster, right? WRONG.

It’s simply too slow. It’s like the time it takes to do all those setPixelColor is too slow. Going to look into the FastLED Library now and see if I can build the sketch that I showed at the ITP Spring Show from it, stat.

Lag on Uploading Sketches to Arduino Due

I’ve always noticed a lag in uploading to the Arduino Due when connected to the LED board. Like, a super long delay from pressing the “upload” button to seeing anything happen in the serial monitor or on the LED board. This can be 30 seconds to minutes. I don’t know why this is. With the UNO it’s generally less than a second. The Due is the most powerful Arduino money can buy, yet it’s super slow — why?

Time calculations for figuring out color transitions in Digital Rothko.

39 seconds from “done uploading” to the following happening on the Serial monitor:


understanding getPixelColor in Neopixel Library

According to Adafruit, the function getPixelColor returns an “32-bit merged color value”

When I set it to fetch the value for a WS2812B set at 10,10,10 and println, the monitor shows the value to be 657930. This is the 32 bit merged colour value.

From an Adafruit forum discussion, I’ve learned that this number is the summation of the following formula:

(red * 65536) + (green * 256) + blue

So sub’ing in my 10,10,10 to confirm this formula:

(10* 65536) + (10 * 256) + 10 = 655360 + 2560 + 10 = 657930

Excellent. Now we’ve found bedrock.

Now question is… can I extract the RGB value just by knowing the 32BMV?

From a math standpoint, it seems like ascertaining 3 unknown variables from an equation is impossible. BUT since I am using making the yellow using only one random value and then dividing that value by 3 to make the green to mix w the red to get the yellow, it is possible. GENIUS!

Therefore, applied to Digital Rothko sketch, it becomes:

(red* 65536) + (red/3 * 256)  + 0 = 32BMV

red = 32BMV / 65621.33



Serial Understanding Experiments

The following code from

int incomingByte = 0; // for incoming serial data

void setup() {
Serial.begin(9600); // opens serial port, sets data rate to 9600 bps

void loop() {

// send data only when you receive data:
if (Serial.available() > 0) {
// read the incoming byte:
incomingByte =;

// say what you got:
Serial.print(“I received: “);
Serial.println(incomingByte, BIN);



1,2,3 leads to:

I received: 110001
I received: 110010
I received: 110011

For OCT: 61,62,63

For HEX: 31,32,33

For DEC: 49,50,51

Serial.print(x, DEC);  // print as an ASCII-encoded decimal
Serial.print(x, HEX);  // print as an ASCII-encoded hexadecimal
Serial.print(x, OCT);  // print as an ASCII-encoded octal
Serial.println(x, BIN);  // print as an ASCII-encoded binary

XYZ / Final Documentation

Note: this final XYZ documentation is written in the style of Canadian diplomatic reporting. It’s something I’ve taken from my former career and is what I turn to when I need to thoroughly explore and clarify my own thinking about something. What follows is a total account of my XYZ final.

SUMMARY: Sometimes things that start badly end well, sometimes things that start well end badly. For the Noodle of Death team, what began with enthusiasm and smiles ended in disappointment and likely broken professional relationships. The robot itself works fine and is engaging and interactive – but that only tells part of the story.


2. Re-Cap of Concept: The Noodle of Death was an idea I had based on my study of martial arts. Specifically it was based on an exercise developed by Ido Portal, who used it to develop a person’s movement capabilities, as well as based on my experiences training with pool noodles in boxing. A fun title initally suggested by Shreiya, the title was actually inappropriate to our project’s actual goal: which was to facilitate life.

3. Division of Duties and Workflow: We decided to use the Make-Block Plotter (MBP) after discussion with Ben, after consideration of other options. We agreed it would be the quickest, cheapest, easiest way. Our team was initially ahead of the other groups because of our clarity of concept and because our early experiments with the MBP had yielded successful conclusions about the way the MBP moved, as well as how the noodle would need to be secured. See below how the MBP originally moved, where we concluded that we had to put it on some kind of stiff board, secured to the ceiling rafters.

4. After this we decided to divide the workflow. I would do the noodle, Tony would do the board structure to secure the MBP to the ceiling and Shreiya would work with the G shield on the code. Comment: In hindsight, I wanted to leave XYZ with a skillset on how to use code to operate an XYZ machine. I should have made this need heard in the group and advocated for more involvement with the coding part of it. 

5. The thing came together fairly well. See below documentation of the final set up of the robot:

Final robot with board attached to speedrails, which we hung from rafters. The weight was it was adequate so that it did not move from the rafters.

Attached to the ceiling with noodle contraption. PVC pipe from Home Depot + foam insulation noodle:

The key difficulty for my part, making the “noodle of death”, was that the unit kept detaching from the stepper shaft coupler after a few rotations like this:

6. The Start Of Troubles: This is where our troubles began. I asked Shrieya to show me how to adjust the rate of the Z in order to fix the problem of the noodle falling off, but she seemed to be too busy to show me how to do this. Being busy with several other side XYZ projects, despite it being two days to the final, she did not have a simple interface where a user could control the noodle, since she still had to write the processing sketch. Therefore there was no recourse but to move it with G Code through GRBL.

7. Despite her assurances, I also did not fully trust that Shrieya would have this done on time because of subtle signals she had shown me which, in my view, was the result of insufficient communication. However, what led to corrosion of confidence was when she declined to take the time to discuss how to move the Z. It is possible that I did not articulate why I needed to move the Z and she felt that I was encroaching in her domain of responsibility, perhaps I needed to impress upon her that moving the Z was critical to my solving the problem of the noodle falling off the MBP. That possibility considered, I rule this out because I would unquestioningly help another group member if asked. For me, a basic courtesy was not shown to me, not was time given to deal with the situation. Instead, I just pushed aside. Comment: In hindsight, a timeline expectation for when each feature would be completed should have been completed and strictly adhered to.

8. I successfully figured out how to change the Z rate with GRBL G code, using the $112 command to reduce the rate from 400 to 20. This reduced the sound coming from the Stepper from a strain to something more pleasant. I found it on this GRBL feed rate website:

9. With this, the robot was complete. Shrieya did a processing sketch and we were playing around with it earlier on. That said, it was not truly “complete” since the complete version of the robot would include an interface where User would control the robot against the Player. At this point, Shrieya settled on having a processing sketch take a pre-determined set of G Code commands, which completely changes the interaction from something dynamic to something routine. However, happy that we were done enough to show the presentation, I did not raise any complaint. Here is a video of my interaction with the final robot in action a few hours before our final presentation:

10. Spring Show Let-Down: It was ultimately my fault that we didn’t get into the spring show, since I put the wrong venue option during the application process. This was unfortunate, and my group members were very displeased with me. I think, however, that some of this anger is misplaced: after all, I did send them the link an hour before submission closed (i.e. no one bothered to check it), and I find it a little unjust that admission to the show would be decided by such a technicality – especially as we did submit on time. However, I take the majority share of blame. This was disappointing but still, things went further south from here.

11. From Cracks to Fissures: From early on, Shrieya and I had a good working relationship and friendship. This friendship was the basis of our collaboration. However, from the incident with the Z feed rate fresh in my mind, Shrieya let us know she would be away from the 8th of May up until the Spring Show. In the event we got into the show, she wrote that she would just write a bunch of G code files we could cycle through on the 14th. I responded and said that I would prefer she hand the coding over to myself and Tony while she was away, and that we would continue the work in her absence. I certainly did not want a bunch of pre-programming patterns instead of an actual user interface, for the show. She responded she would be OK doing this but said that she would not be doing a P5 interface anymore. I responded by voicing, for the first time, that I found it  unacceptable that the final robot did not have even a basic user interface and that I felt she took on unnecessary side projects at the cost of this one. She did not respond to this email. A few days later, when we spoke about this to clear the air, while I don’t feel it right to document the contents on that conversation I must say that what was initially meant to be a confidence-building conversation became antagonistic and the state of relations between Shireya and I declined significantly. [Updated Comment May 14: Upon reading a book called Difficult Conversations, which talks about moving from a blame mindset to a contribution-mapping mindset, I see how both Shrieya and I contributed to the state of affairs, and I see how things could be done different. I will take these valuable lessons into the future projects.]

12. Collaboration Lessons Learned: I count the Noodle of Death as a valuable learning experience on XYZ robots but mostly on how collaboration can go wrong when expectations and roles are not clearly spelled out. While we did clearly spell out the roles, these distinctions were insufficient to the task at hand. Combined with the fact that I did not articulate my concerns earlier on (i.e. about wanting to do more coding, with shrieya’s secondary projects, with what I expected for the final interface) and combined with team members non-communicative tendencies (i.e. the Z rate incident), this whole episode is a glaring reminder that hard discussion needs to happen at all stages, and that I should see past the laughter and good times to see the structure of the interaction itself. I felt I was blinded by how amusing the noodle was and failed to the see the decay underneath. Perhaps me putting in the wrong staging area was an unconscious action that revealed my dissatisfaction with this project. In any event, we did not get into the show, but I can honestly say I don’t really feel badly about it — other than letting my group members down, Tony especially, since he did his group role admirably.

13. I recently purchased a book entitled How to Have Difficult Conversations. I will be reading it over the summer and reflect on this invaluable learning experience.

XYZ / Z axis breakthrough

using this:

I found that the $112 value in GRBL G-code controls how fast the noodle rotates. It was previously on 500, which spun way too fast for the noodle contraption. Taking it down to a value of 40 enabled it to spin without stressing the stepper or the noodle contraption.

That link also had this great super useful list of GRBL commands:

**** Connected to COM3 @ 115200 baud ****

Grbl 0.9j [‘$’ for help]
>>> $$
$0=10 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.010 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=1 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=0 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=25.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=314.960 (x, step/mm)
$101=314.960 (y, step/mm)
$102=78.740 (z, step/mm)
$110=800.000 (x max rate, mm/min)
$111=800.000 (y max rate, mm/min)
$112=350.000 (z max rate, mm/min)
$120=10.000 (x accel, mm/sec^2)
$121=10.000 (y accel, mm/sec^2)
$122=10.000 (z accel, mm/sec^2)
$130=200.000 (x max travel, mm)
$131=200.000 (y max travel, mm)
$132=200.000 (z max travel, mm)

Energy Final – 3/3

Things left to do today:

  1. program board with Timer
  2. buy Rockite, Epoxy
  3. epoxy solar panel and other electronics to interior of acrylic enclosure
  4. make wooden 3.5″x3.5″x3.5″ box, and smaller box inside from cardboard to prototype how the pouring around the acrylic enclosure will be like
  5. make several test concrete boxes before doing it for real
  6. Do it for real

Programming Board w/ Timer

The key thing for me to find out today is how using the Low Power library messes with the timing of the MCU. I know that the low power works by shutting the MCU off for several seconds. From this site, I learned about Rocketscream Electronic’s LowPower library.

I started by using the blink sketch, but using:

LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

instead of the “delay(1000);” of the traditional blink sketch. Using my phone timer, I see that it does indeed cause a delay of approx 8-8.5 seconds. (Probably in imperfect reflexes for timing it o my phone).

I also confirmed that:

LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

leads to a delay of approx 16.5-17 seconds.

This means I will need to build in this 8 second delay into my sketch.


  • 60 seconds / 8 seconds = 7.5 increments of 8S per minute
  • 7.5 x 60 minutes = 450 increments of 8S per hour
  • 450 x 12 hours = 5400 increments of 8S per 12 hours

which means a delay of 12 hours can be written as:

for (int x=0; x<5400; x++) {

LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);


To test this I will delay for one minute, which by my calculations, should be a loop of 7.5 so that:

for (int x=0; x<7; x++) {

      LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);


is about 59 seconds. (I couldn’t put 7.5 on a loop).

Using the Low Power library also means I cannot rely on the WDT (Watchdog Timer) for tracking time. Which means, I’ll have to do this purely using the 8S delay.

LED Light Plan for Dark Hours

Using the following graphic from TimeandDate, there are three phases of “getting dark” before it’s considered night: civil twilight, nautical twilight and astronomical twilight. Astronomical Twilight (AT) occurs when the Sun is between 12 degrees and 18 degrees below the horizon, when the sky is still dark but a faint change in light colour can be seen.

The LED will start it’s journey toward brightness after Dusk Astronomical Twilight and begin it’s journey toward darkness after Dawn Astronomical Twilight.

However, AT occurs at different times at different months, and also depending on Daylight Savings.

Dusk AT:

  • Jan: 5:44pm – 6:17pm
  • July: 9:45pm – 10:37pm

Dawn AT:

  • Jan: 4:11pm – 4:50pm
  • July: 3:19am – 4:10am

Since I plan to have everything encased in concrete so as to be unable to access the components, I can only set the timing once, and it has to work with the day/night cycles of all seasons.

I will start the light at 8 pm and end it at 5am – that’s 9 hours. The lighting plan for the single Neopixel shall be as follows:

8pm-9pm: 0,0,0 – 10,10,10
9pm-10pm: 11,11,11 – 20,20,20
10pm-11pm: 21,21,21 – 30,30,30
11pm-12am: 31,31,31 – 40,40,40
12am-1am: 41,41,41 – 50,50,50
1am-2am: 50,50,50 – 41,41,41
2am-3am: 40,40,40 – 25,25,25
3am-4am: 24,24,24 – 10,10,10
4am-5am: 10,10,10 – 0,0,0

Referencing my earlier calculation of: 450 increments of 8S LowPower MCU shut-down per hour, the code shall be:









Energy / Final – Day 1


The battery and Solar Li-Po Charger

With three days to the Energy final my project has hit a major snag: the Li-Po is not supplying power to the arduino. The assumption was that when not recieving solar, the load would be powered by battery… assumption wrong.

After thinking that the Adafruit Solar Li-Po charger was not meant to be used from battery to load without the presence of solar, Roland helped me out by showing me that when connected to this massive 6000 mAh battery, current does indeed flow into the load even when a solar input is not included. He offered to let me use his battery for the final, but I declined since it was too big for my purposes. I would continue the original plan and go small. However, I did learn that a 1200 mAh Li-Po was too small to be used with the Adafruit charging board.

I went to Tinkersphere to buy a new 2400 mAh Li-Po, hoping that doubling the capacity would allow the charger to be used properly. This was a hypothesis that I hope would work. The 2400 mAh Li-Po was also too big for my design (it was very thin but too large in terms of surface area) so I had the idea of buying another 1200 mAh Li-Po and wiring it in parallel with my current Li-Po. I had no idea if it would work but it did… thank God!

Reducing the current draw to a bare minimum

Because I am designing this thing with the purpose of lasting forever, and because the board needed to be ON forever, I wanted the board and LED to draw the bare minimum amount of current.

The batteries (now 2400 mAh, instead of 1200 mAh) would start fully charged and be drained most at night and hopefully be recharged during the day.

Evolving Concept & Structure

My design was heavily influenced by Amitabh’s workshop on concrete, in which he showed how to encase acrylic and LEDs in a small concrete object. The combination of light and concrete: the juxtaposition of something soft and ephemeral with something very gritty and hard was a very esthetically pleasing mix.

My design originally was for a buddha, type statue, but I designed to scale down my ambition given the complexity of the project and time constrains. The complexity of the project is from the need to encase all those electronics: a solar panel, a Li-Po charging board, 2 Li-Po batteries, a Arduino Pro Mini, a Neopixel LED and a piece of acrylic for light form — that’s a lot of stuff.

I decided upon a simple concrete cube that collect solar during the day on one end and emits light at night on the other. The cube size would only be slightly bigger than the small Adafruit solar panel, which is just over 2 inches in length. The cube would then be 3″x3″x3″.

Safety of Encasing Batteries in Concrete

I was warned by Amitahb that it was potentially dangerous to enclose batteries in concrete, since the heating of the concrete while it was hardening could cause the batteries to explode. He also warned me there is also danger that the microscopic crystal needles poking out of concrete could puncture the battery itself and cause an explosion.

Further, I am told concrete expands

I no nothing of these matters so decided to take precautions by ensuring the concrete itself does not come into contact