what data flows?
~ by way of a floating raft and a waterwheel powering a tiny computer, data flows when enough water flows: a local wifi network appears and a webpage displays dataflow says hi (sensing 2 volts)
drawing of the local wifi network
16 second video of this attempt; 1.9mb
~ another raft, another wheel: this time powering a small computer connected to the internet, in anticipation of hosting this website. the waterwheel charges a battery that powers a small computer (a raspberry pi 2w) with a 4g modem (holding a sim card with data plan) which connects to the nearest cell tower. the computer reads scripts to enter the sim password, connect to the internet (via a tunnel) and collect data through various sensors.
drawing of the network through cell towers to browsing device. since the mobile network doesn't allow direct incoming connections, a separate "tunneling" server is required in between, so this data flow requires quite a few more hops
~ one way to call the river: a microphone is attached and the computer is scripted to pick up the phone when called
pssshhhh... glug, glack! glug, glug, glack! glug, ...
(david rings the dataflow number and records what he hears for 1:37) 3.7mb
logs: view phonelog
to be continued...
... from waterwheel to website
a waterwheel on a raft held by a rope against the current. the flow of the maas turns the wheel which generates electricity to power a webserver
traces of the process are currently scattered across the web and on my local disk. some highlights:
illustration/schematics
power logs from a day during Dutch Design Week 2024
the waterwheel turns geared DC motors (originally intended for car seat adjustment) which generate around 2V at 20RPM. They are wired in series so that their voltage is summed. the power is smoothed and converted to a stable 5V output which charges a battery. a low power microcontroller handles power switching logic, turning the server on when there is enough charge.
power consumed when the server is on is around 1 watt, which is around the amount of power generated by the waterwheel, depending on flow rate. a solar panel is additionally attached, in case flowrate is below the charging threshold.
internet connection is via a 4g modem, unfortunately this also requires a sim card with an active data plan.
illustration of the dataflow network topology. below, the local network (direct connection of browsing
device to the server) involves just those two nodes. above, the internet-connected server is connected via
4G cell towers to a data center which tunnels the connection to the browsing device.
notes
transcriptions from pocketbook
---
20 04 26
How to share dataflow? (waterwheel to waterweb)
To try:
[ ] lightweight view of agora content
[ ] "reader mode" (also with positioning)
[ ] datalog during dutch design week (power levels etc)
[ ] graphs
[ ] contextualise:
- writing and include permaculture principles etc
- criticise:
- hi-tech
- high-threshold (needed for it to "work")
- new components
Still with this project a big challenge is in the long-term testing and robustness and finding a physical spot
for it.
- feminist server manifesto (https://areyoubeingserved.constantvzw.org/Summit_afterlife.xhtml)
---
25 05 26
maaslab/sitemap (or site tree)
maaslab/
|-- maaswacht/
|-- calendar/
|-- dataflow/
|-- residencies/
---
26 04 26
[ ] show the weight of the page (in terms of data transferred)
[ ] select your "data appetite" (i.e. ranging from plain text to super crispy hi-def images and videos)
[ ] tbd: traceroute, show the "data flow" (i.e. the path that the data takes from the server to the browsing
device, including any intermediaries such as CDNs, caches, etc)
[ ] contextualise and connect the project with relevant permacomputing principles
[ ] observe first
[ ] expose the seams
[ ] reference: rosa
My role is also to ask the right questions. Informed by permacompintg rabbithole- make connections what was
explored, which principles are touched on, and also ask critically:
- what are the current relations?
- what is valuable/beautiful?
- what is needed?
- what problem are we trying to solve?
[ ] Observe from multiple perspectives, ideally including all stakeholders (human+non-human)
- maaslab website/dataflow as a **self-obviating system**:
- how can this project obviate itself? (i.e. lead to a situation where it is no longer needed)
- once editing/content collection is done, a static version can be exported and/or printed
- constituent parts can be dissasembled and reused in other projects
[ ] reference: varia rotterdam
---
Questions (technical):
- how to show the "weight" of the page (in terms of data transferred)? Does the browser give access to this
information? Or do we need to calculate it?
---
Outline/chunks to write about:
- dataflow raft / wheel experiments, as a "maas-powered website"
- outline what was done and the process, also be critical about it (e.g. the hi-tech components, the
high-threshold for it to "work", the need for a physical spot for it, etc)
- dataflow as touching maaslab's digital presence in general
- i.e. this website, and considering the
- what it is:
- principles/values:
How can this function as a self-obviating system? (i.e. lead to a situation where it is no longer needed)
