WEBPIT 3.0

Synopsis

This project is a step in a developing body of work called 'the WEBPIT', that explores the creative possibilities of internet-independent WLAN's and servers, portable networks, and off-grid energy generation.

WEBPIT 3.0 (the current iteration) is a portable system that has a crank generator (backdriving DC motor), a PCB board with a supercapacitor that stores the generated energy, and a XIAOESP32S3 microcontroller that, when powered from the supercapacitor, creates a WLAN and puts out a local server. The user can then join the server and read the poetry on it for as long as there is energy. Then they need to continue cranking.

System diagram

Design and planning

Final 3D model

Design principles - permacomputing

Link to the permacomputing website, from which I've taken the screenshots

Initial premise for the design

Project plan for DF Studio

For a little while I was looking for a good visual planner that would be open source and Internet-independent, and so it came in the form of Gantt Project. Wild interface, as usual, but does the job and does not have any form of sensory overload or hyper streamlining, which is great.

PROCESS

Electronics

Storing power - Lipo's vs Supercapacitors

Lipo batteries are extremely convenient, surely, they have charging modules, they are also somewhat dangerous (explosion and all). They are also, generally speakinh, 'too big' in terms of energy they can store. That seems like a counter-intuitive idea, it also goes directly against my permacomputing reference - why implement a smaller battery if there is possibility for a bigger one? Because ART, because... So the defense is conceptual, and presented before: the server should work on a small enough timeline, so as to be experiential. And for that reason:

Supercapacitors are beautifull in just how basic of a bucket they are, they hit the checkbox of understandability, if I go through with the idea of having all casing transparent... A capacitor functions:

The circuit design

The first breadboard version is with a brushed DC motor. The logic of the circuit:

The first PCB design

I was set on having the circuit design be 'readable' left to right, so I made some non-negotiable decisions in terms of the design:

Power management

I had originally intended the XIAO to be powered through the battery terminal - which is supposed to run on 3.8V supply LiPo battery, has a battery management system embedded, etc. This turned out to not be a good idea, since the battery terminals were deciding to short the board, and then the current supplied was peaking to 1A, which is gigantic for this board. I have not discovered, as of yet, the reason for this - the terminal were correctly soldered, the JST connector was crimped well, but all together it was not working out.

What had worked out, however, was giving the power directly to the 5V pin on the board. Yes, this is a far less 'elegant' solution, but it also gives an opportunity to design the board better, without awkward JST connectors that are so hard to pull out. It also gives the opportunity to have the pull-up converter pull to 5, as opposed to 3.3V, which might be advantageous in the end, if I stack more supercaps.

Putting it together

There were a few challenges and realisations during the final assembly process of this first design, namely:

THE FIRST WORKING VERSION

IT WORKS FOR LIKE 30 SECONDS

There are numerous things to do to improve the working time and the circuit, plus many mistakes I have realised when setting it up:

Electronics 2

The final PCB designs

The power capture board final decisions

After having tested the motor with the two-step reduction and knowing the voltage generated (around 2V with generous commitment), I knew my PCB logic would change slightly, namely I would have two BOOST converters, one to boost the 2V to 3.7V (for the supercapacitor), and one to boost the 3.7V to 5V (after finding out the battery management system on XIAO does not like the supercap).

One exciting task was to learn how to design and add my own symbols and footprints to my PCB's. This was time-consuming, but reasonably straightforward.

Designing my footprint

There are 4 main elements of the datasheet of the voltage converter I needed to refer to:

In order to add a new symbol, it is a good idea to first make or locate the library you will be adding to. The symbol and footprint libraries are different, so this needs to be done for both. I created a local library in which I will keep all of my self-made footprints.

Possibly the most crucial step - mapping the pins correctly in the schematic (which will then correspond in the footprint). This is the bit where mistakes cost a lot.

Setting up the general approximate shape for the component (the silkscreen being a tiny bit bigger). The footprint editor requires a separate library to be made.

Getting the pads to the recommended size (which will later be significantly adjusted, as we'll see).

The symbol and footprint need to be manually linked, meaning both already being there and being selected from the menu.

Making the symbol big enough to not cause a ridiculous mess in the schematic.

Filling in the details for the symbol including details, the datasheet link, a linked footprint, etc.

In the final schematic - beautiful.

Final adjustments to the pads - sorting out the right clearances (I need at least 0.4 mm between, the mill won't do any less). Aditionally, because the legs of the component are so small, the 'recommended' pad design is not necessarily working out - it's too close together, and as long as the legs are touching the pads they can be blown up out of proportion, if, again, there is enough space to match with the legs.

Routing the circuit

Routing was not particularly easy in this case because of the design rules I set for myself earlier - having the power and ground rails. Previously I did my best to avoid the jumper resistors, but it was not really an option in this case - however I was rotating the component, tracks were necessarily overlapping.

The XIAO module board

The final boards milled

The wireless network

It is extremely important for me for the whole work to be as self-sufficient as possible. Yes, it is a ridiculous and utopian proposal, maybe even hypocritical, considering I use internet to make the work, to download libraries, even if I upload them onto the board, etc. Nevertheless, I want the artwork to at least try and break the association between communication networks and the larger grid, and suggest interactivity that makes use of technologies that underpin the internet, but are not consistently reliant on it. This presents numerous challenges and restrictions, but it is also the baseline of my creative framework, and that is exciting in its own right. I have to make decisions that work with this premise. The biggest and very reasonable criticism to the idea is that a lot of people have data on their phones, meaning that an 'internet-less' wifi connection is complimented by their data package. There is fairly little 'internet-less' space left anyway. And yet there are numerous places and contexts in which internet connection is not a guaranteed reality, but a complex, latency-ridden luxury. I want to tap into the non-universality of the web.

For these reasons, I will have my device not connected to the internet and in no way depend on that access. This means:

The Acess Point and the Server

The ESP32 is meant to make up its own WLAN that other devices can join. I am making use of the ESPAsynchronousWebServer library to make up an asynchronous server that will host the website locally. Together with Ajax, the AsyncWebServer allows to update the website in real time without needing to force-refresh the whole website.

The communication

Option 1: Websockets

I have used websockets before and they are an incredibly convenient and robust way of communicating between a server and the client. I can also easily implement javascript together with them, since it is javascript code that is likely to handle the websocket in the first place. In a sense there is nothing necessary about the use of websockets in my example, but if I progress further in this process, I can hopefully utilise websockets in order to have the different users interact on the server.

Option 2: straight up httpGET requests

First web prototype

The final system

Because of the time spent focusing on the build, the server side slightly suffered in terms of how deep the exploration went. Full description of the networking code can be found in Networking Week and Interface Programming Week. The anatomy of the system (as also described in the system diagram), is as follows:

The build

The prototype

Deciding on a gear vs pulley mechanism:

Prototype of the belt version

The belt version was very easy to test initially, so I put together the first working prototype with the motor I was intending to use.

The system is very simple, with 2 pulleys at ... ratio and the shortest belt I could put to join them, in the interest of space. It is even simpler than what I had imagined at the very beginning.

I got the measurements for the motor off the wide seas of internet - couldn't actually find that specific model on a manufacturer's website, followed the datasheet attached to the Amazon link instead.

In terms of attaching the parts to the main-plate, I was advised by my colleague to make attachable plates to hold the bearing - this is extremely convenient and looks great, plus is very secure.

While this setup works extremely well, the voltage generated is extremely small - 1V at a reasonable maximum for human rotation. Because the motor is so attractive and readily available, I am willing to give it another shot with a 2-state reduction system, where the gears are arranged like so:

The second design - two-step reduction

The taller cut part

Learned how to use a new lasercutter - the GlowForge. I hate it, it gave the most inconsistant results, burned the wood like the fires of Satan and also managed to not cut through. Like, how?

While there are MANY power transfer parts available at Design Factory and I am extremely happy I can use them, we don't have an axle coupler for every sized shaft, and the motor has a particularly thin one (3mm). Which means it is hard to center the shaft within a hole of 5mm. Especially since the set-screws are at 90 degrees to each other (which is fine if sizes are matching).

I found a coupler that had one end threaded, which was going to be my solution. But the coupler that had the right size of screw (M5) for the pulley for some reason had M5 set screw holes for tightening. And the ones in the bag with them were M3. So all in all, I had to resort to using M5 set screws which were so long they were sticking out, or M5 bolts. Both of which were interfering with the screws holding the motor, and ultimately the pulley was at this point too far from the motor and not coupling with the higher one. What I mean to say is - it wasn't working out.

This tiny discovery made me the happiest out of all of the prototyping steps. Hear me out (it only works in some cases, but (if the axel mismatch is approx 2mm)):

Putting in the block in between the two walls stabilised the setup further - it is certainly necessary to stabilise the two parts as much as possible.

The final design of the prototype - super happy!!! If you are very generous with your energy you get up to 3V, which is great for my purposes and any higher would mean to quick of a charge up.

The final bracket design

Further description of manufacturing in Wildcard Week. The bracket is a waterjet alluminium frame made out of 3 folded separate parts made out of thinner alluminium (3mm) and bearing holders made in 6mm alluminium. The pulleys, belts, and bearings were pre-made, I used m5 bolts as axels and nuts, nylon and normal, to fix the axels in place.

The crank handle

Ultimately, I would like to lathe the handle from metal, but for this version I 3D printed it in PLA and post-processed it, which turned out fairly well.

Electronics housing

The final design for electronics housing focused on it needing to be transparent, for all elements to be visible and readable. I vacuum formed transparent acrylic around a CNC'd silica mold, fuller description can be read on Wildcard Week. The process was difficult, less so the vacuum forming and more the later cutting and shaping (because of the brittleness of the material and the speed and vibration of the bandsaw).

The transparent case was then encapsulated in PLA 3D printed brackets. This is also further described in Wildcard Week. The brackets were located using pins made out of welding rod. I used threaded plastic insert to screw the brackets into. The PCB boards also located using welding rod pins, and the housing was fixed onto the metal bracket using screws and nuts.

The tripod mount

This part I am confident with, since I've made it before. The idea for this version is to make a slot for a small metal part (cut off metal bar) with a threaded hole for the tripod screw. Depending whether the electronics box sits on an additional frame (it probably does), the screw part would mount into the big bracket.

The final design for the tripod mount was machined and drilled. The holes located on the alluminium brackets lock together with screws that go into the mount. For future consideration I would space the holes 120 degrees between each other, as opposed to the awkward design I chose here (two holes reflected accross the center point and one in-between).

The final assembly

You can find much more written about the final assembly in the System Integration Week.

Copyright licenses and decisions

Throughout the course of Digital Fabrication, I attempted to remove myself as much as possible from commercial software, embrace open-source. It is a common problem for initiatives like that to lack the ability or tools to sustain themselves - in the literal sense, for example, of not being able to compete because of additional needed time, lack of support/commercial backup and backing, scalability, reliability, whatnot. The idea is, of course, that with developing community support and leverage an infrastructure can be continously built, and it already exist, albeit on a smaller scale.

Of course, thorough examination of and participation within a mildly-definancialised social sphere requires consideration of every stage of the creative/productive process, aka the use and the terms of use. I have not thoroughly researched the politics of copyright licenses before, even if I have some awareness of the problematics of copyright in the music industry, the ongoing AI training data confrontations, etc.

The idea of 'copyleft'

The basic premise, as described by GNU from the Free Software foundation, is that while an object within the public domain can allow for its free use and modification, it cannot in itself prevent the forked versions of restricting access and becoming proprietary. The idea of 'copyleft' is therefore the maintanence of the same degree of freedom whenever a user interacts with the object, even after forking, etc. The GNU license therefore claims such continous degree of freedom.

Free software in this case refers not to the 0 of the price, which is interestingly not guaranteed, but to freedom of software as defined by 4 principles (taken from the GNU website):

In this sense, free software refers to a type of freedom that can be examined on neo-liberal terms. Fair enough on defining it outside of the grounds of financialised logic (aka costing 0).

The GNU General Public License licenses are pretty much explicitly for digital software, because that logic of copying and repetition is far more applicable to digital structures and artifacts. It is interesting to think that governments de-facto protect the copyright and in order to copyleft, explicit action is to be taken.

Free vs open software

While often used interchangeably, there are differences between the two. Reading different sources on the subject presents somewhat confusing points, but the essential premise being that free software will always have an open-source, yet open-source software might not comply fully with all 4 points of software freedom. They also have different origins, free software idea being developed by GNU in the 80's, OSS in the 90's. Ultimately, it seems to be the case that OSS develops and sustains itself in a more corporate-aligned environment, with less emphasis on the ethics and philosophy of early internet imaginary (practicial idealism ala Richard Stallman (who is a hugely controversial figure and one hardly to be associated with)) that free software pushes forward.

For example, the MIT license is a typical OS license, as opposed to a free software license

One extremely interesting point about free software licenses is the imposition of that license on all forks and derivatives. This, of course, presents a restriction, but the restriction seems to me to be more aligned with the idea of protection of common ideals and less with libertarian free-market logic. It's a bit of a tight territory to navigate. Another key component of OSS licenses are the requirements for derivatives - how changes are to be described, whether the source code has to be included, etc. Free-software also has stricted requirements for the code becoming proprietary - since it must remain under the license, it can never become 'closed'. MIT requires that the original license be kept intact, but other than that is a permissive license. FREE VS OPEN VS RESTRICTIVE VS PERMISSIVE vs ?

Creative Commons license

Creative Commons essentially emerges as an in-between public domain and other license types, since it allows for different choices in use and type, for example relating to commercial use. The author can allow for uses commonly restricted by creative copyright, but still keep some decisions. There are 4 types of CC licenses, essentially distilling other types of licenses out there:

Of course CC sounds good, it is super popular, approved by the Open Source Initiative, flexible, clearly documented. Only, do I want to insist on the ideology of FSF? Then again, FSF seems to have gone through controversy that actually damaged projects like FreeCAD because of the inflexibility of licenses they insist on.

So, what to choose?

In all honesty, CC NC license seems reasonable for my situation. I am not yet at the stage to claim open-source hardware, even if I aim to get there. The project has the intention of promoting self-organisation, some level of community self-sustenance, and grid independence, even is speculatively. Additionally, the tools I've used are OS at best, but not FS, meaning a full attempt at a FS ideology alignment would be unsuccessful. I explicitly want the project to not go into commercial use in any of its forms, but I am extremely pro-forking and pro-adaptation. I should then take the initiative to push the documentation further and share the project in the right contexts.

Conclusions of all conclusions (inconclusive)

I am planning to continue on a body of work of WEBPIT iterations, which I aim to use with friends outside, as a little performance, as well as applying for exhibitions and residencies to develop the project further. It has been a great medium for developing a really wide variety of technical skills, and I plan to continue in that vein.

The bonfire version

I intend to use the knowledge I gained during this process to continue the WEBPIT project the next year, focusing on building a steam-generator version of the project. Areas I intend to be exploring include: