STorM32 BGC: 3-Axis STM32 Brushless Gimbal Controller

I present here the STorM32 BGC project. It is a controller for brushless gimbals with 3 axes, and is based on a STM32 32-bit microcontroller.

The project actually consists of three parts, the STorM32 BGC controller board, the firmware o323BGC for this board, and the Windows GUI o323BGCTool:

  • Controller Board STorM32 BGC
  • Firmware o323BGC
  • Windows GUI o323BGCTool
(open source, see here)               
(free, see here)
(open source, see here)

Strictly spoken, ‘STorM32 BGC’ refers only to the hardware, but I will use this label also for the whole project.

storm32 bgc v017 test microgimbal olliw
(Test setup using a micro gimbal and STorM32-BGC v0.17 controller board, and first demo video using this setup)

(Demo video showing the advantage of a 2nd IMU, which is an intrinsic part of the STorM32bgc concept.)


  • 19. June. 2014: Firmware v0.33 released
  • 28. Mai. 2014: Firmware v0.31 released
  • 21. Mar. 2014: New board STorM32 BGC v1.3 released (this will now really be the “final one” for quite a while)
  • 20. Mar. 2014: Firmware v0.25 released
  • 20. Feb. 2014: Wiki created for documentation:
  • 19. Feb. 2014: The new board STorM32 BGC v1.2 has arrived today, and it is working absolutely perfect! :)
  • 6. Feb. 2014: Development goes on, new board STorM32 BGC v1.2 ordered
  • 11. Jan. 2014: Board STorM32 BGC v1.1 works!
  • 2. Dez. 2013: GitHub Repository created:
  • 26. Nov. 2013: Bluetooth module HC06 installed, works as expected, Windows GUI augmented by an auto-configuration utility
  • 21. Nov. 2013: Take off, the first batch of print boards STorM32 BGC v0.17 has arrived

Useful links

Recent highlights

I am pleased that Martinez agreed to do the layout of the (first, v0.17) STorM32 BGC board. I was also ‘allowed’ to move around some wires, but the hard part of the routing was done totally by him, and he indeed did a fantastic job!
I also want to thank various individuals for support in different ways: erickwesz, hexakopter, KingDaKa, Marc, yang/wdaehn, careyer&TheBlindHawks, Greg Covey, fpvberlin

I. STorM32 BGC: Concept

The board was in principle designed to serve “larger duties”. The current firmware doesn’t yet make full use of its potential, but that’s why the project is not yet at its end ;) . Hardware-wise the STorM32 controller provides these (partially innovative) features (for the current version v1.3):

Processor: 32-bit microcontroller STM32F103RC or STM32F103RB or STM32F405RG
The board has been designed to accomodate the 32 bit microcontrollers STM32F103RC or STM32F103RB, which run at 72 Mhz, as well as STM32F405RG, which runs at 168 MHz and in addition provides a floating point unit. Currently the STM32F103RC is recommended.

Motor drivers: TC4452
The TC4452 drivers are actually designed as Mosfet drivers, but it turned out that they are also well suited for our purposes. They allow for a maximum voltage of 18 V, and hence operation at up to 4 S. The data sheet specifies a maximum current of 13 A peak and 2.6 A continuous per motor phase, but that’s unrealistic (heat!). A realistic maximal value is 1.5 A per motor (for DFN8 packages); fortunately more is rarely needed. The disadvantage of the drivers is its limitation to 18 V or 4 S. The great advantage however is its – in comparison to discrete drivers – high fault tolerance (or, as it is expressed so nicely in the data sheet: “These devices are essentially immune to any form of upset.”).

Interfaces: USB, UART, and Bluetooth
The board provides a USB port, which shows up as virtual com port on the PC. It also provides the usual serial UART port (a USB-TTL adapter is needed to connect to a PC). In addition, the board can be equipped with a HC06 bluetooth module hence providing wireless connection (which is cool!).

Ports: PWM, Sum-PPM, Spektrum, Futaba S-Bus, IR Led, Joystick, Button, AUX
The board provides 7 ports (3 ports with STM32F103RB), which can be used as inputs or outputs for RC signals (PWM/Sum-PPM). These ports are 5 V tolerant. A Spektrum satellite as well as the Futaba S-bus is supported. In addition 3 further ports (7 ports with STM32F103RB) are available as general inputs/outputs (they too are 5 V tolerant). The board also provides 3 analog-digital converter inputs (3.3 V maximal), to connect e.g. a joystick. A further port is offered for connecting a button. Finally, one port is available for connecting a IR led.

The motor drivers, the usage of the microcontroller ports, and the voltage supply are designed for a safe operation, inclusive a reverse voltage protection. Furthermore, a voltage devider is integrated for measuring the battery voltage; in case of e.g. too low voltage the motor drivers are shut down.

On-board 6DOF IMU
The STorM32 controller has a separate 6DOF IMU chip MPU6050 integrated on the board. Alternatively a second IMU can be connected to an additional I2C port. This should allow for exciting novel features in the future.

Magnetometer or 10DOF IMU
Instead of the common MPU6050 module mounted on the camera, also the GY-86 10DOF IMU module can be installed, which provides an additional magnetometer for compensating the drift in the yaw axis. However, in praxis, this doesn’t (yet) work really well because of some fundamental issues with the working principle. And in fact a magnetometer is not really needed..

The STorM32 BGC board is open source hardware, under the terms of the TAPR Open Hardware License as published by the Free Hardware Foundation, see The Eagle and Gerber files can be downloaded below. The TAPR licence explicitely permits a commercial use, with some (easily accomplished) conditions, such as e.g. that copyright logos are not removed. The firmwares/softwares are subject to the licences/terms of usages given below.

Data sheets
STM32F103RB, STM32F103RC, STM32F405RG, TC4452, MPU6050, HC06, HM10

II. STorM32 BGC: Board v1.3


processor: STM32F103RC at 72 MHz
motor drivers: TC4452VMF
on-board Bluetooth (optional)
on-board 6DOF IMU (MPU6050)
IR led port
Futaba S-Bus
Spektrum satellite port
up to 7 PWM/Sum-PPM inputs/outputs
joystick for each axis
additional I2C port (I2C#2)
3 auxiliary ports
BUT port
voltage: 6 – 18 V or 2 – 4S
current: max. 1.5 A per motor (see also here)
dimensions: 5 cm x 5 cm, holes Ø3 mm, distance 45 mm
weigth: ca 13 g

Electric scheme and board layout

storm32 bgc v130 scheme sheet1 olliw storm32 bgc v130 scheme sheet2 olliw
storm32 bgc v130 top bottom olliw

Parts list

See the wiki article How to order the electronic parts – BOM for v1.3.

The placement of the parts is shown in the next picture, which gives the values of the resistors and capacitors. The other parts are not labelled since there shouldn’t be any confusion about their locations.

storm32 bgc v130 top-bottom wvalues olliw
storm32 bgc v130 board dfn mpu olliw
(The v1.3 board, incl. the optional MPU6050)


  • voltage regulator in DPak/TO-252 package
  • AUX2 instead of 3.3V pin at AUX port
  • solder jumper to disconnect bluetooth led
  • values of resistors R12, R13, R22 changed (not critical)

v1.2 rev2:

  • cream pad added to DFN packages
  • silk for DFN packages a bit imporved

v1.2 rev1:

  • value of R11 changed to 1.5k


  • minor errors in v1.1 corrected (order of pins of I2C#2 connector reversed, SWD port labelling corrected, stop mask added to big battery solder holes)
  • USB disconnect pin network changed (as suggested by ala42, THANKS)
  • XOR gate added to RC-0 pin to support Futaba S bus
  • Spektrum satellite port added
  • “cooling pad” for LDO added
  • reinserted Vbat reverse voltage protection diode as in v0.17, using smaller diodes though
  • all parts named/valued properly to produce a good BOM
  • further smaller changes in the scheme and layout


  • reverse voltage protection using p channel fet (SOIC8)
  • large solder pads and holes for battery connection
  • layout allows using TC4452 motor drivers in DFN package
  • I2C#2 connector
  • high-side open collector (pnp) port for driving a IR led
  • sequence of pins changed for the RC and SWD ports
  • further smaller changes in the scheme and layout

Older boards

STorM32 BGC v1.2

STorM32 BGC v1.1

STorM32 BGC v0.17

III. Firmware o323BGC

For the description of the firmware see the STorM32-BGC wiki. Here only some technical infos are given.

To the best of my knowledge the o323BGC firmware/STorM32BGC board is currently the only functional free/open source 3-axis gimbal controller which provides these features:

Some features (v0.25):

  • this is probably the best feature of all: the motor direction is determined automatically… this removes really a lot of issues in setting up the gimbal, in particular of the yaw axis
  • the IMU/MPU6050 module can be mounted in any of the 24 possible orientations, the GUI makes setting this up very simple
  • bluetooth: the firmware together with the GUI provides an auto configuration tool for a one-click setup of the optional on-board bluetooth module
  • battery voltage measurement: it is used for a lipo saver function (I wouldn’t want to be without that anymore!) and an automatic voltage drop compensation feature of the PID controller
  • pan/follow mode on all three axes
  • camera orientation controllable by external rc signals and/or a joystick in all three axes
  • external control of camera orientation can be adjusted precisely, speed limits as well as acceleration limits can be set
  • IR led remote control of camera: shutter, shutter delayed, video on/off
  • Mavlink-type commands for a remote control of the camera by e.g. an app
  • the startup procedure includes a dedicated no-oscillation detection scheme, this I found crucial for a good gyro calibration in particular of the yaw axis (minimizes drift in the yaw axis)
  • quaternion based IMU algorithm (Mahony type), with unique mechanism for suppresing the drift in the yaw axis without magnetometer
  • adaptive acceleration correction to avoid/minimize horizon drift in high-g maneuvers

Note, this is not a list of wishes/plans but a list of available and working features! :)

Motor PWM frequency: 23.4 kHz
The STM32 allows to choose the motor PWM frequency freely in a relatively large range. I have choosen 23.4 kHz. This corresponds to a resolution of the PWM signal of about 10.5 bits.

Control frequency: 0.67 kHz
The main loop is repeated every 1.5 ms.

Angular resolution: 10 bits
This number depends to some extend on how it is exactly calculated. In comparison to 8 bit BGC boards the angular resolution is however significantly larger.

The o323BGC firmware is free (but not open source). Besides unlimited private use you are also granted the permission to use it for commercial purposes under the condition that (1) you don’t modify the firmware, e.g. remove or change copyright statements, (2) provide it for free, i.e. don’t charge any explicit or implicit fees to your customers, and (3) correctly and clearly cite the origin of the firmware and the project web page in any product documentation or web page.

IV. Windows GUI o323BGCTool

For the description of the Windows GUI o323BGCTool see the STorM32-BGC wiki. Here just some “teaser” screenshots of a preliminary version are shown to indicate the rich set of features:

0323bgctool setupmain olliw 0323bgctool datadisplay olliw
0323bgctool setupgimbal olliw 0323bgctool setuprcinputs olliw 0323bgctool setupexpert 0323bgctool configureimu olliw
0323bgctool configuremotors 0323bgctool flashfirmware olliw 0323bgctool btconfigtool olliw

The o323BGCTool software is open source (but see below). Besides unlimited private use you are also granted the permission to use it for commercial purposes under the condition that (1) you don’t modify the software, e.g. remove or change copyright statements, (2) provide it for free, i.e. don’t charge any explicit or implicit fees to your customers, and (3) correctly and clearly cite the origin of the firmwares and the project web page in any product documentation or web page. The GUI software is based on libraries, which I am using since nearly 10 years and which I have modified over time in several places I can’t remember anymore. Furthermore, it is written in Perl using Win32::Gui, which is not maintained anymore. It would take me an enormous effort to build a working distribution. I hence don’t publish the complete code but just the “master” perl source file, which however contains all relevant code.

V. Downloads

The files are also available at the GitHub repository

STorM32 BGC Eagle and Gerber files
storm32-bgc-v130-eagle-gerber-files-20140322 [zip] (2.5 MB)
storm32-bgc-v1202-eagle-gerber-files-20140311 [zip] (2.5 MB)
storm32-bgc-v110-eagle-gerber-files-20131227 [zip] (1.8 MB)
storm32-bgc-v017-eagle-gerber-files-20131120 [zip] (1.5 MB)

storm32-bgc-mpu-module-v009-eagle-gerber-files-20140506 [zip] (1.3 MB)

o323BGC firmware and o323BGCTool files
o323bgc-release-v033-v20140619 [.zip] (4.9MB)
o323bgc-release-v031-v20140528 [.zip] (4.7MB)
o323bgc-release-v029-v20140518 [.zip] (4.5MB)
o323bgc-release-v028-v20140511 [.zip] (4.3MB)
o323bgc-release-v025-v20140320 [.zip] (4.2MB)
o323bgc-release-v024-v20140316 [.zip] (16.0MB)
o323bgc-v20140122 [.zip] (3.1MB)
o323bgc-v20140117 [.zip] (2.9MB)

108 Kommentare

  1. Christian sagt:

    Sorry, hab den vorigen Post gerade selber beantworten können, mittels Wiki…
    Bei den Alexmos ist es aber egal, ob man GND connected, normal einfach nur ein Kabel von F2 an den RC_Pitch. Geht das beim Storm32 auch?

    • OlliW sagt:

      Hey Christian
      ja, das Wiki ist nicht ganz unnützlich :)
      Wegen dem GND, grundsätzlich MUSS es einen durchgängigen guten Referenzsignal für ALLE Signale geben, ob NAZA oder STorM oder was auch immer, wie man das durch welche Verbindungen erreicht kann dagegen sehr variieren… d.h. hängt sehr von deiner ganzen Verkabelung ab, die kenne ich nicht und eine allgemein richtige Antwort gibt es nicht
      (es gibt allerdings die Antwort dass es bei Copetrfliegern wohl üblich geworden ist kein GND anzuschliessen und einfach zu hoffen das es geht was es meist auch scheint, siehe eien Diskussion bei DiyDrones).
      Ich empfehle einen der GND Pins irgendwo an eine verlässliche Masse in deiner Elektrik anzuschliessen.

    • Christian sagt:

      Danke Olli für die schnelle Antwort!

      Ich denke, dass die GND einfach bislang vom Alexmos – Board Stromanschluss (welcher vom Akku der Phantom 2 mitversorgt wird) geschlossen wurde, oder habe ich da einen Denkfehler?

      Warte schon gespannt auf die Bastelei wenn das V1.1. von Whitespy eintrifft, es wird an ein FPVMonkey 3-Achser-Gimbal gebaut…

    • OlliW sagt:

      ja, so ist’s, allerdings fliesst über die Batteriemasse Strom und führt damit zu ungenauen Pegeln… beim Pixhawk führt das wohl zu ernsthaften Problemen, und nachdem das auch STM32 bzw. 3.3V basiert ist könnte es ähnliche Probleme hier nun auch geben… in jedem Fall ist das ne sehr “unsaubere” Methode, wenn es Probleme gibt sollte man zumindest nicht verwundert sein…

  2. Christian sagt:

    Hallo OlliW, finde es echt super, dass Du eine echte Alternative zu Alexmos und co anbietest!
    Eine Frage: Wird es möglich sein, den Pitch Motor mittels Naza-M F2 (DJI) anzusteuern?

  3. Michael sagt:

    Hallo Olli,

    wie kann ich sehen ob die onboard Imu nach dem lötprozess funtioniert?
    Wofür sind die Firmwaretestfiles?


    • OlliW sagt:

      Hey Michael
      es gibt noch keine offizielle Unterstützung der on-board IMU. Du kannst die inoffizielle Version v0.26b02 zum Testen der 2ten IMU benutzen.
      die Testfiles geben auf jedem benutzen Pin der MCU ein Testsignal aus; ich benutze die um zu Testen ob die MCU vollständig funktioniert.
      Cheers, Olli
      PS: Für tiefere Diskussionen gehst du besser ins Forum :)

  4. Armin sagt:


    echt Klasse das Projekt. Jetzt habe ich mal das Board probiert mit der aktuellen Firmware 0.28.
    Dabei vergleiche ich jetzt mal mit dem Brugi vom Martinez.
    Änderungen der Parameter müssen immer mit “Write” bestätigt werden. Das ist bei anderen Boards/Software immer on the fly >> geht besser einzustellen, als immer Write zu drücken. Kann man das nicht automatisieren? Sobald man den Wert mit der geklickten Maus verlässt >> übertragen! Sowie wären Pfeile an den Wertefeldern zum hoch und runterfahren besser als mit der Maus da den richtigen Wert zu treffen/schieben.

    Die Bluetooth LED >> gibts ja jetzt Jumper für.
    Was ist mit LED 1? Die Blinkt ja von Anbeginn und ändert sich nie?
    LED0 blinkt erst schnell, dann wenn die Cal. steht leuchtet die dauernd >> macht Sinn!

    Also wenn ich die Störungen mal provoziere, Kamera auf den Kopf stelle (bei mir alles über Drehkontakte >> freies 360 Grad) dann erkennt er diese Störung nicht und bleibt dort stehen >> im Prinzip bleibt er überall stehen was ausserhalb der eingestellten Winkel ist. Bei den anderen Boards/Fimwares auch beim Brugi ist es egal welche Falschlage wo, die wird sofort verlassen und die richtige Lage eingenommen. Das sollte doch sinnvoll sein?

    Am Anfang (Power Up) fahren die Achse leicht in eine Richtung und LED1+0 blinken heftig.Nach 11 sekunden levelt er die Achsen ein. Dann dauert es manchmal bis zu weiteren 15sekunden oder gar nicht bis er kalibriert hat.

    Beim Brugi habe ich die Kalibrierung komplett in 8 Sekunden, dabei werden die Motoren zuerst abgeschaltet, dann Gyros kalibriert (ACC wird einmalig manuell kalibiert und gespeichert). Dann fährt sie zügig und ordentlich in die Sollage fertig.

    Hier kommts mir so vor, als ob jedesmal der ACC neu kalibiert wird, und wenn das nicht gleich passt, dann wartet sich die Routine dazu zu Tode!?
    Könnte man das ändern?



    • OlliW sagt:

      Hey Armin,
      am Besten meldest du dich bei rcgroups an (im Notfall bei fpvc), für detaillierte Diskussionen ist die Kommentarfunktion heir nicht gut geeignet.
      Write: sehe ich nicht so :)
      Leds: Funktion steht im Wiki
      provozierte Störungen: hab ich jetzt nicht kapiert, müssten wir ausführlicher diskutieren
      Start-up: du weist schon das Brugi ein 2-Achser ist, das hier aber ein 3-Achser? Du weisst auch dass das STorM eine auto Dir Funktion hat?
      Grüßle, Olli

  5. OlliW sagt:

    Hey Barry,
    ich zitiere mal von oben “Die aktuelle Firmware schöpft die Möglichkeiten noch nicht voll aus” !!!
    Die v0.25 unterstüzt keine 2te IMU, d.h. weder on-board noch über I2C#2.

  6. Pedro sagt:

    First of all congratulations for this amazing project. It seems like the best gimbal controller I have seen till now.
    Secondly I was wondering where to find the Android app to download, and the open source code, if there is available. It was also you who developed the app, or it was Erick?

    • OlliW sagt:

      Hey Pedro
      it’s maybe not better than AlexMos but maybe the best non-commercial one :)
      the app is by Erick, as much as I know he hasn’t yet done an “official” release

  7. Erik sagt:

    Hallo Olli,

    echt ein starkes Projekt, welches du da hast. Heute hat mir ein Freund davon erzählt und ich bin dabei. Er stellt mir die fertige Platine zur Verfügung und ich kümmere mich dann um den Rest. Leider habe ich keine wirklich große Ahnung von Elektronik, ich kann Konstruieren und mit den verschiedensten Maschinen Sachen herstellen, daher habe ich noch ein paar Fragen.
    Und zwar, welche Motoren verwendest du bzw. welche kann ich noch so verwenden? Die Kamera die ich nutzen möchte ich die gleiche, wie die in deinem ersten Video – jedoch ohne aufgesetztes Objektiv.
    Habe ich es richtig verstanden, dass die Steuerung der Motoren mit über die Platine funktioniert? Denn du sprichst von einer zweiten Einheit.

    Gruß Erik

    • OlliW sagt:

      Hallo Erik
      Alle Infos zu den Motoren findest du im Thread Es gibt auch bei FPVC ein Thread von mir mit ausführlicheren Hintergründen. Generel ist das mit den Motroen bei der Keycams ein recht schwieriges Thema.
      Ja, die Motoren werden vom STorM32 Board gesteuert (und dort angeschlossen). Es wird noch zusätzlich ein MPU Modul, welches an die Kamera “geklebt” wird, benötigt, welches also über ein Kabel an das STorM32 Board angesteckt werden muss. Mit der “zweiten Einheit” meinst du vermutlich die “zweite IMU”. Diese ist nicht absolut nötig, verbessert aber einige Eigenschaften ehrheblich.
      Übringens: Die Kommentarfunktion hier ist nicht wirklich nützlich. Idealerweise würdest du dich für weitere Diskussion bei rcgroups anmelden, dort kann man auch Deutsch reden wenn man will (oder notfalls bei FPV-Community anmelden)
      Cheers, Olli

    • Erik sagt:

      Hallo Olli,

      ich habe ja gar nicht mit einer so schnellen Antwort von dir gerechnet – danke erst einmal.
      Dieses Wochenende werde ich mich noch etwas in die Thematik einlesen und mich mit meinem Freund besprechen, da ich derzeit noch nicht genau weiß ob er zu der STorM32 Platine auch die MPU Platine hat.
      Nächste Woche werde ich mich dann einmal in dem rcgroups Forum anmelden und dort in deinem Thread schreiben, denn ich weiß zum Beispiel nicht, warum die Motoren ein schwieriges Thema sind.

      Bis nächste Woche, Gruß Erik

    • OlliW sagt:

      das Problem ist dass es für Gimbals für Kameras kleiner als GoPro keine vernünftigen Motoren fertig zu kaufen gibt
      rcg ist gut
      viel Spass, Olli

  8. Klaus sagt:

    Hi Olli,
    ich muss vorausschicken, dass ich mich nahe dem Rentenalter bewege und deshalb
    nicht immer alles verstehe, was ich mir so in den letzten Wochen angelesen habe.
    Man möge mir dies im Einzelfall nachsehen.

    Zunächst bin ich Filmer, dann Motorradfahrer und dann Helipilot (Verbrenner).
    So habe ich auch gewisse Vorstellungen, die ich bei deinem phantastischen Board
    das erste Mal umgesetzt sehe (sofern ich alles begriffen habe).

    Ich habe mir ein System vorgestellt, das ich für einen Camcorder, der mit Mic und Zusatzoptik ca. 800-900gr wiegt, bauen möchte und das

    - stehend montiert auf dem Motorrad einsetzen kann.
    Einmal “Rollachse blockiert”, damit es die Schräglage mitmacht, einmal stabilisiert, damit es immer waagrecht bleibt und die Schräglage der Maschine ausgleicht.
    Zusätzlich noch in diesem Modus mit Follow-Modus in der YAW-Achse für Aufnahmen nach rückwärts.
    oder wahlweise zusätzlich noch per Kabel abgesetztem Joystick um die Hochachse (YAW) nachführbar, sprich Follow-Modus manuell beschleunigen (z.B. Fahrzeug von hinten überholt, Kamera folgt). Die Modi ebenfalls abgesetzt per Knopfdruck anwählbar. Das System muss Quasi den Sozius ersetzen!

    - hängend montiert unter einem Handgriff. Dies für Kinder-/Tieraufnahmen in Kniehöhe.
    Neben der stabilen Aufnahme wieder per Joystick nachführbar, wie beim Motorrad/Auto.

    - hängend montiert unter dem Heli. Anforderungen wie vor, aber die manuellen Eingriffe über freie Servokanäle.

    - was bis dato noch keine Beachtung fand, der Einsatz als Motorstativ. Stehende Montage auf einem Stativ und langsame Schwenks in der YAW- und/oder auch Nick-Achse. Vielleicht lässt sich hier eine Timer-/Geschwindgkeitssteuerung über entsprechende Parameter implementieren oder/und das ganze über entsprechende (analoge) Joysticks steuern (ggf. automatisieren).

    Sofern ich also Recht habe und dein Board kann das alles und künftig noch mehr, muss ich mich in den Foren nach Mitstreitern umsehen, die mir beim Elektronikaufbau helfen.

    Übrigens, kennst du folgendes:
    Da sind auffallende Ähnlichkeiten zu deinem System (2 IMU); kommt da was ähnliches oder ist das deine kommerzielle Variante?

    Egal wie, mach weiter so !

    Gruß Klaus

  9. Frank sagt:

    Hallo Olli,
    starkes Board und funktionelle GUI. Ich bin gerade am Suchen einer Alternative zum Alexmos und muss sagen, dass ich das hierbprobieren werde. Kannst Du eine Info absetzen, wann und wo Dein Board käuflich zur Verfügung steht?
    Gruss Frank

    • OlliW sagt:

      Hey Frank,
      ja, kann ich (btw zum wiederholten male ;) ): Ich selber werde es nie und nirgends käuflich zur Verfügung stellen. Das müssen Andere machen die auf sowas Bock haben, ich mache das hier zum Spass als Freizeit :)
      Cheers, Olli
      Tip: frage doch mal im rcg o. FPVC Thread nach.

Add Comment Register

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *