Homemade Hardware: Explorations with ATTiny85

For this assignment, I programmed an ATTiny85 to run Neopixels when triggered by a capacitive touch sensor. I had a bit of previous experience working with an ATTiny85 + Neopixel combo, and began by trying to recreate that. Initially, I was a bit nervous that the soldering of my programming jig had introduced some integrity issues to the code uploaded to my ATTiny85, but I ran many tests with both Blink and Neopixel’s strand test and found that the jig (and each of my programmed chips) performed just fine.

The implementation of capacitive touch sensing was quite similar to my previous experiences working with it. I placed a 100k ohm resistor across pins 4 and 2 of my chip, using pin 2 as my input or sensing pin. You can see the behavior here:

The housing you see is a junk shelf find. The contraption is powered by two 3V coin cell batteries in series.

Basically, the code on the chip includes small tweaks to the sample code that comes with the Neopixels library and the capacitive sensor library. With a bit more time, I would have soldered my circuit, because as it stands, it is quite fragile.


Device to Database: Experiments with Grafana + NodeRed

For this assignment, we were tasked with experimenting within two different programs at various parts of our data pipeline. Results below:

Part 1: Experiments with Grafana

I came up with the following dashboard, focusing primarily on looking at humidity data over time, with relevant max values represented as well:

I used the following query for line chart:

For the temperature guage, I used the following query and settings:

For the humidity guage, I used the following query and settings:

Part 2: Experiments with Node Red

I made some adjustments to the workflow we did in class to make it so I recieved an alert whenever the humidity of one of our sensors went above a measurement of 20.

The workflow can be seen below:

I sent the alert to my NYU email, rather than my personal gmail.

Here’s a link to my workflow gist: https://gist.github.com/rashidakamal/5d830a73e96a584e857831d93c6bc685


Device to Database: Phone Notifcation

I made very minimal changes to Don’s code in class to send notifications to my phone from the data send to the class’s MQTT broker from my device.

The adjust code is below (I’ve changed my phone number to just all 5’s):

const mqtt = require('mqtt');
const mqttClient = mqtt.connect(process.env.MQTT_SERVER);
var AWS = require('aws-sdk');
AWS.config.update({ region: 'us-east-1' });

mqttClient.on('connect', () => {
    console.log('MQTT Connected');

mqttClient.on('message', (topic, message) => {
    console.log(topic, message.toString());
    const temperature = Number(message.toString());

    if (temperature > 70) {
        const alertMessage = `Temperature in Rashida's room ${temperature}°F exceeds the high temperature limit of 70°F`
        // mqttClient.publish('itp/device_xx/alert', alertMessage);
        sendSms('+15555555555', alertMessage);

async function sendSms(number, message) {

    var params = {
        Message: message,
        PhoneNumber: number

    try {
        // Send the message
        let response = await new AWS.SNS({ apiVersion: '2010-03-31' }).publish(params).promise();
        console.log(`MessageID is ${response.MessageId}`);
    } catch (e) {
        console.error(e, e.stack)

Screenshot of proof:

Actuating something was also part of what was suggested for the assignment. I adjusted my old arduino code so that an LED blinked when my device published to an MQTT topic. Proof:


Energy: Solar Rover - Hardware

So far, for our solar assignment, James, Brent and I have focused on getting the basic functionality of our hardware down. We have been building a solar (plant) rover, a friendly light-seeking bot that tries to use its energy particularly judiciously.

We knew we wanted to give it the ability to control motors and a few light sensors, at the least. To that end, we began measure the current draw from different motors we had on hand. We had a plain DC motor and a geared motor to work with. We found that our plain DC motor draw 400 mA at 3V, but the geared DC motor performed better in both loaded and unloaded conditions:

  • 0.06 mA, unloaded geared-DC motor @ 3V
  • 90 mA, unloaded geared-DC motor @ 6V
  • 300 mA, fully loaded geared-DC motor @ 3.6V

Because we intended to use two such wheels in our project, essentially our current needs would be 600 mA, which with a fully charged 500 mAh batter, would last us a bit less than an hour.

We did have a few tricks up our sleeves to make our rover more efficient.

In our initial designs, we imagined our solar plant rover as traveling across the floor of a sunny room throughout the day, seeking “lighter” ground from time to time. In order to accomplish this, we don’t really need the rover to be constantly active, but rather, adjust to new lighting conditions from time to time.

James and I had both been in Eric Rosenthal’s Basic Analog Circuits and had used a 555 timer chip in one of the labs – it seemed as though it would be a good fit for our needs (and possibly a more interesting alternative to existing deep sleep libraries).

After researching and testing a few different 555 configurations, we settled on an astable multivibrator mode (using this site as a key resource: link). We intended to use the timer chip to power on our arduino + sensor + actuator setup for about 3 mins and then power off for an hour or more.

We used the RC Time Constant calculate our capacitor and resistor needs. Our calculations were a bit different from the usual equation, because we were using a set of diodes to isolate the effect of one of the resistors, so that we could have a longer off-period in our duty cycle without affecting our 3 minute mark.

For our current timing circuit, we are using resistors that are nominally marked as 500k and 20k and see a 1.5 hour off period and a 3 minute on period.

We tested the current draw of our whole system and found that it draw about 2 mA in the off state and 300-350 mA when the motors were at work, loaded.

In order to run these measurements, we came across a set of interesting discoveries.

  1. The human body is about 200-300k ohms. More accurately, my human body. I had taken my multimeter to our bins of resistors in the shop to ensure I was getting the values I thought I was (the bins are a mess), and it seemed that all of the higher-value resistors were reading about 300k ohms. I had become the path of least resistance! Once I had James hold the other end of the resistor to the multimeter, this problem was resolved.

  2. The 555 timer, in order to output steady amperage seems to require resistors of a high-enough value. In order to measure the current draw of our system, we had switched out our timing resistors to make our duty cycle shorter. Unfortunately, at lower resistor values (< 500 ohms on one, about 3.3k ohms on the other), the Arduino’s power LED would flicker and show evidence of less than steady amperage. Once we switched the 10k resistors, the problem seemed to resolve.

This post has glazed over the parts that I did not focus on. Brent has worked to engineer the robot behavior by coding its response to different lighting conditions. We are using 4 LDRs, placed in cardinal directions, and have applied an Kalman filter (James’s suggestion!) to smooth the data we receive from their associated analogRead pins on our Arduino. Brent has been working with the robot to make it turn in the direction of the most well-lit LDR.

Next, we have to finalize the form of our rover. It’s current form is not particularly friendly to the transport of plants, so a bit of fabrication is in order.


Artist in the Archive: MARC Madness

I got a wee bit lost on this assignment and jumped around from the many possible ways to satisfy its requirements. I initially started by modifying the ‘marc_template’ from Jer’s github to traverse through other sets of keywords. I played around with examining flowers and electrical appliances in the visual materials. One thing I immediately realized was that I was not familiar with MARC records well enough to traverse it as freely as I would have liked. I found this link in Jer’s code comments: https://folgerpedia.folger.edu/Interpreting_MARC_records#2xx, but nonetheless found it was necessary to do quite a bit of digging to pull fields that Jer hadn’t already pre-populated into his parser.

I then tried to play around with Jer’s network graph based on the name authority records. Again, ran into similar issues with MARC documentation – I eventually found a side that documented how to pull gender information from MARC records, but then promptly misplaced the site amongst my many tabs.

I decided to change tacks slightly by pursuing modifications on Jer’s network graph Glitch, but found Sigma.js’s documentation to be somewhat lacking. I decided my contribution for this week would be to clean up the json that Jer had used in his occupation graph. For this, I used a bit of python that I ran right from my Terminal. Code as follows:

import json

data = { "nodes": [ ... ] } # I copy/pasted Jer's JSON into this variable
data_list = data["nodes"]

filtered_data = [node for node in data_list if node['label']]
with open('cleaned_occupations.json', 'w') as outfile:\
	json.dump(filtered_data, outfile

After a few minor edits to that output, (I added back in the { "nodes": and trailing }), I uploaded that to a gist on github, and adjusted Glitch network graph (forked from Jer, with a few styling adjustments).

It does not really look very different from what we had last week, but the data is cleaner. If you insist on seeing it: https://glitch.com/edit/#!/tender-pony?path=views/index.html:32:17

I tried to through this into Mike Bostock’s force-directed, but realized my data was structured differently than his (no explicit links in my set). A mess nonetheless: https://observablehq.com/d/1403340886c072e5