A Slimmed Down First and a Well Known Second Final

project solar-geiger-counter

This weekend I took my Energy final project out in the sun and it worked - at least most parts of it: I can power the geiger-counter entirely with a 12 V / 3.4 Watt solar panel - no LiPo involved. I cannot get enough current out of the panel to power a solenoid on the side as well. To avoid using another solar panel and keeping the project still portable I decided to slim this part down and accept the final outcome: a solar powered geiger counter with an Arduino Nano as a data outlet. I cannot run my entire art installation from project development on a small solar panel - but it is remarkable that the small panel can power the geiger-counter and therefore produce voltages up to 400V (needed to activate the geiger-mueller tube)! 

Here the prototype test outside:

 The  mightyohm-geiger kit  assembled and running on solar - a beauty!

The mightyohm-geiger kit assembled and running on solar - a beauty!

And a live test:

project solar-blockchain-physical-streaming-interface

Thinking about the course and my projects in it so far I thought since a long time that it might be worth revisiting my only partially finished project for the midterms. 

It took me a few hours to successfully debug my hardware + code and had three insights:

  • a bigger power supply (in my case a 6600 mA Li-Ion Pack) is great for the Raspberry Pi 3 
  • don't copy paste into Github from terminal - check for tabs and spaces
  • always check if your project share a common ground

I got the wallet / blockchain connection and the servo part working on solar (with a gentle support from the Li-Ion pack ...), here the rough prototype (here just running from Li-Ion pack):

After compiling ffmpeg on my raspberry pi locally (takes a long time ...) I tested streaming to youtube from the pi and then embed this into my website. Streaming from the Pi to Youtube following this tutorial worked, at full resolution only if the Raspberry Pi is plugged into a standard power socket - the Li-Ion Pack can only support a streaming resolution of 320x240 at the moment, maybe the bottleneck is the booster. Here the battery powered prototype:

After a lot of tweaking of the ffmpeg-stream parameters I finally decided to re-solder some of the connections - using thicker wires. And I finally got all parts (digging the blockchain, running the servo while streaming live to youtube - with battery/solar power only) working. Very buggy, it crashed after a minute ... but it worked!

I am super happy! And I know that I need to iterate on this: This is a temporary fix as I ideally would like to the use webRTC as I used it on the mac-version of the project.

This class really was a journey, a lot of insights and learning moments - so far am so satisfied that I can run both projects independently with solar on a raspberry pi and an Arduino!

A Stone, finally! And Some Numbers on Randomness

I am super happy that my classmate Yen, who happens to work at ITP as well, heard about my project and gave me a beautiful big natural stone that he kept in his office . Very likely it is granite and therefore a good source for natural radiation / random numbers. 

radiation tests

So last night I sat down and did a few experiments measuring the amount of decaying particles with and without a stone close to the geiger-counter. I conducted 3 test rows, so three times with the stone, three times without the stone. 

Here are the results measured over the time of 3 minutes each:

round 1

(86 vs 67)

round 2

(76 vs 67)

round 3

(75 vs 62)

verdict

The stone from Yen's office seems to be slightly radioactive, around 15 - 20% compared to "normal" conditions that mainly detect gamma rays from cosmic radiation. It is still very low compared to carbon-monoxide detectors, big granite kitchen countertops, old watch luminescent hands, which emit many more decaying particles over this amount of time. 

installation prototype setup

I decided to do a quick run to test parts of the setup. Here a solenoid knocks the random particle decay from inside the stone that gets detected by the geiger counter back into the stone  - the heart of the stone is talking to its audience:

 

So far so good - tomorrow I have to test the setup powered entirely with two solar panels - let's hope the sun is out and the panels can generate enough current to power the entire installation! 

Merging "Energy" and "Project Development Studio" - Finals

For my final in my energy-class I decided to create a solar powered version of my installation piece for project development studio: In this iteration of my project, the audience can only "connect" to the true randomness of the granite when the sun is out. 

I will build a more complex installation for the spring show that will not run on solar, this one for my energy-final will run entirely on it.

Here a modified wiring schematics that is based on an Adafruit tutorial for using the piezo and solenoid in combination:

 

solar_random_setup.jpg
 

I am using a logic level converter between Arduino nano running on 5V and the geiger-counter running on 3V. The solar panel is providing power for the Arduino and the solenoid. The piezo is running on a separated power-circuit provided by the Arduino. This circuit feeds as well into the logic-level converter which is providing power to the geiger counter (convert voltage down) and enables listening to its pulse (convert signal voltage up). 

The code for the installation is still in the making, I still have to merge the solenoid trigger into the piezo and geiger counter code. The comparison of geiger counter beeps and knocks to identify whether the knocks of a user are in sync with the randomness of the particle decay inside the granite needs to be improved as well. 

IoT, Blockchain and Solar - Midterm

After countless days and hours of debugging, two bricked/one broken SD cards and a final kernel panic when running a simple python sketch it is time to take a little break and resume. So let's have a look where I was a week ago with my project - at that time everything was running fine, the Pi was accessing the blockchain and the servo reacting to changes in my account. All of that streamed in real time. At that time with two laptops:

So far so good: listening to changes in the chain and the servo re-action happened battery powered on the Pi Zero W, the streaming was done with webcams and laptops, the server part plus frontend ran on my Amazon Instance. 

My next step was to try to run the Pi-part with solar power. It worked as expected with a 5V booster and a Li-Po between Pi and solar panel. Then I tried to run the main local part (camera stream and querying blockchain) with battery (a pre-step before using solar exclusively) - after a few days of debugging and hacking web-rtc for streaming live from the pi via my server this worked as well (with a great lag due to the slow network). Great!

Motivated by this success I tried it with solar power on a sunny day - from an energy perspective a success, not so much from a computational one. My streaming code and/or Pi image started to behave strange - it had a bug. And here I probably made a few too optimistic assumptions about the energy provided by the small solar panels, running the Pi at full CPU usage requires more amps than expected. And more than the panels can provide. It should take me a few days to fully realize this - and (spoiler alert!) finally delay the final project vastly.

But at that time I was optimistic to solve this issue in the next days (I assumed it is a code issue, not an energy one) and started working on the enclosure for my project.

IMG_2452.JPG
IMG_2470.JPG
IMG_2450.JPG
IMG_2478.JPG

After running the separate codes on the py I started to see a mysterious "Bus error" - which seemed to indicate corrupt SD cards, a common issue on the Pi. I re-imaged different cards a few times  - just to run again into the same IO-Bus error. I was still optimistic to solve this - I knew that the code worked a week before on the Pi (at that time with a steady battery supply) - why should it not work anymore now? I hadn't changed a single line as far as I could remember. 

I spent 3 days in a row trying 2 new SD cards (which are completely unusable now), broke one other SD card, tried numerous debugging strategies - only to run into a kernel panic after a fresh install of Raspbian during a very late night session. 

IMG_2476.JPG

That was the point where I had to laugh out loud - too many things went wrong before and this appeared just absurd. I realized that I could not solve this quickly - but that I had done as much as I can to solve it. It was indeed disappointing to work this hard on a project only to see that nothing work=ed anymore at the end of the week. I basically started on the top and ended up at the bottom. After another day of debugging and presenting my progress in class more and more clues popped up that this might not be a software/code issue, but related to the power supply - in my case the LiPo/Solar setup. I finally stumbled upon this forum post:

Screen Shot 2018-03-20 at 11.56.18 PM.png

I realized that I probably need more Amps to power my application - meaning a LiPo that is more powerful. The solar panel should be fine, if exposed to direct sunlight as much as possible. In a real life installation outdoors the conditions (temperature) would affect the battery life as well, for this project I assumed indoor use. 

So far in this project I learned a lot: Solar works, computation powered by it on a Pi works as well, the sleep/wake up external circuit is simply great - but better stack a few more Amps into the circuit when running computational intense operations on a Pi.

IMG_2474.JPG
IMG_2477.JPG

 

 

Energy: IoT, Blockchain and Solar

idea & prototype

After experimenting with blockchain implementations for IoT devices I decided to use a Raspberry Pi Zero W for a first iteration on my solar project for energy: a physical pay-for-a-smile interface for the blockchain.

basic circuit setup

Pi Zero W + Camera, micro servo, 5V booster, 3.7 V 1200mAh LiPO, charging/load circuit, solar panel

solar setup_bb.png

 

power requirements

I re-measured the power consumption for the project and averaged the values over time/runs. The Pi Zero showed a significantly lower power consumption compared to the Pi 3 (in mA). 

I am still contemplating on how to create a deep sleep mode that fits the concept of the project. At the moment, the Pi is listening constantly on changes in the blockchain, then reacts by turning the servo when a user sends money into the account. Conceptually the project would be online forever (so that users can continuously trigger the smiley face), the camera would need to stream constantly as well (something still not finished in pi sketch, at the moment I am using my laptop camera). This is not possible with the current circuit as it will be down after 4.5 hours if running exclusively on battery.

LiPO specifics: 3.7 V, 1200mAh

LiPO + booster: 5 V, 890mAh (rounded)

runtime for continuous sketch (ignoring the servo peaks): 4.5 hours (rounded)

This would mean it would inevitably stop at nighttime when there is no daylight to charge the LiPo from the solar panel. Assuming the physical interface would be mounted outside, it would make sense to power it off at night - as the camera would not be able to film the interaction anyway. This would as well emphasize the connection of the piece to a real environment - which a physical web-interface tries to evoke anyway. 

Nevertheless, an external deep sleep circuit is necessary. I am currently waiting for an external hat for the pi that will manage the power with an automatic shutdown/wakeup schedule. 

 

Hopefully the sun will come out in the next few days so that I can run the sketch at least for one or two days to test the performance of the circuit over time and alter it if necessary.

planned iterations 

I want to experiment in the next few days with writing data to the blockchain directly with the Pi Zero W to store environmental data from a temperature sensor in the network permanently with solar power.

 

Energy: Solar Powered IoT-Art for the Blockchain

My focus this semester in many courses is the blockchain: I believe that a server-less, decentralized and consensus-based network is the future of the web. I want to explore different use cases for DApps (decentralized apps) and DAOs (decentralized autonomous organizations) in an art and design context. 

In my "Energy"-class we were assigned with the task to power computation (in any form) with solar power. After investigating the energy consumption linked to the proof-of-work algorithm in blockchain applications like bitcoin or Ethereum I decided to explore how far this could be powered by solar energy. After some research I realized that the proof of work is theoretically a great idea - but not sustainable from an environmental and economic perspective in the longer run. Ethereum is planning to replace the proof-of-work with a proof-of-stake algorithm which relies on a stake-based verification/mining system rather than the cryptographic-puzzle that needs to be solved for proof-of-work. This will require less computational power (and real energy) as a hardware arms-race (miners competing for mining a block first) is avoided by design. 

Based on my research that I presented in class I decided to look at use-cases for micro-controllers and blockchain. These should be low energy as they are powered by solar energy only and store environmental data gathered by sensors in the blockchain - creating a 'memory' of environmental data. So far the open-source IoT devices capable of running the necessary systems (node & geth) are rare: I found one git about measuring temperature with a Node 8266 board. This will be my starting point for further exploration. I plan to base my further work on this project on the hack and measure the necessary power consumption of the board, then explore an optimized use of solar energy (without relying too much on battery storage). I will investigate if it is possible or necessary to try to run a node directly on the device (highly independent but probably more power hungry) or use the device as an ultra low-energy transmission tool to another central device running a node via wifi/bluetooth/lora. 

I plan to start with measuring environmental data, but the use cases could be quite varied: I am working in my Project Development Studio Class on an installation piece that runs possibly for an infinite time trying to randomly guess with quantum processes a certain quote on probablity - it would be conceptually interesting to store the failed attempts of this process "forever" in the "world memory" of the blockchain. Solar power would make sure that this guessing runs for an infinite time (excluding material failure). 

To familiarize myself better with more abstract concepts in solidity (the language for Ethereum) I started with CryptoZombies, an interactive, game-based learning platform that teaches programming for the blockchain - by building a zombie game on the blockchain.  

Directly related to our topic of energy:

In Solidity, your users have to pay every time they execute a function on your DApp using a currency called gas. Users buy gas with Ether (the currency on Ethereum), so your users have to spend ETH in order to execute functions on your DApp.

How much gas is required to execute a function depends on how complex that function's logic is. Each individual operation has a gas cost based roughly on how much computing resources will be required to perform that operation (e.g. writing to storage is much more expensive than adding two integers). The total gas cost of your function is the sum of the gas costs of all its individual operations.

Because running functions costs real money for your users, code optimization is much more important in Ethereum than in other programming languages. If your code is sloppy, your users are going to have to pay a premium to execute your functions — and this could add up to millions of dollars in unnecessary fees across thousands of users.

from: cryptozombies-tutorial

This means I should look into the most efficient ways to write contracts and store data in the blockchain - probably based on trusted open-zeppelin contract templates and decentralized storage with IPFS.

Here the PComp side of the setup: ESP 8266 wifi-module, LiPo, Solar-Panel + adafruit mcp73871 solar charger

IMG_2395.JPG

Lots of iterations and a few tutorials  that explain deploying a DApp later I got something working: a physical interface for the blockchain ... that smiles for Ether :) 

KINETIC CHALLENGE: The Energy - Hammock

We finished our prototype for the kinetic challenge assignment on Saturday - and it worked! (apart from some minor engineering challenges that are beyond the scope of the task).

A lot of fabrication was needed as we built the gears and belts by ourselves:

 The sheep ... meaning our foundational structure to hold gears, belts and the stepper motor. 

The sheep ... meaning our foundational structure to hold gears, belts and the stepper motor. 

 We used nails (in our first iteration) instead of cutting the gears with the cnc-router.

We used nails (in our first iteration) instead of cutting the gears with the cnc-router.

 Nails to keep the belt drive in-line.

Nails to keep the belt drive in-line.

 Measuring by eye the accuracy of the wheel drive - a tiny bit off but tolerable for a prototype.

Measuring by eye the accuracy of the wheel drive - a tiny bit off but tolerable for a prototype.

 Basic setup, rear view with circuit and motor attached.

Basic setup, rear view with circuit and motor attached.

 Our circuit (without capacitors) with full bridge rectifier built of 4 diodes.

Our circuit (without capacitors) with full bridge rectifier built of 4 diodes.

 The stepper motor with the second wheel attached to it.

The stepper motor with the second wheel attached to it.

 The self-made belt drive translating the power of the big wheel (that is connected with a rod to the swinging hammock).

The self-made belt drive translating the power of the big wheel (that is connected with a rod to the swinging hammock).

Prototype

And here the final prototype in action on the ITP floor. It is providing up to 9V at 150-200 mA.

KINETIC CHALLENGE

Assignment 1: Turn human motion into light.

After reading the Paradiso/Starner paper, “Human Generated Power for Mobile Electronics” we realized quickly that a lot of our initial ideas had been done already a few times. Very interesting was the energy chart that highlighted the amount of power that can be generated by different parts of the human body - with the legs as the most powerful ones. 

We decided to use a combination of human power and gravity for our project: The Energy Hammock.

Iteration 2

A seesaw-like setup for two people on sitting swings that encourage a playful interaction.

Iteration 1

One Person, swinging movement of the hammock to the sides creates energy at a gear-head motors mounted at the ends of the hammock.

hammock_energy.png
energy_concept1.jpg

The idea is to harvest energy in a playful way using the weight of the human body as the main means of production.