Når man driver et hackerspace, kan man altid bruge mere plads så man kan have endnu mere udstyr og værktøj. Vi bor i lokaler, som kommunen stiller til rådighed, og hele bygningen er i brug af forskellige foreninger. Der så derfor ikke ud til at være mulighed for at udvide, men for nogen tid siden fandt vi ud af at det var muligt for os at leje en del af den lade, som også er en del af bygningskomplekset på Sofiendalsvej 80.
Der er selvfølgelig nogle udfordringer – laden er hverken isoleret eller opvarmet, og et træværksted støver en del – noget som de andre brugere af laden nok ikke ville være begejstrede for. Løsningen lå lige for: Byg en lukket kasse med isolering (og en dør).
Efter en del besværligheder med et trælastfirma som vi vil undlade at nævne navnet på lykkedes det at få leveret en ordentlig dynge træ, og en flok friske frivillige gik i gang med at bygge.
I skrivende stund er “kassen” bygget op med isolering, og der er trukket kabler til strøm og netværk – og der er endda bygget en fin trappe, så man kan gå op på “taget” af kassen. Her overvejer vi blandt andet at lave en kabine hvor man kan sprøjtemale.
Our space has been equipped with an RFID-based door system since the beginning. It has worked well, but when we got the laser cutter, it was necessary to restrict access to the cutter to members who had received training. At first, the laser cutter had its own simple ‘database’, but it soon became inefficient to maintain two separate fdsfsystems. Also, the door system was not integrated with the member database, so we actually had three different databases that had to be maintained.
So we started talking about making a new system, and after extended discussion we actually started to code. The center of the system ia a backend, written in Rails. The backend provides a web interface for administration, and a REST interface for use by the various peripherals – called ‘machines’.
Configuring a user’s permissions with the web interface.
Viewing the log.
The primary ‘machine’ is the card reader located at the door. It uses the REST API to determine if the card is associated with a user who has access to the space.
Card reader at the entrance
In the same way, a number of other machines (lathe, mill, CNC router, 3-D printers) are equipped with a box containing an RFID reader, a relay, and an ESP8266. The ESP8266 connects to the backend over WiFi. For most of the machines, the power is only on as long as the card is inserted into the reader, but for the 3-D printers, the card can be removed once the print is started (the box measures current consumption of the printer, and shuts off once the print is done and the printer has cooled down).
Card reader at Bungard CNC
Access control box mounted on the Lulzbot Taz printer
Inside of access control box showing PSU, relay, and ESP8266. The version for the 3-D printers has an additional current sensor so that they can determine when the printer is idle.
The front of the access control box seen from the inside, showing card reader loop antenna/switch, OLED display, card reader PCB, and indicator LED.
The backend runs on a Cubieboard (an SBC based on an Allwinner ARM core, with on board SATA) with an SDD for storage. The connection between backend and the door ‘machine’ is USB, so you can open the door as long as there’s power, even if internet access should be down.
The backend is placed near the door and has a display and two buttons; the green one unlocks the door for fifteen minutes, and the red one locks the door.
Vi er lidt for dovne til at lave en rigtig blog-post, så I må nøjes med lidt billeder og video.
Først en video fra vores stand, hvor man kan se næsten alle de ting vi havde med. Dog kan man ikke se de to fine flipdot-displays, hvor det ene efter lidt hacking på stedet kom til at køre Game of Life.
Vi havde i år lavet en flok simple bristlebots, som var en stor succes.
This is the considerations I did when building 1S80P 18650 battery packs, for a DIY powerwall.
My design will go for 14 of these packs in series, for a nominal 48V system.
I wanted a design that was:
Very hard to short circuit, individual cell fuses, and generally as safe as possible
Balanced as much as possible
The design is basically 4 4×5 18650 holders for the top and bottom. The cells I used were all tested for capacity (all above 2000 mAh) and self-discharge (all above 4,1V after several weeks/months), and are all Samsung cells. When assembling the packs I tried to mix the cells as much as possible: this should mean that on average the packs will be approximately the same capacity.
The packs have all the positive metal on the top, and the negative on the bottom. This means that any metal would have to touch both the top and the bottom, to short circuit the pack; this is not possible with a straight piece of metal. The connectors are going out on each side: if they went out the same side it would be possible to short-circuit them. Also, this will ensure that all the cells are discharged at the same rate: if they went out the same side the cells closest to the connectors would be loaded harder than the ones further away. This layout will not be a problem when they are put in series, they will just be alternating up-down. The busbars are shrink-wrapped on both ends, so only the connector is connected.
This means that the packs are impossible to short-circuit by themselves.
The packs are held together by 6 zip-ties: 2 at each end, and 2 in the middle. 5mm holes are drilled in the holders. The zip-ties go through the packs and around the busbars on each side.
The busbars are 4 wires of 2.5mm² wires, that are extracted from a standard AC cable. They are twisted together using a bench vise, and a cordless drill. They are then pre-bent using a template.
The connectors are 25mm² cable lugs. The two ends of the busbar go into the lug, meaning 8 wires of 2.5mm², or 20mm² in total. Depending on the exact calculations, this should be good up to 80A-160A. I intend to load the packs with at most 80A, and normally much less, so this should be fine.
The cells are connected to the busbars by fuse-wires. I used legs from 1/8W resistors, from a batch I tested beforehand. The resistor legs blows at 5A after some time, and in a few seconds at 6A. This should be well within spec, since the fuse-wires are mainly intended to isolate cells that go short-circuit: in this case the other 79 cells will be delivering current to the one bad cell, and the fuse wire should blow very quickly. This is another reason to not build too small packs: you need enough current available that the fuses will blow quickly.
The fuse wire is soldered to the cells, and soldered to the busbars. I used good lead-based solder, I tried crappier and lead-free solder but the results were poor. The positive side is soldered at about 340C, while the negative needs a bit more heat at 350C. For soldering to the busbars I go up to 380C, and move around in a circle since heat management is very much needed.
One concern I have heard from several people is that the cells are losing capacity by soldering. I did a test by soldering a few cells, and leaving a few control cells unsoldered. Then I capacity tested all the cells for a few cycles to check if any capacity is lost. I was unable to find any capacity loss on the soldered or unsoldered cells, so for me that is “myth busted”.
The packs are prepared for a future extension to 1s160P or similar. The holders are all oriented in the same way, and in such a way that 2 80P packs should be able to click together side by side:
Each pack (or set of 2 packs if expanded) will get one Batrium LongMon. It should be fully capable of balancing such a system.
If the hivemind has any ideas or things I missed, I’m very interested in hearing about it!
Last week my A20-OLinuXino-LIME2 one board Linux computer quit working, with a power supply issue. I looked up when it was purchased, and realised it had been in 24/7 service for almost 4 years. I guess that is a good excuse to do a little review. It even turned out that it the board was fine, but the AC-DC power supply brick could not supply enough current anymore.
The relevant specifications of the board, for my uses, are basically:
Dual core 1 GHz ARM Cortex-A7
1 GB memory, 1 Gbit ethernet, SATA connector
LiPo battery connector/charger for UPS functionality
The Lime2 has been tasked with running my home monitoring system, consisting of a Debian installation with a Graphite backend, a Grafana frontend, and a ZoneMinder installation. The Graphite database is running on a software RAID0 of two disks (one on SATA, one on USB): in the beginning it was two spinning disks, but after a few years the random 2.5″ laptop disk I was using crapped out, so it was upgraded to a Samsung SSD. The power budget is strained more or less to the max with two spinning harddrives: The system was only able to boot if the battery was connected, presumably because the voltage would otherwise drop for the startup torque. This problem went away after switching to a SSD.
Software wise the system started out with the Debian supplied by Olimex on a SD-card, a Debian pre-Jessie with a custom SunXi kernel. This system was reasonable, but did experience random hangs after some time of use (I belive I found a bugreport back in the day, but am unable to refind it now). The system was later upgraded to a Debian Stretch with a 4.9 kernel from stretch-backports, that supports the SunXi chipset enough for my uses. The upgrade was rather involved, requiring the correct kernel image, a custom U-boot script and the correct device tree file. Something did of course go wrong, at which point I got to be familiar with the serial console of the Lime2: there is a convenient 3 pin header, that gives access to a TTL serial. Using the serial console, I was able to identify the mistake and correct it. After the upgrade the system has been rock-stable.
The system has been handling the load reasonably: The 1GB of memory is constraining, there is not really any more free memory. The processor is only really strained by the motion detection in ZoneMinder, which uses more or less one core per camera. This will hopefully be optimized a bit, as ZoneMinder is being optimized for the ARM instruction set. Handling only the Graphite/Grafana load would be a breeze, even though the system is receiving ~650 metrics per minute.
All in all, I can recommend the Lime2 board for applications that need a little more umph than a Raspberry Pi, notably on the SATA and Ethernet side, and/or applications that need to be continuously available even after the power cuts out. For applications that need more than one SATA port, or more than one Ethernet port, or on-board Wifi, there are better — and more expensive — options. The price point of 45 EUR + VAT (which did not change from 4 years ago) puts the Lime2 slightly above the price of a RaspberryPi or BananaPi, but below boards like the Apu2. In addition, Olimex has announced that the Lime2 will be available “forever”, making any system designed using the Lime2 future proof — for the foreseeable future.
I ordered a new Lime2, before realising the problem was the power supply. I opted for the industrial variant that is now available. The only change, as far as I’m aware, is that the Allwinner A20 chip is rated for a larger temperature range, and it is 5 EUR more expensive.