Als kleines Nachmittagsprojekt wurde ein Modellbauladegerät in einen alten “Alu-Koffer” eingebaut. Da einige Kabel recht kurz waren und dadurch das Laden erschwert wurde, wurden Durchführungen für die Kabel eingebaut.
Dazu wurde an den notwendigen Stellen mit einem Forstner Bohrer ein Loch in den Koffer gebohrt (22mm). Alternativ kann dazu auch ein Hohlkernbohrer verwendet werden.
Für die Durchführungen wurden nun mit dem 3D-Drucker Abdeckkappen gedruckt. Ein erstes Test mit PLA als Druckmaterial hat sich nicht bewährt, da das Material für die Zinken zu spröde ist. In ABS oder PET(G) stellt das kein großes Problem dar. Wie auf den Bildern zu erkennen, verfärbt sich ABS an starken Knickstellen halt weiß.
Da die Bananenstecker für das Ladegerät etwas störrisch durch die Durchführungen gehen, sollen diese dauerhaft nach außen geführt werden. Es wurde sich dagegen entschieden das Originalkabel abzuändern und z.B. abnehmbar zu machen. Damit die Stecker nun nicht lose in der Gegend hängen, wurde ein Halter gedruckt. Dieser wurde mit geschäumten Doppelseiteigen Tape an den Koffer angebracht. Der Halter für die Bananenstecker wurde auf einer Seite an den Löchern mit einer Fase versehen, damit die Stecker einfacher eingesteckt werden können.
Beide Modelle wurden in Autodesk Fusion360 gezeichnet. Die Zeichnungen wurden parametrisch angelegt. [Das bedeutet, dass einzelne Elemente der Zeichnungen durch Abhängigkeiten (z.b. parralel, rechter Winkel, 2mm Abstand, usw.) miteinander verbunden sind. Daraus ergibt sich der Vorteil, dass Änderungen gemacht werden können und das Modell alle Abhängigkeiten behält die festgelegt wurden. Wenn jetzt der Durchmesser der Kabeldurchführung angepasst werden soll, würde sich das gesamte Modell für die neue Größe wieder aufbauen. Dafür müssen keine weiteren händischen Änderungen gemacht werden.]
Beide Modelle wurden mit einem selbstgebauten JoSeb (I3 Stil) Drucker gedruckt.
For the access control system and different private and space related projects sre regularly uses I²C sensors/devices. For testing purposes it helps a lot, if those devices can be connected to a notebook. So far he either used a VGA adapter (VGA cables contain an I²C signal to transport the display’s DDC information. Most of the open source linux graphic card drivers allow users to access the i2c bus on the adapter using standard tools). Unfortunately newer hardware no longer provides VGA adapters and/or muxes the connectors in a strange way, so that it’s no longer easily possible to use the I²C port.
Another option is using a Bus Pirate, which supports I²C and is connected to the notebook via USB. The Bus Pirate is not supported by the standard kernel interfaces, though. This is not very nice for application development.
Fortunately the kernel supports a few USB based I²C adapters. Most of them are quite expensive in the 100€ range, but one of them requires just an ATtiny85, a crystal and a few resistors/diodes. That one is a project from Till Harbaum, who developed the adapter and provides instructions on his homepage.
sre took that information and designed his own PCB, adding voltage regulators and logic level converts for 3.3V and 1.8V. So most common sensors can be connected easily. Also the PCB has a mini USB connector instead of the huge USB-B connector.
The PCB design allows a nice sandwich-style case as visible in the graphic below (file for a lasercutter). The top left part can be put on top of the PCB and should have the same height as the USB connector. The bottom right part should be put directly below the PCB and should have at least the height of the crystal. Then the other two parts can be put at the bottom and on top of the other two parts. The result is quite stable and does not waste much space. It should be cut out of acryl glass or labels must be added to know the pin assignment.
So let’s have a short look at how it works. Below is the PCB’s schematic. It starts with a pull-up resistor from USB- to Vcc, which tells the USB host, that we are a low-speed device. Then there are two zener-diodes on the data lines to limit the voltage to 3.3V making the device comply with the USB standard. Next there are blocking capacitor for our ATtiny85. Then we have the USB connector, followed by the I²C pull-up resistors on SCL and SDA.
In the next row the ATtiny85 and its crystal follows. Also there are termination resistors of 68 Ohm before the USB pins. Then in the third row we can see the logic level converter for SDA and SCL for 1.8V using a BSS138. Next to it the MCP1755S-1802E provides the 1.8V reference, which is also available from one of the PCB’s pins. Then last but not least the last row contains the logic level converts for 3.3V and the matching voltage regulator (TS1117).
As you can see the hardware setup is pretty simple. The USB communication is implemented in software by bitbanging the ATtiny85’s pins, that are connected to the USB port.
While I’ve been told, that there are Windows and Mac OSX drivers available, I have not tested those parts myself. On Linux the kernel driver has been upstreamed and most distributions have it enabled in their kernel config. As a result it works out of the box. It can be tested by loading the i2c-dev module and using i2cdetect to find the right adapter (You will have to do the following as root). Get the number for the i2c device labeled i2c-tiny-usb and you can scan the bus for devices.
modprobe i2c-dev i2cdetect -l i2cdetect 8
If that works you can start developing in your favourite programming language and switch to e.g. the Raspberry Pi’s native I²C interface at any point by just changing the I²C device number. Of course the adapter can also be used to develop I²C Linux kernel drivers.
For our access control system, we needed a motor lock for our main door. After having a look how other hackspaces solved the problem, we decided to get ourself an ABUS CFA1000. It’s quite popular among Hackspaces, Fablabs and Makerspaces for two reasons:
Once we received the piece of hardware, we opened it up and had a look at the hardware. Usually the ABUS CFA1000 is used together with a simple radio remote control. The manual advertises, that a “secure” rolling-key system is used to encrypt the information exchange. We don’t trust that part and do not need wireless support, so we disabled that part of the ABUS. The radio support is conveniently placed onto its own PCB inside of the CFA1000, so we could just cut the interconnections (Vcc, GND, Signal) between the main PCB and the radio interface PCB. We also removed the radio PCB to gain some space inside of the case.
That left us with a block of hardware, that can (un)lock the door by pressing its buttons. Obviously that’s not pretty useful on its own. Using a digital storage oscilloscope (DSO), we measured, that the buttons connect ground to a pin. Next we desoldered the buttons and soldered a couple of wires instead. These wires are connected to GPIO pins of our access control system sharing a common ground, so that it can “press” the buttons by shortly settings the relevant GPIO pins to low.
So far so good. Other spaces use more or less the same setup and its pretty easy to implement the above changes. But the ABUS CFA1000 also has a small display, which displays its current state (locked/unlocked). That state also changes if the door is opened manually, so we were interested in it. After unsuccessfully trying to find that information via some boolean style pin on the PCB, we decided trying to reverse engineer the protocol used for the display.
The display is laying on top of the main PCB using some kind of foam connector. So it’s easy to probe the outputs from the CFA1000’s µC by removing the display and just connecting a DSO to the PCB pads. On the other hand its hard to do anything with the display without creating some PCB just for that task, since we cannot solder anything to it.
The first thing we noticed after having a look on our scope was, that the display is driven using 4 different voltage levels: 0V, 1V, 2V, 3V, 4V (voltage differs based on the voltage supplied to the CFA1000). Also from the schematics we got the information, that 4 pins are labeled SEG and 5 pins are labeled COM.
Measuring 4 pins at a time due to our scope not providing more input channels, we had a look at all 9 pins and noticed a few things:
We assume, that Pin 5-8 are our COM signals and are some kind of layer selection. It seems there are 4 time slots with each of them having two sub-slots. With that assumption we noticed, that each time slot either contains a 0V/4V pair or a 2V/3V pair. So we assume, that 0V/4V pair means the time slot is a logic “1” and 2V/3V pair is a logic “0”.
We also noticed, that the sub-slots of the SEG pins are inverted compared to the COM pins. So if e.g. SEG4 is on 4V, then the COM pin is either in its middle state, or at 0V. With the second sub-slot being inverted compared to the first one it means the pins are driven in both voltage directions. We assume, that its probably some hack to get the polarity right.
Anyways we still need to know, which pin is used for which segment on the display. Unfortunately we cannot easily connect the display to another PCB and on the ABUS pcb there is no easy method to inject a custom signal to the display. So instead we reconnected the display and let the CFA1000 generate something on the display for us. Then we put a piece of paper between the CFA1000’s PCB and on of the display’s pins and had a look, which segment was no longer displayed due to this. From time to time we had to press some buttons to generate other symbols on the display, because the segments must be enabled in the first place of course. Doing that we could identify basically all pins and created the following pin information graphic (C=COM, S=SEG):
With that we can decode the information from the display. We verified this by removing the display again, connecting our scope and trying to decode the display manually. After identifying a few incorrect pins (probably the piece of paper did accidently cover the wrong pin) and we were happy with the results, we started to think about a PCB doing the decoding for us.
First of all we somehow needed to get the 4-voltage-level signal into a 2-voltage-level binary signal. We initially tried to do that using zener-diodes to cap the voltage combined with some schmitt-triggers. The schmitt-triggeres feed the information into a ATmega then, which decodes the display pins and provides the information via I²C. Unfortunately, that turned out not to work that well. The voltage dropped, because the CFA1000’s µC did not provide enough energy for this setup. The image below shows our first attempt.
After finding a few more issues, we decided to start from scratch using a completly different design based on voltage comparators. We added a 4 comparators checking if the COM pins are above a certain voltage level near the 4V mark and another 5, that check if the SEG pins are below a reference voltage near the 1V mark. After the comparator we have a digital signal, where a segment is enabled if the SEG pin and the COM pin are high.
In theory we could just connect this to an ATmega again and decode the signal now. This time we try to solve the problem in hardware though and add 4 latches - one for each layer/COM pin. The latches will take over values from their input pins, if their “Load” pin is high. So we can simply connect the first COM pin to the first latch’s Load pin, the second COM pin to the second latch’s Load pin and so on. Then the latches will take over values when the layer is activated. The SEG pins on the other hand can simply be connected to each latch. The output pins will then provide the state of all segments (there are 4*5 = 20 possible combinations, but some of them are not used).
We connected the relevant pins to a simple I²C port-expander (MCP23017), so that we can read the display state from our access control system. The expander also provides an interrupt pin to notify the host system, that one of the input pins changed.
So far so good from the digital side. Unfortunately it again did not work as expected. So let’s get out our scope again and check the lines: The voltage comparators work greatly this time and we have nice boolean values behind it.
The screenshot below shows one of the raw COM signals (yellow) together with the cleaned variant (cyan). Also visible is one of the raw SEG signals (purple) together with its cleaned variant (blue). So why is it not working?
Looking further we noticed, that the COM signal is enabled slightly longer, than the SEG signal. Thus our latch will take over incorrect values. We actually want the COM signal to be enabled slightly later than the SEG signal and be disabled slightly before, so that the SEG signal is always valid when the latch takes over values.
On the other hand we do not need good signal edges, so we solved the problem using capacitors. To ensure, that SEG is initialized before the COM signal we started with a capacitor on the COM line. To avoid increasing the problem for the falling edge side, we added a diode, so that the capacitor is discharged fastly here. Now we also added a capacitor to the SEG signals, so that it keeps its value a bit longer. This capacitor must be smaller than the one for the COM signal to avoid breaking the start behaviour.
Below you can see screenshots of the resulting signals. The yellow one is a COM signal and the purple one is a SEG signal. The blue one shows the matching output of the latch. As you can see it keeps it value at high.
With that fixed we ordered a nice PCB in china and soldered it and found it mostly working. Unfortunately we still had two pins wrong, so we had to patch the PCB to get the right signal lines from the latches to the port expander. If we ever need another PCB, we add another port expander and add the additional signal lines and the buttons there instead of directly providing them to the host system.
For our access control system we needed wanted a few
multi-colored status LEDs. Nowadays that basically means, that one gets a few
ws2812b LEDs, since they are quite cheap and already provide a serial
interface. Unfortunately most microcontrollers including the Raspberry Pi have
no hardware accelerated interface for their protocol. For our access control
system we thus use an ATtiny85 to translate from the ws2812 protocol to a more
common serial protocol: I²C.
Below you can see how the ATtiny85 is supposed to be wired. Basically it needs power supply, the I²C interface (SDA, SCL) and the input pin of the first ws2812b LED must be connected to the pin labeled WS2812b. There is also a mode pin, that should be connected to some GPIO of the system controlling the ATtiny85. More on that later.
The ATtiny85 firmware consists of 3 parts: A driver for the ws2812b LEDs, a driver for the I²C interface and some glue-code. Let’s have a look at each part.
Like most microcontrollers, the ATtiny does not have hardware support for the ws2812 protocol. That means we need to generate it ourself by bit-banging one of its I/O pins. Since we did not connect any crystal to our ATtiny to keep the circuit simple, we use it with the internally generated 8MHz clock signal. So one instruction is supposed to be roughly 125ns. By studying the ws2812b timing diagram below, you can see, that we must be able to switch the pin at least within 350ns. As you can see the timing may be possible, but while we are updating the LEDs it’s impossible to do anything else.
The driver itself solves the timing issues by disabling interrupts, since any ever so short interruption will break the ws2812b timing. Then it loops over a supplied array of LED values. There it loops over the bits of each byte and based upon its value it either starts with a long high-sequence or a short high-sequence followed by the matching low-sequence. All of that is done in inline assembly to avoid the compiler doing optimizations breaking the timing.
In theory it would be possible to handle interrupts during the ws2812 update, if we used a timer instead of counting instructions for the precise timing. But our interrupt service routine would have to be finished within 1 or 2 instructions, since we must satisfy the 350ns timing. Obviously that’s not helping much.
Fortunately the ATtiny85 does have hardware support for the I²C protocol making things a bit easier on this side. The hardware block capable of I²C (master and slave) support inside of the ATtiny85 is named Universal Serial Interface AKA USI. I²C is a bus-protocol, which usually has one master and multiple slave devices connected via two wires (not counting ground) named SDA and SCL.
The communication is always started from the master using a start-condition and stopped by a matching stop-condition. After being initialized the USI module will generate a interrupt, if it sees a start or stop condition on the bus, so that it can be handled by our I²C driver.
Then there is a second interrupt for all other i2c related events. Let’s ignore most of them here and just have a look how the data is exchanged. We basically get an event “data received” for each received byte and “data requested” for each byte, that should be send. The byte, that should be sent is simple written to a register of the USI block. Similarly reading the byte when the data received interrupts comes in, we get the byte written to the bus. All bit-level stuff is handled by the hardware.
Our I²C driver also takes care of checking the address (while it receives the data destined for other devices it will ignore any ongoing communication, that was not started with its own address as recipient) and implementing an eeprom style interface.
The base idea of our eeprom style interface is, that we receive
colour-information from the I2C master by receiving a single byte for the LED
number and 4 bytes with colour data. From a bus-level point of view this is
exactly the same as an eeprom with 8-bit address size and 32-bit value size.
For example if you want to set the 11th LED to white you would send the following via
I²C: <device-addr> 0x0a 0xff 0xff 0xff 0x00
. There will be more information
about the additional byte in a later section of this documentation. Once the
I²C driver received all 4 bytes it will call i2c_recv(led, data) in the glue code.
The glue-code combines the I²C driver with the ws2812b driver to something useful. For this task it stores all information received from the I²C driver into an array for the LEDs. Similarly it has a second array, which contains the LED colour information for the ws2812b driver. In theory the same array could be used for both implementations, but the split-architecture allows us to implement some fancy features in our glue-code. Unfortunately it also means, that we need quite a bit of memory (4 bytes for i2c data + 3 bytes for ws2812b data = 7 byte). With the ATtiny85 only having 512 byte of memory that means we can talk to a max. of about 60-70 LEDs.
Now let’s have a look at the 4th byte sent via the I²C interface. Appart from directly setting a LED color, our ATtiny85 should also be able to blink LEDs and fade to some other color. This is encoded in the fourth byte. It’s upper two bits (7&8) can be used to let the ATtiny85 know, what we want to do with the LED:
The remaining 6 bit are a time value, which is multiplied by 31.25ms (32Hz base). For fade mode it describes how long it the (linear) fading should take. For blink and glow mode it describes how long a half period (dark → bright / bright → dark) should take. This means the max. encodable timing is 2 seconds.
As described in the ws2812b section, the update requires disabled interrupts. Updating 50 LEDs requires roughly 62.5us. Disabling the interrupts for such a long time results in problems with the I²C bus. Thus the USI module must be disabled while we update the LEDs (or interrupts must be enabled resulting in broken LED update if there is I²C traffic and thus random blinking).
We worked around the issue by introducing another pin to choose between I²C mode and LED update mode. In I²C mode (mode pin = high) the LEDs are not updated and the timer engine for the fading is stopped (important to make the LEDs blink synchronously). In LED mode (mode pin = low) on the other hand the I²C interface is disabled.
Once the firmware is flashed and the hardware wiring is done you can now control your LEDs using the following interface:
device_addr = 0x23; mode_blink = 0x2 << 6; gpio_set(mode_pin, 1); // send ATtiny85 into i2c mode usleep(1000); // wait until ATtiny85 reached i2c mode i2c_send(device_addr, 0x00, 0x80, 0x00, 0x00, 0x00); // LED0 = red i2c_send(device_addr, 0x01, 0x00, 0x80, 0x00, 0x00); // LED1 = green i2c_send(device_addr, 0x02, 0x00, 0x00, 0x80, 0x00); // LED2 = blue i2c_send(device_addr, 0x03, 0x30, 0x00, 0x20, mode_blink | 8); // LED3 = blink purple @ 2Hz io_set(mode_pin, 0); // send ATtiny85 into led mode
While the status-switch is nice, it does not help to actually get into a hackspace. For this you need some keys and with multiple people having access rights having a single key is quite annoying. While there are a few simple solutions they usually lack some desired features. Thus we decided to implement a digital access control system, that can open our doors.
As visible in the space map, there are multiple ways to get into our Hackspace. Let’s have a look at the main entrance for now. The first door is the building’s entrance downstairs. This is not yet handled by the access control system, since its not exclusively used by us and needs agreements with different people first.
Then in the second floor (not counting the ground level - the building has no first floor) there is a glass-door from the staircase to our front corridor. This door has been armed with a few sensors by us, a door opener as well as a bell button next to it. The corridor is also used as emergency exit from our neighbours, so the glass-door contains a panic lock. It will automatically unlock the door if somebody uses the inner doorhandle. We notice any door opening by the door using a small reed-contact and always know if the door is locked using a bolt-switch. This information is fed into our Grafana instance. If the door is not locked, it can be opened using a door opener (buzzer). Our access control system opens the door, if the bell button is pressed and the space is not closed. If it is closed, the bell button rings the bell instead. A small ws2812b LED inside of the bell button gives a hint about the current space status.
Next, there are two doors going from the corridor onto our main area. One going straight to the main area (AKA main-door) and one going via our conference room. The one going via the conference room is not yet upgraded, but the main-door has the same sensors as the glass-door, as well as the door opener and the bell button. Additionally it already had a keypad, which has been integrated into our access control system. This door also has a motor-lock (using an ABUS CFA1000).
Historically we used the status-switch, to change the space-status and a normal key to (un)lock the door. We are currently migrating away from the switch to a SSH based setup (and an Android app using our custom ssh interface) for changing the space-status. Then the door-lock will automatically (un)lock the space based upon the status provided via ssh. Once unlocked the door can be opened by our members using the keypad. Guests can ring the bell using the bell button instead. There is also an “Open House” mode, which is called “open+” by us. In this mode the bell button directly opens the door.
Below you can see a diagram of all hardware implementing the above. The green boxes are related to the glass-door and the blue boxes to the main-door. The orange boxes relate to hardware on our main area. The red dashed line is a ws2812b bus provided by an attiny85 and provides status indications. The green dashed lines are GPIO handles. Note that those are slightly simplified, as they sometimes contain pull-ups/pull-downs, logic-level converters or even relays to control the actual hardware.
The handling of the GPIOs and other hardware components happens on a Raspberry Pi 2 running a (minimal) Debian and Debian kernel. The device tree has been modificated slightly, so that the kernel knows about the mcp23017 port expanders and the keypad.
Since there is no userspace support for DT overlays in the mainline/Debian
kernel so far; the standard DT blob must be modified instead. The one provided
by Debian’s kernel package can be made readable again using dtc -I dtb -O dts
-o rpi.dts /path/to/rpi.dtb
. Then we add our custom modifications from devicetree-additions.dts.
With that done the software from the github repository linked above can be used. It comes with multiple daemons:
Binary | Description |
---|---|
acs-abus-cfa1000-sensor | Send Bolt State of Abus CFA1000 to MQTT |
acs-abus-cfa1000-setup | Setup Abus CFA1000 (use after power loss) |
acs-gio-actor | Make output GPIO accessible from MQTT |
acs-gpio-sensor | Make input GPIO accessible from MQTT |
acs-i2c-led | Control LEDs connected to the attiny85 |
acs-keyboard | Handle for keypad device |
acs-status-display | Handler for usb-serial display |
acs-switch | Handler for status switch |
acs-keyholder-interface | SSH interface |
acs-mqtt-fwd | Forward SSH data to MQTT |
acs-doorctrl | Control ABUS CFA1000 based from SSH data |
acs-main-door | Handler for main-door bell-button |
acs-glass-door | Handler for glass-door bell-button |
On the RPi a new system user is created e.g. “keyholder”. For this user
the login shell is set to “acs-keyholder-interface”, which runs with
suid bit. It only supports a few commands (actually just “set-status”
and “set-next-status” at the moment). Apart from that you provide a
~/.ssh/authorized_keys in the usual format. Last but not least the user
information must be added to the user DB (usually /var/lib/acs.db
).
If you now try to set the state using ssh keyholder@access-control-system
set-status open+ "Open 4 all!"
the system will check the fingerprint of the
key, that did the ssh login and infer the user information from that generating
a few simple files in /run/acs-state
. These files are interpreted by
acs-mqtt-fwd and acs-doorctrl respectively.
If the deprecated status switch is used to change the status, the files in /run/acs-state are deleted.
Platinen werden üblicherweise aus einer, mit Fotolack und Kupfer beschichteten Trägerplatte, hergestellt.
Es sind dann folgende Arbeitsschritte nötig:
Mit einem modifizierten Inkjet-Drucker ist es möglich das Layout direkt als ätzbeständige Farbschicht auf einer, nur mit Kupfer beschichteten Trägerplatte, aufzubringen. Danach kann die Platine direkt geätzt werden.[1]
Man spart sich also zwei Arbeitsschritte (2 & 3) und eine Chemikalie (Entwickler).
Erfolgreiche Umbauten eines Epson C84 bzw. C87 für solche Zwecke kursieren schon seit ein paar Jahren im Netz [2]. Dieser Drucker besitzt einen keramischen Piezo Permanent-Druckkopf.
Es muss zuerst der Drucker auseinandergebaut und die Schiene auf der der Druckkopf sich bewegt angehoben werden, da wir ja in Zukunft nicht mehr auf dünnem Papier drucken wollen sondern auf Platinenmaterial. Hierzu muss das Metallchassis an einer Stelle durchgesägt und dann höhergelegt und wieder fixiert werden (siehe Abbildung). Auf der rechten Seite des Druckes sorgen Unterlegscheiben für den nötigen Abstand. Auch ist es wichtig die „Parkstation“ für den Druckkopf auf der linken Seite anzuheben, damit dieser nicht ausstrocknet!
Da das Platinenmaterial auf noch wesentlich unflexibler als Papier ist muss der Papiereinzug entsprechend so umgebaut werden, dass das Material horizontal durchgeführt werden kann und auch geführt wird.
Die Hauptarbeit war das Testen unterschiedlicher Parameter wie der Erwärmung vor und nach dem Drucken auf das Platinenmaterial, Ätzmittel und der Tinte. Hier lagen auch die Hauptprobleme vieler Nutzer im Netz. Bei den Standard-Tinten konnten hauptsächlich nur Eisen(III)Chlorid verwendet werden.
Eines Tages und nach vielen Gesprächen später nahm ich allen Mut zusammen und versuchte es mit Edding(r)-Nachfülltinte aus dem Schreibwarenhandel. Diese Tinten gelten allgemein als ätzresistent und werde auch zur Nacharbeitung von Platinen vor dem Ätzen eingesetzt. Es funktionierte tatsächlich (siehe folgende Abbildungen).
vor dem Ätzen
nach dem Ätzen (Beispiel für eine SDR-Platine von DD7LP)
Vorteil bei Verwendung besagter Tinte ist auch, das als Ätzmittel auch
Natriumpersulfat verwendet werden.
Wichtig ist die Druckköpfe vor einer längeren nicht benutzung mit einer
Patronen mit Isopropanol zu spülen, damit die Tinte in dem Druckkopf nicht
eintrocknen kann. Generell sind nachfüllbare Tintenpatronen mit Auto-Reset Chip
zu empfehlen.
[1] http://techref.massmind.org/techref/pcb/etch/directinkjetresist.htm
[2] http://www.cnczone.com/forums/general-cnc-machine-related-electronics/30951-hacking-printer-directly-print-pcbs.html
Der Salatbaum ist ein Projekt, dass wir als Workshop auf dem Freifeld-Festival und am Tag der offenen Tür bei uns angeboten haben.
Dabei handelt es sich im wesentlichen um ein Abwasser-Rohr, das mit Löchern versehen wird, und dann vertikal in einen Blumenkübel gestellt werden kann. So kann man ringsherum Salat oder andere Pflanzen anpflanzen, um auch ohne großen Garten oder Terrasse ein wenig Grünzeug in seiner Wohnung zu haben, und sich vielleicht sogar ab und zu einen Salat davon zu machen.
Dieses “Siebdruck-Dings” nennt man eigentlich “Siebdruck-Maschine”, obwohl es eigentlich gar keine Maschine ist. Es handelt sich hierbei im wesentlichen um eine freistehend montierte Holzplatte mit zwei Scharnieren, an denen man einen Siebdruckrahmen einspannen kann.
Freistehend deswegen, damit man auch Textilien anständig bedrucken kann, indem man es über die Holzplatte zieht. Das verhindert das Durchsickern der Farbe auf die zweite Lage Stoff und lässt sich auch einfacher fixieren.
Mit diesem Hilfsmittel lassen sich einfache Siebdrucke mit Schablonen anfertigen, die z.B. mit unserem Laser-Schneider geschnitten wurden. Auch beschichtete Rahmen lassen sich dort einspannen.
Diese Gerätschaft kam bereits auf einem Siebdruck-Workshop an der Uni Oldenburg erfolgreich zum Einsatz.
Inzwischen sind noch weitere derartige Hilfsmittel dazugekommen, damit mehrere Leute gleichzeitig drucken können.
Der Laser schneidet nicht nur Holz oder Polypropylen, sondern auch Leder. Mein erstes Projekt waren Bundschuhe - oft als Mittelalterschuhe tituliert, aber eigentlich viel älter. In der einfachen Landbevölkerung hielten sie sich jedoch bis ins späte Mittelalter [1].
zu habe ich erst ein paar Lederreste gekauft - zum Kilopreis bei Leder Schomaker [2] (netter Laden, nur leider recht eingeschränkte Öffnungszeiten).
Für die Vorlage habe ich einen meiner eigenen Bundschuhe auseinander genommen und flach fotografiert:
Mit dem Foto als Hintergrund habe ich das als Pfad abgezeichnet. Bei den Bohrlöchern musste ich darauf achten, dass sie “Klone” sind, damit sie alle gemeinsam in der Größe geändert werden können. Damit kann man die Vorlage nämlich einmal auf die Schuhgröße skalieren und und zum anderen die Löcher an das Band anpassen, das man durchziehen will.
So sah dann die Vorlage aus:
Mein Leder reichte nicht für große Schuhe, aber für ein Kleinkind. Hier habe ich die passenden Zentimeter für das Alter gefunden, und die Vorlage auf einen Fuß der Länge 11cm skaliert. (Hinterher ist man schlauer: beim nächsten Mal werde ich sie dabei auch noch stauchen, weil Babyfüße im Verhältnis breiter sind).
Aber bevor das Leder geschnitten wurde, probierten wir es einmal auf Polypropylen, ob der Schnitt passt. Das ergab dann niedliche Plastikschuhe; als Knöpfe durften zwei missglückte Zahnräder aus dem 3D-Drucker mitspielen:
Dann haben wir erstmal mit den verschiedenen Ledersorten und einem Bastelfilz die richtige Geschwindigkeit und Intensität des Lasers erprobt.
Beim ersten Lasern des Leders für die Schuhe hatten wir vergessen, ihn richtig zu fokussieren. Das ergab aber einen netten Effekt, nämlich wurde die Oberfläche nur eingebrannt, und kann jetzt als Demonstration und Unterlage für die Plastikschuhe herhalten:
Und das sind schließlich die finalen Leder-Schuhe, genäht mit einem Seidenband:
An den Zehen werden sie einfach im Kreis zusammengenäht, zum Schließen wird auf eine Seite ein Knopf festgenäht, auf der anderen Seite ein Band einmal rund eingezogen. Die Ferse ist ein kleines bisschen anspruchsvoller, deswegen hier eine Anleitung. Die Löcher sind im Bild benannt, in der Anleitung bedeutet L3-I “von innen durch das Loch L3” und L5-A dementsprechend “von außen durch das Loch L5”:
R1-A R2-I N1-I M2-A L3-A L4-I M3-I R5-A R6-I L6-A L5-I N3-A R4-A R3-I N2-I M1-A L2-A L1-I
Die beiden Enden (die ja aus R1 und L1 rauskommen) werden dann nach innen gezogen und vor der Mittellasche verknotet (dabei hilft es, den Schuh kurz auf links zu drehen). Der Knoten wird dann halb von den beiden Seitenlaschen (die mit den Löschen L1-L6/R1-R6) verdeckt.
Hier nochmal ein Detailbild von hinten:
Dieser Artikel beschreibt den Bau eines Debug-Adapters für das Nokia N900 Smartphone. Dieser ermöglicht den Zugriff auf eine die serielle Schnittstelle, so dass Debug-Ausgaben des Kernels abgefangen werden können.
Hürden für den Bau eines solchen Adapters stellen hauptsächlich zwei Probleme:
Um einen nicht bootenden Linux-Kernel genauer zu analysieren wird üblicherweise auf eingebetteten Geräten JTAG und/oder eine serielle Schnittstelle als Debug-Ausgabe verwendet. Auf dem von mir verwendeten Smartphone von Nokia, dem N900, wird eine solche serielle Schnittstelle in Form von Testpads herausgeführt. Das Pinout für die serielle Schnittstelle wurde bereits vor meiner Arbeit von Hackern der Maemo-Gemeinschaft analysiert und dokumentiert (N900 Debug Ports), so dass auf vorhandenes Wissen zurückgegriffen werden konnte.
Für den Bau des Adapters habe ich zunächst Federkontaktstifte (GKS-181 305 080 A 1500 L) besorgt, welche den eigentlichen Kontakt zum Testpad herstellen sollen. Diese sind z.B. auf ebay erhältlich.
Als nächstes habe ich das geöffnete Telefon in einen Flachbrettscanner gelegt, um die Positionen der Testpads zu erhalten. Zusätzlich habe ich die Maße des Akkufachs mit einer Schieblehre abgemessen, um die Grafik korrekt zu skalieren.
Als nächstes habe ich die Grafik in Inkscape geöffnet und die wichtigen Strukturen vektorisiert, so dass ich mittels CNC-Technik einen eigenen Akku herstellen kann, der an den Testpads Löcher für die Kontaktstifte hat.
An die Kontaktstifte wurde von mir ein Pegelwandler (Sparkfun 8745) angeschlossen, welcher das TTL-Signal von 5V oder 3.3V auf 2.7V wandeln kann. Dazu benötigt er eine 5V/3.3V Referenzspannung, sowie eine 2.7V Referenzspannung. Hierzu wurde von mir ein LM336Z (von Pollin) verwendet, welcher aus 5V eine 2.5V Referenzspannung erstellt. Damit kann auf einer Seite des Pegelwandlers ein normaler 5V USB-TTL-Adapter angeschlossen werden und auf der anderen Seite der serielle Port des N900.
Zum Schluss habe ich noch ein kleines Gehäuse für den Akku designt, damit dieser einfach mit dem Debug-Adapter verbunden werden kann.
— Sebastian
Ich habe die Buchstaben einzeln mit dem Styroschneider ausgeschnitten. Als nächstes wurden die Buchstaben mit weißem Acrylack auf Wasserbasis zwei mal gestrichen. Da ich noch eine Dose KFZ-Lack hatte habe ich die Buchstaben damit lackiert. Die Grundierung mit dem Acrylack verhinderte das Zerfressen der Buchstaben durch das Lösungsmittel im KFZ-Lack. Aus einem Rundholz habe ich die Abstandshalter zugesägt. Mit unserem Drucker Plotter habe ich mit eine Schablone gedruckt um die Buchstaben später zu positionieren.
Auf der Rückseite habe ich LED-Stripe verlötet.
Hier die Rückseiten mit Stripes und Abstandshaltern welche mit doppelseitigem Klebeband befestigt wurden und hoffentlich halten.
Seit dem 1.11.12 bin ich Mitglied, und am 3.11. war ich das erste Mal “so richtig” im Hackspace, der jetzt den schönen Namen “Mainframe” trägt. Ich kam gerade rechtzeitig zu einem Vortrag der Mainframe-Reihe, über Fourier-Analysen: war spannend und gut erklärt, und ich konnte meine Mathe-Kenntnisse an einem praktischen Beispiel - mit Elektronik-Demo! - auffrischen.
Danach fing ich mit meinem ersten kleinen Projekt an. Ich wollte das Logo des Spiele-Kleinverlags Flying Games aus Styropor ausschneiden, um es dann bei Spielevorstellungen an einer langen, dünnen Stange über dem Spieltisch “fliegen” lassen zu können. Das Logo hatte ich von Markus, dem Verleger, als PDF im Vektorformat bekommen. Im Original sah das so aus:
Das musste ich jetzt in eine SVG-Datei umwandeln, die nur noch einen langen Pfad enthält. Zunächst verband ich also die Umrisse des Logos (die beiden Flügel mit der Spieleschachtel in der Mitte) und erhielt das hier:
Die Buchstaben “F” und “G” machten mir etwas Kopfzerbrechen, ich beschloss schließlich, sie von unten her anzuschneiden und durch die gleiche Öffnung wieder zurückzukehren zum Umriss. Damit würde das Logo dann zwei schmale Löcher bekommen, aber die könnte ich hinterher vielleicht wieder kleben. Die Vorlage sah dann so aus:
Damit ging es dann zum PC, der den Styroschneider steuert. Die SVG-Datei wurde dort mit Inkscape geöffnet, und das Plugin sollte sie in GCode umwandeln. Damit wird der Schneider angesteuert - ist auch Thema im nächsten Mainframe-Vortrag.
Zunächst war die generierte Datei aber leer. Ich hatte vergessen, den Pfad auch an einer Stelle zu öffnen, damit der Styroschneider einen Anfang hat. Außerdem mag das Plugin wohl keine gruppierten Objekte. Auch mit der Skalierung passte es noch nicht ganz (das Modell war viel zu klein), aber das konnte in Inkscape leicht angepasst werden.
Dann hatten wir gültigen GCode und mussten nur noch den Styroschneider an die richtige Position fahren und ihm sagen, wo im Koordinatensystem des Objekts er anfangen sollte. Und los gings! Schließlich war das Logo fertig und sah so aus:
Und mit dem Video vom Schnitt habe ich ein weiteres erstes Mal gewagt: mein erstes Youtube-Video.
Manchmal fällt uns ein Projekt auch einfach in den Schoß. So wie dieses Lauflicht aus 192×14 LEDs. Das Gerät gehört einem Freund des Vereins, der aber gerade wenig Zeit und Muße hat, sich der Herausforderung zu stellen, das gute Stück zu programmieren und somit wieder nutzbar zu machen. Denn dummer Weise fehlt die zur Programmierung notwendige proprietäre Tastatur zu diesem über 30 Jahre alten Schätzchen. Also hat er es uns in der Hoffnung vorbeigebracht, dass sich bei uns jemand finden würde, der Lust auf diese Herausforderung hat.
Hardware die nicht funktioniert oder von der niemand weiß wie sie funktioniert und dann auch noch mit blinkenden LEDs.
Diesmal wurden unsere Spezialexperten für alte Hardware schwer gefordert. Es gab keine Handbücher und auch das vorhandene Typenschild verriet uns nur, dass die Hardware das letzte mal 1985 gewartet wurde. Es musste also alles selbst herausgefunden werden. Gesagt getan. Das Gehäuse wurde aufgeschraubt, der Controler teilweise ausgebaut mit einem Logic Analyser verbunden und die zuletzt einprogrammierte Animation durchlaufen gelasssen. Der Logic Analyser hat dabei die Signale aufgezeichnet, die an den Controler geschickt wurden. Dadurch war es möglich, die einzelnen Kommandos nachträglich genau auszuwerten. Leider ist es natürlich nicht so, dass einem die Geräte sagen, was warum wann gerade getan wird. Also starrt man manchmal mehrere Stunden auf solche Kurven wie in dem Bild.
Man überlegt, warum gerade an dieser Stelle jetzt gerade Strom an oder aus gestellt wird, verrennt sich von einer in die nächste Theorie, weiß irgendwann nicht mehr, warum man die letzte wieder verworfen hat. Schließlich kommt man auf die selbe Idee zwei oder drei mal und ist am Ende soweit für den Tag Schluss zu machen, um es am nächsten Tag erneut zu probieren.
Und an dieser Stelle hat sich das Konzept Hackerspace voll ausgezahlt; es passierte, was passieren soll: Jemand, der bisher völlig unbeteiligt war, lief vorbei warf einen kurzen Blick auf den Bildschirm sagt etwas wie “Sieht für mich aus wie eine Binäreadressierung”. “HEUREKA!” genau das war’s. Jede LED der ersten Spalte wird mit einer Zahl zwischen 0 und 13 in Binärdarstellung angesprochen, dann wird sie entweder auf an oder aus gestellt und, wenn man damit fertig ist, werden alle Spalten eins weiter geschoben. Danach wird die neue letzte Spalte bearbeitet. Dies geschieht so schnell, dass es am Ende wie eine flüssige Animation aussieht. Mittlerweile können wir also unsere eigenen Animationen abspielen. Und wie üblich, wenn wir sich bewegende LEDs haben, wollen wir auch damit spielen: Der nächste Schritt ist also die Implementierung eines Jump-and-Runs à la Super Mario auf 192×14 LEDs. Mal gucken wie schnell das fertig ist. Und wenn wir spielen können, freuen wir uns natürlich über neue Gegner, die versuchen, unsere High-Scores zu knacken.
Ein echter Dauerbrenner bei uns ist das kreative Arbeiten mit Mikrocontrollerschaltungen. Auch gerade auf neue Gäste im Beta-Space übt dieser Bereich der Elektronik große Anziehungskraft aus. Um hier den Einstieg möglichst leicht zu machen und unsere Aufbauten möglichst untereinander kompatibel zu halten, hat sich die quelloffene Mikrocontrollerprogrammierung mit Arduino quasi als “Standard” etabliert. Auch mit überschaubaren Hardware- und Programmierkenntnissen ist es damit möglich, interaktive Objekte zu steuern oder reaktive, anfassbare Dinge zu bauen. Entwickelt wurde die Plattform maßgeblich von Massimo Banzi, einem italienischen Professor. Ihm waren die hohen Kosten und die hohen technischen Hürden ein Dorn im Auge, die man für die Programmierung von Mikrocontrollern in der Zeit vor der Einführung des Arduinos nehmen musste.
Um die ersten Schritte im Umgang mit der Arduino-Plattform zu erlernen, haben wir sehr gute Erfahrung mit dem großartigen Comic von Jody Culkin gemacht. Hier wird in quietschbunten Comicgrafiken das Grundlagenwissen rund um den kleinen blauen Tausendsassa und seine Software vermittelt.
Leider gab es den Comic bislang nur in englischer Sprache. Da wir nun aber auch einige Mitglieder haben, die gerade beim Erlernen neuer Dinge lieber auf die eigene Sprache zurückgreifen, hat sich unser Mitglied Thorben Weber der Übersetzung des Comics ins Deutsche angenommen. Da das Original unter einer Creative Commons Lizenz steht, war dieses Unterfangen auch unproblematisch möglich, sogar erwünscht.
Die deutsche Übersetzung des Comics kann sich nun jeder unter http://arduinocomic.kreativitaet-trifft-technik.de/ ansehen und herunterladen. Überzeugen sie sich selbst wie einfach es ist in die Mikrocontrollerprogrammierung mit Arduino einzusteigen.
Wer Lust hat, selbst einfach mal mit einem Arduino zu experimentieren, kann uns gerne im Space besuchen. Wir halten immer einige unserer selbstgemachten Arduino-Einsteigersets mit Arduino und weiteren Bauteilen zum Ausprobieren vor. Natürlich helfen wir Einsteigern immer gern, die ersten Schritte in die Welt der Mikrocontroller zu gehen.
Wenn man vier mal in der Woche 15-25 kreative und technisch begabte Leute auf einem Haufen hat, denen man dann auch noch ein wenig Geld oder Hardware in die Hand drückt und sagt, “macht mal”, kann eigentlich nur Großes daraus entstehen.
Vor lauter Basteln haben wir vielleicht etwas vergessen, auch mal Außenstehenden mitzuteilen, was wir eigentlich so alles Tolles machen. Das soll sich jetzt endgültig ändern. In der nächsten Zeit wird es an dieser Stelle immer wieder Berichte über die Projekte geben, die bei uns im Beta-Space entstanden sind oder gerade im Entstehen sind. Den Anfang macht:
Projekt: “Terminals”
Im Beta-Space standen schon seit kurz nach der Eröffnung drei serielle Terminals, die vor Jahren von unserem ersten Vorsitzenden Patrick vor der Verschrottung gerettet wurden. Nun gibt es ein Projekt zu diesen alten Schätzen aus den 70er-Jahren. Erklärtes Ziel ist es, den Geräten wieder Leben einzuhauchen.
Zunächst muss man vielleicht erklären was ein serielles Terminal ist: Bevor Personal Computer Einzug in Büros und Haushalte fanden, hatten viele Unternehmen Großrechner. Großrechner sind wie der Name schon andeutet vor allem groß und dabei laut, aber auch “leistungsstark” – zumindest für ihre Zeit. Mehrere Mitarbeiter teilten sich häufig die Rechenleistung eines dieser Rechner. Um gleichzeitiges Arbeiten zu ermöglichen, gab es Terminals, die über keine bzw. kaum eigene Rechenleistung verfügten. Die Eingaben, die ein Benutzer tätigte, wurden an den Großrechner gesendet. Dieser verarbeitete die Daten und sendete daraufhin eine Antwort an das Terminal zurück, das die Antwort auf dem Bildschirm anzeigte. Ein Terminal ist also im Wesentlichen eine Tastatur mit Monitor.
Nachdem die Terminals nun schon über 20 Jahre alt sind, war der erste Schritt herauszufinden ob sie überhaupt noch funktionieren. Dank Handbüchern war es nicht so kompliziert mit einem angeschlossenen Computer ein “Hello World” auszugeben. Nach kurzer Zeit waren auch kleinere Animationen kein Problem mehr. So kam schnell die Idee auf, einfache Animationen über alle drei Geräten laufen zu lassen. Aber wer will dafür schon die ganze Zeit seinen stromhungrigen Laptop zur Verfügung stellen. Wir brauchten also einen “Großrechner”. In unserem Fall übernimmt ein kleiner Arduino diese Rolle.
Arduinos haben serielle Schnittstellen, mit denen die Terminals allerdings nicht direkt angesteuert werden konnten, da sie die falsche Spannung liefern (0/5 V anstatt -12/+12 V). Mit einem kleinen IC lies sich aber auch dieses Problem in den Griff bekommen, sodass jetzt alle drei Terminals von einem Arduino angesteuert werden können. Mit diesem Aufbau lässt sich beispielsweise eine Laufschrift über alle drei Monitore realisieren. Wer schon mal bei einer unserer Veranstaltungen war, konnte das auch schon live bestaunen.
Aber wir wären ja keine richtigen Hacker, wenn uns eine einfache Laufschrift schon reichen würde. Die nächste Stufe war: “Warum können wir die Animationen während sie laufen nicht verändern?” Wenige Sekunden nachdem diese Frage gestellt wurde hieß es im Beta-Space dann weiter: “Warum können wir eigentlich nicht Pong auf den Dingern spielen?”
Gesagt getan: Mittlerweile sind an den Arduino zwei Playstation Controller angeschlossen, Pong und Snake wurden programmiert, und wir freuen uns über entspannte Spieleabende in originalgetreuer grün-schwarzer- und oder bernsteinfarbender Monochromoptik.
Wer auch mal spielen möchte, der kommt einfach mal im Beta-Space vorbei und fordert einen von uns heraus.
Ob unsere Räume gerade geöffnet sind kann schon seit März 2012 auf unserer Webseite neben unseren üblichen Öffnungszeiten live eingesehen werden.
Wer es genauer wissen will sieht unter http://status.ktt-ol.de sogar, wie lange der Space schon offen ist, wieviele Leute aktuell über unseren Freifunk-Knoten im Internet surfen und welches Wetter wir drinnen und draußen haben. Wer dann auf der Statusseite verbleibt, der wird sogar zu der sich ebenfalls live aktualisierenden Anzahl aller Leute, hinzugezählt, die den Space-Status im Auge haben.
Hauptbestandteil ist ein aus China importierter imposant großer Messerschalter, der in Deutschland den VDE-Fingertest nicht bestehen würde. Dieser hängt an einem Mikrocontroller mit aufgestecktem Internetanschluss. Es werden nur unschädliche 5 Volt geschaltet, die dem Mikrocontroller sagen, ob jemand den Schalter gerade umgelegt hat.
Wenn dies geschieht geht sofort eine kleine Nachricht an unseren Server im Internet, der die frohe Botschaft spontan weiterverteilt. Da das Umlegen des Schalters nicht zuletzt wegen der spontanen Reaktion im Browser ungeheuer Spaß macht, haben wir das Posten der Nachricht auf Twitter um einige Minuten verzögert.
All diese Informationen sind über die Space-API, die von 26 internationalen Hackerspaces genutzt und weiterentwickelt wird, global verfügbar.
IMG
Und natürlich gilt: “There’s an App for that” (zumindest für Android)
Als erstes Projekt, an dem wir im Space arbeiten, soll heute der Styroschneider vorgestellt werden.
Die Idee einen Stryoschneider zu entwickeln hat sich aus einem anderen Projekt ergeben, dem Return-to-Launch-Wetterballon. Um für den Wetterballon ein Gehäuse, Steuerruder und ähnliches zu bauen wurde ein leichter, druckänderungsunempfindlicher und falls möglich auch kostengünstiger Werkstoff benötigt. Nach einiger Überlegung und der Entdeckung dieses Projekts fiel die Wahl auf Styropor und den Nachbau des CNC-Hotwires.
Die Idee hinter dem Styroschneider ist relativ simpel. Man verwendet durch Schrittmotoren gesteuerte Aufhängungen, auf zwei Seiten eines Styropor-Blocks, die einen heißen Draht führen, der wiederum das Styropor schneidet. Die Ansteuerung geschieht dabei wie bei einer CNC-Fräse über G-Code Anweisungen.
Das ist zwar nicht unser Styroschneider, unser soll aber am Ende auch so funktionieren. Um leichter transportabel zu sein, wir werden mit dem Beta-Space ja noch mindestens einmal umziehen müssen, soll unserer Variante allerdings unter einen Tisch montiert werden.
Mittlerweile sind die ersten Arbeiten an unserem Styroschneider abgeschlossen. Die Grundplatte auf der die Elektronik und die benötigten Motoren angebracht sind ist zugeschnitten und mit bisher zwei Schrittmotoren und einer Aufhängung für die Steuerung des Drahts versehen worden. Gestern konnte dann auch die Kalibirierung der beiden Motoren abgeschlossen werden und damit wir auch ein bisschen was zu präsentieren haben wurde der Styroschneider kurzerhand zum Behelfsplotter umgewandelt. Dank G-Code Steuerung und angeschlossener Verarbeitung von SVG-Dateien konnten dann gestern Pacmans, Nikolaushäuser und KtT-Logos geplottet werden. Und so sieht das ganze aus.
Viel Spass mit den Videos und hoffentlich bis bald im Beta-Space
To be continued…
Mit steigender Mitgliederzahl und mehr als 5 verschiedenen Produkten im “Kiosk” des Hackspaces wurde das führen und auswerten von Strichlisten immer aufwändiger. Aus diesem Grund wurde von uns Software entwickelt, welche die Daten von Beginn an digital vorhält.
Das Shopsystem läuft auf einem Raspberry Pi, an welchen ein serieller Barcode Scanner angeschlossen ist. Desweiteren ist an den Raspberry Pi ein Monitor angeschlossen, welcher die letzten Vorgänge protokolliert. Jedes Mitglied kann sich mit einem (ungeschützten und leicht fälschbaren) Barcode einloggen, dann beliebige Produkte kaufen indem er deren EAN Barcode scannt und sich schließlich mittels eines logout barcodes ausloggen. Um zu verhindern, dass Personen den Barcode anderer Mitglieder scannen bekommen diese gegen 8 Uhr eine E-Mail, in der die eingekauften Produkte des Vortages aufgelistet sind. Am Anfang des folgenden Monats kommt dann, ebenfalls per E-Mail, die Rechnung für den gesamten Monat. Diese wird, zusammen mit einer einfach auswertbaren CSV-Datei auch an den Schatzmeister geschickt, welcher dann das Geld von den Mitglieder Konten einzieht.
Das Eintragen neuer Produkte geschieht über ein Web-Interface. Über dieses kann auch die Mitgliederdatenbank des Systems aktualisiert werden (import einer CSV-Datei) oder der aktuelle Warenbestand eingesehen werden.
Der Forumslader ist ein Ladegerät für's Fahrrad, dessen Nachbau für private Nutzung erlaubt ist. Er ist dazu gedacht, Mobiltelefone oder Navigationsgeräte während des Radfahrens zu betreiben bzw. aufzuladen.
Wir haben uns für den Nachbau die 12V Variante mit USB ausgesucht, und ein paar Anpassungen vorgenommen. So haben wir z.B. den 5V-Teil der Schaltung, die für die Spannungsregulierung für USB zuständig ist, durch einen fertigen Chip ersetzt.
Gehäuse und Formfaktoren unterscheiden sich bei unseren Geräten danach, wie derjenige sein Gerät am Fahrrad montieren oder benutzen möchte. Auf dem Bild z.B. wurde der USB Ladeanschluss in den Lenker integriert. Einige Geräte wurden auch um eine 12V Anschlussmöglichkeit oder einen schönen Rundstecker für die Stromabnahme des Nabendynamos erweitert.
Eine komplette Übersicht von Schaltplänen, Prototypen und vorgenommenen Anpassungen, gibt es im Wiki.