NeoPixel Bike Light

Thu, 29 Oct 2020

Imagine a bicycle with flickering strips of them, sliding along foggy Carrboro roads at night like a bioluminescent deep-sea cephalopod!

That's what I said when I first got started with the NeoPixel ring. Well, we also have a 60-pixel strip. This is an opportunity to learn some electrical engineering, develop some cool neopixel effects, and keep me illuminated while I'm biking around at night.

The first step was to lift the control circuit off the breadboard and onto a more permanent printed circuit board. This was my first experience with the process of PCB design and fabrication, so I spent a lot of time watching the DigiKey guide to KiCad software. The PCBs were printed in a facility and we have several copies now, which will be helpful for the next project of this sort.

I don't want a monotonous light pattern; I want to be able so select among them. So, I need at least one button to increment the pattern program. While we're adding control buttons, let's add another - this will act as a second discrete control. Might as well add two potentiometers to act as continuous analog controls. The rest of the circuit follows the adafruit uberguide. Finally, there's a global power on/off switch.

The code framework for the arduino is pretty straight forward: There's variable and pin initialization and the interface with the neopixel strip is set up. One detail is that, to override the pattern loop, the button pins are set as interrupts. I don't fully understand this! I am also not following best-use advice, because I can't get it to work correctly.


  #include <Adafruit_NeoPixel.h>
  #define PIN 6
  #define NUM_LEDS 60
  Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LEDS, PIN, NEO_GRB + NEO_KHZ800);

  //dial one, PROG
  const int analogInPin0 = A0;  // Analog input pin that the potentiometer is attached to

  //dial two, SETT
  const int analogInPin1 = A1;  // Analog input pin that the potentiometer is attached to

  const byte ledPin = 12;
  const byte interruptPin = 2;
  const byte interruptPin_sec = 3;
  volatile byte state = HIGH;

  int arr = 0;
  int gee = 0;
  int bee = 0;


  int sensorValue = 0;        // value read from the pot
  int outputValue = 0;        // analog reading

  volatile int prog = 0;
  volatile int setting = 0;

  int mod = 5; //number of programs to switch between

  void setup() {

    strip.begin();
    strip.show(); // Initialize all pixels to 'off'
    strip.setBrightness(25);

    pinMode(interruptPin, INPUT_PULLUP);
    attachInterrupt(0, blink, RISING);
    pinMode(interruptPin_sec, INPUT_PULLUP);
    attachInterrupt(1, wink, RISING);

  }

  void loop() {

    switch(prog % mod){

      case 0:
        nightVision();
        break;

      case 1:
        arr = random(255);
        gee = random(255-arr);
        bee = 255-arr-gee;
        Twinkle(arr,gee,bee);
        break;

      case 2:
        blaster( );
        break;

      case 3:
        switch(setting % 2){
          case 0:
            Strobe(255,0,0,random(3));
            Strobe(0,255,0,random(3));
            Strobe(0,0,255,random(3));
            break;
          case 1:
            arr = random(255);
            gee = random(255-arr);
            bee = 255-arr-gee;
            Strobe(arr,gee,bee,3);
            break;
        };break;

      case 4:
        switch(setting % 2){
          case 0:
            rainbowCycle();
          break;
          case 1:
            VaporWave();
          break;
        };break;

      default:
      break;
    }
}

  void blink() {
    state = !state;
    prog = (prog+1)%mod;
  }

  void wink() {
    state = !state;
    setting +=1;
  }

The sketch above outlines the implementation: a counter called prog is kept, and when the first button is pressed, it is incremented; this is used to track which light pattern is selected. This happens in the switch/case tree in the loop() function, where a function like nightVision or Twinkle is run depending upon the modulus of the prog count.


void nightVision(){
    for(int j=0; j%lt; 10; j++){
    sensorValue = analogRead(analogInPin0);
    int intensity = map(sensorValue, 0, 1023,16, 255);
    setAll(intensity, 0, 0);
    showStrip();
    delay(50);
    if (state){  state = !state;break;};
  }
}

Here's the first program, a simple dimmable red that will be easy on the night vision when you first turn the unit on. The reading from one of the potentiometers is mapped to a value for the red channel of the RGB light. One subtlety is the for loop and the if-break routine. The state variable is set to True when either of the buttons are pressed. This exits from the nightVision() function, and the loop() moves to the next iteration. This is how we switch color patterns with a button press.


void Twinkle(byte red, byte green, byte blue){
  sensorValue = analogRead(analogInPin1);
  int twinkleCount = map(sensorValue, 0, 1023, 1, 32);

  for (int i=0; i %lt; twinkleCount; i++){
    setPixel(random(NUM_LEDS), red, green, blue);
    showStrip();
    sensorValue = analogRead(analogInPin0);
    int twinkleDelay = map(sensorValue, 0, 1023, 1, 50);
    delay(twinkleDelay);
    if (state){  state = !state;break;};
    }
  if(setting%2==0 ){
    setAll(0,0,0);
  }
}

This project was partly inspired by this HackADay-featured collection of effects, and the next program in the queue, Twinkle, is based directly on one of theirs. The core of the Twinkle function is the repeated setPixel(random(NUM_LEDS), ...) call, which assigns a given color to a random LED each time it's invoked. On top of the original core, there are some modifications: the time between individual sparkles (twinkleDelay) is set by the first potentiometer. The actual number of the sparkles (twinkleCount) is set by the other potentiometer. This pattern also makes use of the second button to toggle whether the strip is blanked (ie, all pixels set to 0). If the second button is pressed, this is turned off. The pixel stays at its last set color until it is randomly overwritten.

To keep things interesting, the Twinkle function is called with a random color with each pass of loop(). Originally this was implemented by calling a random number between 0 and 255 independently for each of the red, green, and blue channels. This works well enough, but the palette it generates tends to be more pastel than I'd necessarily like. To make the colors more vivid, random colors were generated here by assuming that there are 255 total color points to assign, and distributing them randomly across the three channels.


   case 2:
      if(setting % 2 == 0){
        rainbowCycle();
        break;
       }
      if(setting % 2 == 1){
        VaporWave(50);
        break;
      }
      break;
//  ....


void VaporWave(int WaveDelay){
  int Position=0;
  for (int j=0; j %lt; NUM_LEDS*2; j++){
    Position++;
    for(int i = 0; i %lt; NUM_LEDS; i++){
      setPixel(i, (sin((i+Position)*180/3.14)*127+128), 0, 127);
      showStrip();
    }
  outputValue = map(sensorValue, 0, 1023, 0, WaveDelay);
    if (state){  state = !state;break;};
      delay(outputValue);
  }
}

The next program is a pair of cycling color routines. The first was a rainbow cycle adapted from an example script from the adafruit NeoPixel library, modified to have the cycle speed controlled by the first potentiometer. The other one, VaporWave, is an original of mine. Each pixel has its blue channel set to 127 of 255, and it's green channel set to 0. Then, the red channel is set according to a sine wave with a maximum of 255 and a minimum of 0.



    case 3:
      switch(setting % 2){
        case 0:
          Strobe(255,0,0,random(3));
          Strobe(0,255,0,random(3));
          Strobe(0,0,255,random(3));
          break;
        case 1:
          for (int i = 0; i%lt;3; i ++ ){
            arr = random(255);
            gee = random(255-arr);
            bee = 255-arr-gee;
            Strobe(arr,gee,bee,3);
          }
    break;
  }

// ...

void Strobe(byte red, byte green, byte blue, int StrobeCount){
  sensorValue = analogRead(analogInPin0);
  int FlashDelay = map(sensorValue, 0, 1023, 50, 250);
  for(int j=0; j%lt; StrobeCount; j++){
    setAll(red, green, blue);
    showStrip();
    delay(FlashDelay);
    setAll(0,0,0);
    showStrip();
    delay(FlashDelay);
    if (state){  state = !state;break;};
  }
delay(FlashDelay*2);
}

The next pattern is also a modification of a tweaking4all routine, which accepts a color and flashes it several times. A potentiometer read controls the rate of the flashing, and the setting button toggles between two schemes: in the first, red green and blue are each flashed a random number of times; in the second, a random color is flashed three times.


    case 4:
      blaster();
    break;
//  ...

void blaster( ){
  for(int j=0; j%lt; 10; j++){

  sensorValue = analogRead(analogInPin0);
  int interval = map(sensorValue, 0, 1023,1, NUM_LEDS/4);

  int red = 0;
  int green = 0;
  int blue = 0;
  int col = random(1,4);
  if (col==1){
    red = 255;
  }
  else if (col==2){
    blue = 255;
  }
  else{
    green = 255;
  }

  int StartPoint = random(1, NUM_LEDS);

  for( int i = 0; i %lt; interval; i++){
    setPixel((StartPoint + i)%NUM_LEDS, red, green, blue);
  }

  showStrip();
  sensorValue = analogRead(analogInPin1);
  int blastDelay = map(sensorValue, 0, 1023,15, 1000);
  delay(blastDelay);
    if(setting%2==0 ){
      setAll(0,0,0);
    }
    if (state){  state = !state;break;};
    }
}

This last pattern is a heavily modified version of the tweaking4all Cylon program. In each cycle, a potentiometer is read and the result converted into an interval length. A random color is chosen from among red only, blue only, and green only. A point on the chain is selected at random, the next several pixels are colored. The actual number, interval, is controlled by one potentiometer; the other controls blastDelay, which determines the wait time until the next block is written. The overall effect is of random chunks of light flashing off and on. This routine also makes use of the setting button, which toggles the end-of-loop blanking. When this is turned off, the colored bars pile up on each other, like a chunkier version of the Twinkle effect.

The circuits were wired up, and the whole thing put in a mostly water-tight container, including a vinyl tube to house the NeoPixel strip. Right now the lights are just sort of wrapped around the bike like a rope. This works well enough, but a future modification will probably break the strip into subsegments with specific locations on the bike, such as horizontal strips on the sides and vertical ones on the front/back. This change of topology will require some rethinking of how the pixels are addressed, but it will also permit new patterns. For example, with pixels arranged in space rather than just sequence, you could create a consistent gradient. Putting blue at the front of the bike and red in the back would simulate the doppler effect of an object moving at relativistic speeds, with the intensity of the redshift controlled by potentiometer.

Hacking in a Time of Coronavirus

Sun, 19 Apr 2020

Society is reeling from the twin crises of a brtual coronavirus pandemic and an economic kernel panic. How have hackers and makers been stepping up to the challenge?

at the Recybery

Making bleach

With store shelves empty of essentials like cleaning supplies, it's time to look around for a way to make them from scratch. Here's one example: washing soda (sodium carbonate) is added to swimming pool chlorinating granules (calcium hypochlorite). Chalk powder (calcium carbonate) precipitates, leaving liquid bleach (sodium hypochlorite) to be decanted off.

Ca(ClO)₂(aq) + Na₂CO₃(aq) → CaCO₃(s) + 2NaClO(aq)

Our first run at the Recybery yielded five and a half gallons of 6% bleach! They were donated to groups like the local Food Not Bombs chapter.

Sewing face masks

Supplies of N95 masks have been exhausted by medical demand; fortunately, cloth masks are easy to make! They function primarily to filter small droplets that spray when we cough, talk, and breath. Because these droplets can transmit the virus, the CDC has recently recommended the use of cloth masks in public, even providing instructions for making your own. (When the feds are offering clever lifehacks by way of public health assistance, you might be living in a failed state!) A recent study under review found that, as a complement to other strategies, "The preponderance of evidence indicates that mask wearing reduces the transmissibility per contact by reducing transmission of infected droplets in both laboratory and clinical contexts." Suffice to say, the Singer Featherweight has been running full tilt! We've been using the "Masks of Love" pattern . We ran out of cloth for a moment, but thanks to a generous donation from CommunityWorx Thrift Store, we're back up and running!

Folding At Home

One of the first things the Recybery worked on was crunching numbers for distributed scientific computing through BOINC. FoldingAtHome is one such distributed computing project; it runs protein dynamic simulations for biomedical researchers, and has recently taken on COVID-19 reseach, looking for therapeutic targets. Our computer is contributing to the HackADay team - check out our stats!

and Beyond

Here's a few of the things that are going on elsewhere:

Faceshields from UNC BEAM

Medical workers have found themselves without protective face shields - the university makerspace, BEAM, has stepped in to fabricate them by the hundred, while maintaining protocols for working safely during a pandemic! We gave them a gallon of bleach so they could keep running.

Triangle mutual aid

You might have seen portable handwashing stations popping up around town - they're a project of Triangle Mutual Aid and Bonneville Electric. They're following the build instructions found here.

Misc 3D Prints

The NIH is maintaining a library of community-sourced 3D prints specifically useful during this crisis. Examples include headbands for face shields and plastic clips to connect face mask straps to (thus protecting the ears)

___

"My novella “The Masque of the Red Death” is a tribute to Poe; it’s from my book Radicalized.
It’s the story of a plute who brings his pals to his luxury bunker during civlizational collapse
in the expectation of emerging once others have rebuilt ... And naturally – for anyone who’s 
read Poe – it doesn’t work out for them. They discover that humanity has a shared microbial destiny
and that you can’t shoot germs. That every catastrophe must be answered with solidarity, not
selfishness, if it is to be survived."
-Corey Doctorow

Really Really Free Market, 2 February 2019

Sat, 02 Feb 2019

The Really Really Free Market is this weekend, so we're going to show up with the NeoPixel ring we've been experimenting with. There's code written for rainbow chaser lights written, with adjustable speed and direction, so we'll let people turn the potentiometer and press the button for free and talk to them about electronics and computer code.

Office Hours, 26 January 2019

Sat, 26 Jan 2019

We're going to try out the "office hours" model for meetings, in which we show up and do orginizational work in an open and informal setting, with others welcome to watch or talk about the Recybery. If that sounds interesting to you, we'll be trying it out on Saturday, 12 Jan 2019. Charlie will be at Open Eye Cafe from 4 to 6pm. Some things we might be doing:

NeoPixel Ring Projects

push v1 to github
write up v1 for website
work on v2
work on clock (find working RTC?)

Environmental Monitoring Project

update project page

Updating IRC bot
Future Events

2 Feb 2019: Bring NeoPixel?
Next office hours?
History of computing by J?

Report back! We managed to get a project page and a github repo started for the NeoPixel ring! These will be good resources to have handy when we bring the arduino and neopixels out to the Really Free Market next weekend.

Fun with a NeoPixel Ring

Sat, 26 Jan 2019

NeoPixels are a variety of addressable multicolored LEDs, meaning that their color and brightness can be programmed by a microcontroller like an Arduino. This can support some stunning cyberpunk aesthetics, like this wig or this umbrella. Imagine a bicycle with flickering strips of them, sliding along foggy Carrboro roads at night like a bioluminescent deep-sea cephalopod!

We're going to start off learning on a 12-LED NeoPixel ring. Here's a few projects that we're looking at:

Generic NeoPixel Exercises
1. Wiring to Arduino
Circular Topology
1. Chasing Rainbow
2. Tunable Chasing Rainbow
3. Trigger-Reversible Chasing Rainbow
4. Dial-Reversible Chasing Rainbow
Modulo 12
1. Analog Clock
2. Groups and Greatest Common Factors

There's a github repo for these projects, too!

Generic Exercises

Wiring can be a little tricky, with improper wiring sometimes causing weird flickering behavior! this glitchiness can be fun to watch for a little bit, but it's hard to develop with this unpredicable behavior interfering. Proper grounding seems to be key here. There's a wiring guide at Adafruit. A little solder and we're ready to go!

Circular Topology

The NeoPixels are addressable, which means that each one is given a unique integer to identify it. Here's this idea in practice, from an example script:

// Fill the dots one after the other with a color void colorWipe(uint32_t c, uint8_t wait) { for(uint16_t i=0; i<strip.numPixels(); i++) { strip.setPixelColor(i, c); strip.show(); delay(wait); } } This arduino function acccepts a color c. Using a for loop, it then sets each pixel i to have color c in sequence: first pixel #0, then pixel #1, then pixel #2.... all the way up to the total number of pixels in the device. (The rest of the function updates the hardware and controls the speed). In other words, while one might separate the neopixels and arbitrarily arrange them in 3-space, the software still views them as standing in an ordered, single file line. The specifics of the code can add some extra structure, and the ring shape suggests a natural addition, which is to treat the last pixel in sequence as standing one unit before the first pixel, such that propagating behavior like chaser lights "wrap around" when it reaches the end of the series. A simple implementation of this uses a math and computing concept called modular arithmetic.

Modulo 12

This ring has 12 lights in it, which means that we can do some interesting things that we might not with a different number. One has to do with timekeeping, which splits time into 12-hour half-days, 60-minute hours, and 60-second minutes (sixty being twelve times five). The twelve pixels arranged in a circle might form a familiar clockface, with color being used to differentiate between hour, minute, and second markers.

We might also use the 12 lights to illustrate some facts about abstract algebra: The circular arrangement of lights can illustrate how numbers coprime to 12 (ie those which don't share a greatest common denominator: 1,5,7,11) generate the whole 12-member group under modular addition, while numbers which share a divisor with 12 (ie, 2,3,4,6,8,9,10) generate a subgroup with order equal to twelve divided by the common divisor.

Building a Jacob's Ladder: A High-Voltage Electricity Project

Sat, 30 Jun 2018

Charlie found an old neon-sign transformer, and it gave off a mains hum when plugged in, a promising start. This is probably going to power all manner of high-voltage mischief, but we're going to begin simple and easy and build a Jacob's Ladder.. You've probably seen these in movies like Frankenstein: two stiff wires like a rabbit-ears antenna, with an electrical arc repeatedly igniting, traveling upwards, and extinguishing. No mad scientists' lab is complete without one, so let's get started!

"Sometimes, ya gotta build a Faraday cage." - Bobby

The first thing to do is build a Faraday cage. This is a conductive mesh which surrounds a source of electromagnetic fields, preventing their transmission. (The Tenth Doctor once used a double-decker bus as a Faraday cage to safely travel through a wormhole.) This is important, because electrical arcs like these sometimes generate radio emissions which can interfere with local stations and wifi, as well as piss off the FCC. It also acts as a more mundane barrier, to keep people from physically brushing against the live wires or have a dangling metal necklace drift into the arc. We used chicken wire, wrapped around a frame built out of the skeleton of a former garden greenhouse:

A second important general safety point is that electrical arcs are energetic enough to oxidize atmospheric nitrogen, forming poisonous nitrogen oxides as well as ozone. (Lightning is one source of naturally occurring 'fixed' nitrogen.) This machine won't be continuously running long enough for this to be a major concern, but ventilation is still important.

Control Panel

The next step is to wire up a control box in between the wall and the transformer. The light switch is a master shutoff, hidden under a cigar box. Built into the box is a momentary push-button switch, wired in series: when pressed, it will complete the circuit for as long as it is held down. This is also a safety consideration: this way, the machine can not be left unattended, and if the operator is injured, it will automatically shut off.

Spark Gap

Once the switchboard is wired to the transformer, we need a place to connect the high-voltage wires and to hold the spark gap itself. This was built from a 2x4, a couple of hex bolts, nuts, and washers; the rabbit ears were fashioned out of coat hangers. This is on the high-voltage side of the transformer, so it's important to use well-insulated wires and keep them well-separated. We used heavy-duty toaster wire but it would still form a coronal discharge if they got too close!

This has worked well enough, but it's not ideal, since the arc is hot and the wood is flammable. Electrical engineer and hobbyist Bill Beatty explains:

While it's possible to build these devices with wooden supports, you run the risk of starting a fire should the spark decide to jump through the wood instead of through the air. Also, the arc/flame tends to make the metal hot, even though the current is pretty low in the vertical rods. Ceramic insulators and fireproof glass/metal construction materials are best.

But, with a fire extinguisher ready, let's put it all together and watch it go!

In Operation

A final safety point is ultraviolet light, which the electrical arc can release. It's probably best not to stare at it for too long. But, it taught us something new: the hot glue used to hold the bolts in the 2x4 is fluorescent!

/etc/

Parts and supplies that we didn't find laying around came from Fitch Lumber.

Controlling an Etch-a-Sketch with Two Stepper Motors

Sun, 08 Apr 2018

The Etch-a-Sketch is a classic toy, in which two knobs are used to independently control the horizontal and vertical movement of a pointed, which removes a dust coating from a plastic screen, leaving a semi-permentant trace. What if we attach stepper motors to the knobs and control them by computer, instead of by hand? There's several possible applications; one particularly well-suited to the Etch-a-Sketch is generative art based upon Lindenmeyer systems. These are often continuous, connected lines (the Etch-a-Sketch can not lift its pen up and down) and describe interesting patterns such as fractals and plant shapes.

This is fun, and also illustrates the principles behind automated production tools like CNC machines, laser cutters, and 3D printers.

Right now, the dials are controlled by 28BYJ-48 stepper motors and the standard driver library. Rubber bands worked pretty well as drive belts, but they were too elastic to transmit fine changes and tended to slip on the smooth posts of the toy. An alternative scheme uses gears instead and has the advantage that the ratio of motor turns to dial turns can be adjusted. These gears were designed in openSCAD using this gear generating library , and 3D printed at UNC-BEAM:

The gears probably need to be redesigned with smaller radii and finer teeth, but this set up is working well enough to test out some basic routines. for example, this loop draws horizontal and vertical lines alternately. With each pass of the loop, the size of each line drawn is scaled up by a factor of 1.1; the sign, corresponding to the direction of travel, is also reversed.


void setup(){
  hSteps  = STEPS_PER_OUTPUT_REVOLUTION / 2 ;
  vSteps  = STEPS_PER_OUTPUT_REVOLUTION / 2;
  horiz_stepper.setSpeed(500); 
  vert_stepper.setSpeed(500);  
}

void loop(){
  horiz_stepper.step(hSteps);
  hSteps *= -1.1;
  vert_stepper.step(vSteps);
  vSteps *= -1.1;
}

Since each line segment starts where the last one ends, this draws a spiral expanding outwards. Varying the scaling of the two line sizes can create a variety of patterns. Setting different (negative) scaling rates for the horizontal and vertical will give rectanglular spirals with different aspect ratios. If the scaling rates are between -1 and 0 exclusive, the spiral will contract inward rather than expand outwards. If one of the rates is positive, a square-wave pattern will be produced; if both are positive, it will produce a staircase.

Here's a few similar projects:

Arduino-based Environmental Monitoring

Mon, 15 Jan 2018

One of Charlie's interests is remote sensing and environmental monitoring; there are several interesting applications:

gathering ecological data, such as the meteorological (temperature, humidity), the biological (animal noises), and the anthropological (light pollution from encroaching development). You can read some more about this here at Charlie's blog or at this archived ArkFab post.
Monitoring and automation of food production facilities, such as mycoponics and aquaponics, greenhouses, and apiaries.
Smart homes

This project aims to build a basic platform for monitoring the local environment, and ultimately build greenhouse and beehive monitors.

Jan 2018

Adafruit provides combined temperature and humidity sensors, the DHT series. Although we have one of the nicer DHT22 sensors, let's start off using the less expensive (though less precise and more limited) DHT11.

One quantity that might be interesting to measure is the difference in temperature and humidity between a controlled environment like a greenhouse, and a reference environment, like the outdoors. To measure this, it'll be important to compare the two sensors under identical conditions, to get an idea of the bias and noise between them.

For monitoring light levels, we'll start off using CdS-based photoresistors.

Eventually, it'll be good to look into WiFi and SD card shields for data logging and solar-powered battery packs for long-term, remote operation.

For beehive monitoring, we'll also want to get a scale with digital strain sensors.

Feb 2018

Here's a github repository to track the project's code and data:

https://github.com/Recybery/basic_environmental_monitoring

Here's about a day's worth of data from a single DHT11 sensor, some distance from a heat duct but in its direct path:

Clock time is the horizontal axis; the upper pane tracks relative humidity in percent, and the lower pane tracks temperature in degrees celcius. Much of the variation is due to an oscillation of about 30 minutes, with the sensor cooling and growing more humid until a spike of hot, dry air appears. This is the furnace cycling on and off. During the afternoon, the oscillations stop, but the temperature continues to drop. This is because the thermostat is in the living room, which gets direct sun; the sensor was in a rear room which is shaded. The living room stayed warm enough to keep from tripping the thermostat while the rear room, separated with a closed door, cooled.

There are lower-frequency changes too; the step-change in both temperature and humidity on midnight of the second day corresponds to a rainstorm arriving, for example.

Sometimes we'll want to record two different sets of measurements. For example, taking temperature measurements inside a greenhouse and comparing them to an external reference temperature will establish how much warmer the greenhouse is than the outside. Even when one measurement is being taken, it's good to have an idea of the inter-instrument variation. Here's a time series of temperature and humidity, taken simulatenously with two DHT11 sensors sitting side by side:

This shows a similar pattern as before, with warm, dry days and high-frequency signal from the furnace on the cool nights. It's also clear that there is an offset between the two sensors, both for the temperature and the humidity measurements. It looks as though the offset is smaller in the humidity signal, compared to the variation. We can explore this relative bias between the two sensors by subtracting one reading from the other, to generate new time series consisting of the difference between sensors. Here the difference in temperature and humidity readings are plotted over time, with hour of the day represented using color:

Looking at the difference between sensors (top two facets), there is a clear relationship between the inter-sensor bias and the furnace behavior. During the day (approx. 10AM to 6 PM), regular furnace cycling stops and the difference in temperature measurement between the sensors settles on a consistent -1 C. When the furnace begins cycling, the temperature difference begins fluctuating as well, between the reexisting -1 and 0 C. However, the fluctuation in temperature discrepancy has a greater frequency than the oscillation of temperature itself, suggesting it's not just the furnace cycle driving it.

Humidity has a more complicated behavior: with the furnace cycling, the humidity difference varies between -1 and -2 percent between the two sensors. When the furnace stops cycling in the midday, the discrepancy jumps to almost 0 between them, then slowly relaxes back to the previous offset by the time the furnace cycle resumes.

cereal=$1
#e.g., /dev/ttyACM1
phial_out=$2
ttylog -b 9600 -d "$cereal" -f |  ts '%Y-%m-%d	%H:%M:%S' | tee "$phial_out"

Here's some of the details of the code: the DHT11 and library report the measurements directly, which the Arduino reports to the serial port. Computerside, the above bash script monitors the serial port with ttylog. In the wild, timestamping would happen Arduino-side; here it was accomplished by piping the serial port output through the moreutils ts command before storing.

Another design aspect is the sampling structure. Here's the Arduino code responsible:

int burst = 0; int replicate_number = 5; // how many replicates per burst int rep_delay = 2; // how many delayMS units to wait between replicates int burst_delay = 60; // how many seconds between measurements void loop() { for (int counter = 0; counter < replicate_number; counter++){ // Delay between replicates delay(delayMS*rep_delay); // Get temperature event and print its value. sensors_event_t event; dht.temperature().getEvent(&event); Serial.print(burst); Serial.print(" "); Serial.print(counter); Serial.print(" "); Serial.print(event.temperature); Serial.print(" "); dht.humidity().getEvent(&event); Serial.print(event.relative_humidity); Serial.println(" "); } burst += 1; delay(burst_delay); }

The environment is sampled with an interval ofburst_delay seconds; each sampling consists of replicate_number measurements, with a delay of rep_delay minimum delay units. The loop() function keeps a running count of the burst number, and a rolling count of the counter number, both of which are reported alongside the sensor readings. After some minor munging, the data looks something like this:

date time burst replicate temp hum 2018-02-03 03:09:43 0 0 28.00 18.00 2018-02-03 03:09:45 0 1 29.00 18.00 2018-02-03 03:09:47 0 2 29.00 18.00 2018-02-03 03:09:50 0 3 29.00 18.00 2018-02-03 03:09:52 0 4 29.00 18.00 2018-02-03 03:10:24 1 0 29.00 18.00 2018-02-03 03:10:26 1 1 30.00 15.00 2018-02-03 03:10:29 1 2 30.00 15.00 2018-02-03 03:10:31 1 3 30.00 15.00 2018-02-03 03:10:33 1 4 30.00 15.00 2018-02-03 03:11:06 2 0 30.00 14.00 2018-02-03 03:11:08 2 1 31.00 13.00 2018-02-03 03:11:10 2 2 31.00 13.00 2018-02-03 03:11:12 2 3 31.00 13.00 2018-02-03 03:11:15 2 4 31.00 12.00 ...

Once in this form, the data is ready to be processed through the tidyr framework. For example, the date and and time can be merged into a temporal object using the lubridate:

single_sensor_test <- data.frame(single_sensor_test) single_sensor_test$date<- ymd(single_sensor_test$date) single_sensor_test$time<- hms(single_sensor_test$time) single_sensor_test$dateTime <- single_sensor_test$date + single_sensor_test$time single_sensor_test$dateTime<- as.POSIXct(single_sensor_test$dateTime)

The five replicates in each burst can be easily summarized using dplyr's group_by and summarize:

single_sensor_test.summarized <- single_sensor_test %>% group_by(burst) %>% summarize(meanTime = mean(dateTime), meanTempC = mean(tempC), meanRelHum=mean(relHum))

There are a few reasons to take measurements this way, rather than constantly sampling or taking single samples. The first method could be inefficient at high sampling frequency, requiring large storage space for redundant data. Single samples, on the other hand, might result in a noisier signal, since instrumental variability wouldn't get averaged out at all. Another potential advantage is the counterintuitive fact that repeated sampling can give an estimate with a higher precision than that of the measurements themselves.

As long as we're adding sensors, we might want to monitor light levels as well. A simple approach is to use a standard CdS photoresistor with a constant voltage and measure the remainder on an analog-in pin. Here, the trace is plotted on a background shaded to indicate the ambient temperature. When light strikes the CdS cell, its resistance drops, and it registers a higher value on the analog pin. In the dark, the resistance is high, and the reading at the pin is low. The diurnal cycle in both temperature and luminosity is thus visible:

This seems to work well at distinguishing between moderate levels of lighting, but it might not be good for distinguishing low levels (like the difference between a full and a new moon) or small differences (like changes in cloud cover over the course of a day). A more advanced option might be the TSL2591 sensor.

July 2019

A lot of work has been going on behind the scenes on this project, but I've been waiting to get a decent dataset for measuring scale drift before posting here. Along the way, this has meant:

moving time-stamping off of the computer-side serial connection and onto the board itself using an RTC module
using on-board USB logging, eventually turning to a logging shield
adding a weight sensor using a repurposed bathroom scale
experimenting with mobile power supplies

That last item is still troublesome! It would have been nice if it could use the inexpensive, waterproof solar chargers you can get for phones. Unfortunately, it looks like the model I tried has a minimum power-draw requirement, before it would shut down. If the Arduino goes to sleep (as intended, to save battery), it doesn't draw enough to keep the supply on! It looks like this might need a custom-built power supply after all, but it's weird to be in a situation where the problem is that the power consumption is too small!

The logger was run for about a week and a half at a sampling frequency of about 5 minutes, with six replicates per sample burst. A known weight (1 gallon of water = 8.34 lb = 3.785 kg) was placed on the scale. The purpose was primarily to get information on how the scale's measurement of a constant weight would fluctuate. Instrumental drift is apparently a concern when the load cells of the scale are used continuously for long periods. Once the replicates are averaged into burst values, the weight measurements look like this:

Scaled to their range, the weight measurents are relatively steady: there is the step-up at the start of the time series, when the gallon jug of water was placed on the tared scale. There are also a very small number of transient spikes into values higher by a factor of 3. It's not obvious where these are coming from. They appear to be distributed evenly throughout the day: > inner_join(timeLapse, timeLapse.summarized %>% filter(meanWt >5) %>% select(burst), by = c("burst"="burst")) %>% select(date) %>% summary() date Min. :2019-06-26 1st Qu.:2019-06-26 Median :2019-06-30 Mean :2019-06-30 3rd Qu.:2019-07-04 Max. :2019-07-06 >inner_join(timeLapse, timeLapse.summarized %>% filter(meanWt >5) %>% select(burst), by = c("burst"="burst")) %>% select(time) %>% summary() time Min. :1M 0S 1st Qu.:3H 0M 55.75S Median :8H 11M 26.5S Mean :9H 16M 30.32S 3rd Qu.:13H 22M 17.25S Max. :23H 17M 55S

Looking at the raw data, it appears that these spikes are caused by individual bad replicates within a measurement burst. These can be excluded, and the average value calculated on the "good" replicates. This means that we can still rescue a reasonable data point from a burst with a bad replicate, although the measurement will have a smaller sample size. Most mysteriously, the bad replicates are not evenly distributed among the measurements taken, but only occur in the third and fifth measurements in a burst!

Although these spikes are extreme, there are very few of them. In fact, of 2800 averaged measurements, only 18 (~0.6%) were such obvious outliers. When filtered to remove them, and the initially empty scale, we get a periodic oscillation of measured weight, mostly between 3.7 and 3.8 kg, with excusrions as far as 3.6 or 3.9. The raw data have also been included, which fall into discrete 0.1 kg increments, and have been colored with their measured temperature to indicate a likely culprit: many electronic devices change their behavior slightly with temperature. As we continue working on this project, a goal will be finding a model to correct the measured weight based on measured temperature. All in all though, this is reassuring: there doesn't seem to be a lot of unmanageable instrumental drift on the scale of days-to-weeks!

Solar Powered Death Ray

Tue, 30 Aug 2016

Hack-A-Day featured Charlie's solar furnace! It was built out of an old DirecTV satellite dish found in the woods, a couple hundred mirror chips, and a lot of hot glue. Measurements taken show that it can deliver almost 50 Watts at maximum power, and a power flux of 45 kilowatts per square meter at its focus. This can easily ignite paper and cloth, burn through wood, and boil water.

Mark helped take the furnace out to the Really Free Market, where we showed it around and generally got everyone revved up about renewable energy.

If you're interested, check out the build video and the technical details.

Security Software Workshop

Sat, 12 Dec 2015

Date finalized - 12 December, 3 PM, Internationalist Books

Want to learn about computer security? Check out this workshop! Presenters will take a piece of software relevant to computer security, like nmap or wireshark, and give a tour of its use. A topic list is on its way; the tentative date is Saturday, 5 December.

Here's a list of topics and the people presenting. If you see something that's interesting to you, and you'd like to do a presentation, if you have a topic of your own you're interested in, or if you have questions, send us an email!

General

TOR
I2P
Syndie
CJDNS

Disk encryption

ENCFS
PGP/GPG - Nick

Chat/email encryption

PGP/GPG - Nick
Pidgin / OTR
Jitsi

Exploit detection / mitigation

TripWire
AIDE

Network intrusion detection

Snort
Bro
Suricata

Network analysis / forensics

NMap - Charlie
Wireshark - John
Scapy

System vulnerability analysis / exploitation

Metasploit
OpenVAS
Nessus

Web vulnerability analysis

Nikto
W3AF

Code debuging

IDA pro
Immunity Debugger
WinDBg

Disk forensics

Maltego
Sleuth Kit
EnCase

Memory forensics

WinDBG
Volatility

Coding Challenge Day

Sat, 21 Nov 2015

We had so much fun at our Perl coding day that we decided to have another one! To keep things interesting, the language we're using will be announced at the event. Nick is going to come up with a list of coding challenges that we'll tackle with cooperation and friendly competition!

The coding day will be 3-5 PM, Saturday, 21 November, at Internationalist Books in Carrboro. Bring a laptop! (Snacks are also welcome)

The Day Of!

We chose Rust as the language for this challenge. It was a bit of a struggle even to put together a Fibonacci sequence generator - this language has a steep learning curve!

Here's a factorial calculator, demonstrating recursion:

use std::io;

fn fibber (x:i32) -> i32{
	if x == 0 {
	return 0;
	}
	else if x == 1 {
	return 1;
	}
	else {
	return fibber(x-2) + fibber(x-1); }
}

fn main (){
	let mut input = String::new();
	io::stdin().read_line(&mut input).ok().expect("Failed to read line");
	let num_in: i32 = input.trim().parse().ok().expect("Please type a number!");
	println!("Fibonacci sequence number {} is {}", num_in , fibber(num_in));
	}

John also filled in the slow moments with an overview of lockpicking!

Coding Challenge Day

Sat, 07 Nov 2015

Nick came up with a series of coding challenges ranging from basic (Hello World, a factorial calculator) to advanced (an RSA encryption algorithm) and we chose Perl as a coding language, since none of us knew it. Using built-in help pages and examples from the internet, we tackled these problems and learned basic Perl syntax!

Here's a factorial calculator, demonstrating recursion:

#!/usr/bin/perl

$input = $ARGV[0];

sub factorial{
	my $num=shift;
	if ($num == 0){return 1;}
	else {return $num * factorial($num-1);}
}

print factorial($input);
print "\n"

Some projects that don't take up a whole page but are cool anyway.

Sat, 10 Oct 2015

Sometimes we run across something that isn't a huge project, but is more like a nifty trick. Here's a few:

When current flows through a speaker, it creates a change in its shape. If there is an oscillating current, it will create a buzz or a tone. Creating that oscillation usually requires a somewhat complicated electronic circuit, but here we use the speaker itself as an oscillator: when the circuit is completed, the speaker pulses and bounces the connection apart, causing the circuit to open, which relaxes the speaker...

Above: a simple circuit incorporating a 555 timer, which blinks an LED at a variable rate.

Meeting, 3 October 2015

Sat, 03 Oct 2015

We met this Saturday at iBooks and brainstormed some ideas for projects; John is interested in using maps for data visualization. We also talked a little bit about object oriented programming, looking at some of Charlie's older code. Colin patched a bug we found!

This defines a "cell" object with a __str__ method, which defines the string which is displayed when the cell-object is printed:

class cell:
	
	def __init__(self, state=0):
		self.state = state
		
	def __str__(self):
		return self.state

But as written, __str__ returns self.state, which is an integer by default; this will raise an error. So, we use the built-in str() function to make sure a string would be returned:

	def __str__(self):
		return str(self.state)

Dulce says the designs generated look like skulls!

Meeting, 19 Sept 2015

Sat, 19 Sep 2015

We met this Saturday at iBooks and worked on updating and upgrading the website. We learned a bit about the Jekyll language it's written in.

Meeting, 12 Sept 2015

Sat, 12 Sep 2015

We met this Saturday at iBooks and did some organizing and strategizing. A couple of things that we talked about:

Directions to take the website
What group- and subgroup-projects we want to pursue
Where to flier for outreach

Also, Colin gave an impromptu caligraphy lesson!

A modified PhennyBot for our IRC chatroom

Sun, 30 Aug 2015

We decided that we needed to spice up our IRC chatroom, and in particular that we needed a chatbot. This is a computer program which monitors activity in a chat room, and can be instructed to perform actions upon command. For example, if someone in the chatroom types ".t", the chatbot will respond with the current date and time. We're currently using a Python-based program called Phenny in our channel. The nice thing about open source software like Phenny is that it can easily be modified; we have added a few extra modules and commands. You can check out our modifications in this repository. For example:

Eric built a module to return phrases at random, like a Magic 8 Ball
Charlie borrowed from Eric and Colin's telegraph scripts to make a morse-code translator
Logging the chat and sending users a list of what they've missed since they last logged in

Some things that we've talked about adding:

an option to request operator status

Documentation

[command [option]]

.2morse [text] : converts plaintext to Morse code.
.2text [text] : translates Morse code back to plaintext.
.boinc : gives statistics on the BOINC simulations running on the same machine as the bot
.fillMeIn [number of lines]: updates the requesting user on the chatroom conversation they've missed. Default lines reported: 25
.m8b : a digital Magic 8-Ball gives predicts the future!
.stats : gives statistics on bot usage

Establishing Our Internet Presence

Mon, 10 Aug 2015

Nick has been busy setting up our cyberpresence! We now have this awesome website, recybery.space, not to mention a chatroom on the Freenode IRC network, so we can work on and plan our projects. Come say hi!

Upcoming Meeting

Sat, 08 Aug 2015

Our next meeting will be Saturday, August 15 at Internationalist Books and Community Center. The address is 101 Lloyd St. in Carrboro, NC.

See you there!

Example Post 1

Fri, 07 Aug 2015

This is only an example post

Generic NeoPixel Exercises
1. Wiring to Arduino
Circular Topology
1. Chasing Rainbow
2. Tunable Chasing Rainbow
3. Trigger-Reversible Chasing Rainbow
4. Dial-Reversible Chasing Rainbow
Modulo 12
1. Analog Clock
2. Groups and Greatest Common Factors

Ca(ClO)₂(aq) + Na₂CO₃(aq) → CaCO₃(s) + 2NaClO(aq)

Entoloma sinuatum (commonly known as the livid entoloma, livid agaric, livid pinkgill, leaden entoloma, and lead poisoner) is a poisonous mushroom found across Europe and North America. Some guidebooks refer to it by its older scientific names of Entoloma lividum or Rhodophyllus sinuatus. The largest mushroom of the genus of pink-spored fungi known as Entoloma, it is also the type species. Appearing in late summer and autumn, fruit bodies are found in deciduous woodlands on clay or chalky soils, or nearby parklands, sometimes in the form of fairy rings. Solid in shape, they resemble members of the genus Tricholoma. The ivory to light grey-brown cap is up to 20 cm (8 in) across with a margin that is rolled inward. The sinuate gills are pale and often yellowish, becoming pink as the spores develop. The thick whitish stem has no ring.

When young, it may be mistaken for the edible St George's mushroom (Calocybe gambosa) or the miller (Clitopilus prunulus). It has been responsible for many cases of mushroom poisoning in Europe. E. sinuatum causes primarily gastrointestinal problems that, though not generally life-threatening, have been described as highly unpleasant. Delirium and depression are uncommon sequelae. It is generally not considered to be lethal, although one

twitter embed test:

#NewProfilePic pic.twitter.com/Y70R4tOVVv
— CarrboroRecybery (@recybery) February 20, 2018

Making an Appearence at the Really Free Market

Sat, 01 Aug 2015

On the first Saturday of every month, Carrboro holds a festival in the Town Commons called the Really, Really Free Market. We are trying to show up at these events and present some of the projects that we're working on. Hopefully it will get people excited about our group and about technology in general. This weekend, we had the Arduino set up and loaded with the latest version of our morse code project. We got to have a lot of good conversations!

We needed our fliers perforated, so interested folks could tear a tab off. We repurposed a sewing machine to do it for us!

Volunteer-based Distributed Research Computing: Scientific Progress Goes BOINC

Wed, 22 Jul 2015

What does your computer think about when you aren't using it?

A lot of people use screensavers. These date back from when CRT monitors were standard; they would keep the display changing so that an image was not burned into the phosphor. When laptops and flatscreen monitors became more popular, screensavers were still popular, often for aesthetic reasons. Some of them could be elaborate, requiring significant system resources. Could this computer power be put to some useful purpose?

One of the first projects to harvest this computer power was SETI@Home, a program which could be downloaded and run as a screensaver, but which processed and analyzed radiotelescope signals. Out of SETI@Home grew the Berkeley Open Infrastructure for Network Computing, a system for harnessing spare computer power for scientific research.

We finally got a working desktop computer, so we can burn LiveCDs and make bootable USB sticks and so on. But when we aren't doing that, it's running BOINC. Right now it's signed up for two projects: ClimatePrediction, which studies climate change, and MalariaControl, which runs epidemiological simulations.

If you'd like to keep track of our progress, you can check out our stats here

Our First Python Day

Tue, 07 Jul 2015

The week before last, we had our first Arduino day. This involved some scripting when we wrote the code for the microcontroller, but our focus was on the electronic circuitry aspect.

This last week, we met up and took a closer look at programming. The ultimate goal is to translate text from a computer into Morse code, and have the microcontroller blink or buzz the message, like a telegraph. Along the way, we looked at concepts like string and dictionary data types, mutability, and serial communications.

When we were done for the day, our code seemed to be translating correctly, and even had case insensitivity built in:

$ python textToMorse.py
–>sOS
…/—/…/

It’s not done yet. You can watch its progress (and check out our other projects as they crop up) on our new GitHub Repository

Our next meeting is scheduled for Saturday, 11 July, from 3-5 PM at Internationalist Books. Check us out!

Our First Arduino Day

Sat, 20 Jun 2015

We’ve had a couple of administrative, get-to-know-one-another meetings, so I’m pleased to report that we’ve had our first hands-on, project-driven gathering! A core of about three of us camped out in the lounge of Internationalist Books and jumped head-first into an Arduino microcontroller! This is a piece of technology which bridges computers and simple circuitry, so we learned a lot about electronics and coding, making it through the first few example circuits.

Exploring an 8×8 array of LEDs.

One of the projects on the table is an automated Etch-a-Sketch; perhaps the computer will have a steady hand and can finally draw a clean diagonal! That’s probably a while off, though. We’ll definitely have to master stepper motors first. But just messing around today we came up with a few more ideas. For the next get-together, we’re planning to write a text-to-Morse code converter!

We’re trying to get a schedule going: Saturday afternoons, 3-5 PM, at Interationalist Books (101 Lloyd St Carrboro)

Hope to see you there!