Inhalt
- Geräusche machen eine Szene glaubwürdig
- Warum wir selbst entwickeln wollten
- Von Anfang an offen und nachbaubar
- Drei Teile gehören zum Soundmodul
- Arduino Nano, JQ6500 und Lautsprecher
- Was das Soundmodul können sollte
- Der erste Aufbau auf dem Steckbrett
- Ein abgespielter Ton war noch nicht genug
Geräusche machen eine Szene glaubwürdig
Ein Soundmodul für die Modellbahn beginnt für uns nicht bei der Elektronik, sondern bei der Wirkung einer Szene. Ein Bahnhof wirkt anders, wenn eine Ansage zu hören ist, auf dem Bahnsteig Stimmen und Schritte angedeutet werden oder eine Glocke einen betrieblichen Ablauf begleitet. Im Betriebswerk passen Kompressor, Werkzeug und das gleichmäßige Geräusch einer Werkstatt. Bei einer Fabrik, einem Sägewerk oder einer Baustelle können Maschinen und Fahrzeuge den sichtbaren Betrieb ergänzen. Auch außerhalb der Bahn entstehen passende Motive: Straßenverkehr, Hafen, Landwirtschaft, Tiere, Jahrmarkt, Stadt- oder Landschaftsgeräusche. Solche Klänge sollen nicht wahllos laufen. Sie müssen zum Ort, zur Situation und zur gewünschten Aufmerksamkeit passen.
Gerade deshalb wollten wir keine feste Sammlung von Tönen vorgeben. Die Sounddateien gehören nicht zum Projekt, denn jede Anlage erzählt eine andere Geschichte. Ein kleiner Haltepunkt benötigt andere Ansagen als ein großer Bahnhof. Auf einer ländlichen Anlage können Tiere oder eine Kirchenglocke wichtiger sein, während auf einer Industrieanlage Maschinen, Rangiergeräusche und Hintergrundkulissen dominieren. Jeder Anwender wählt seine eigenen Dateien und muss dabei die jeweiligen Urheber- und Nutzungsrechte beachten. Das Soundmodul stellt die technische Grundlage bereit. Zehn nummerierte Wiedergabeplätze, mehrere Auslösewege und eine nachvollziehbare Steuerung.
Die zeitliche Steuerung ist dabei ebenso wichtig wie die Auswahl der Aufnahme. Ein dauerhaft laufender Klang kann eine kleine Szene schnell überdecken, während ein einzelnes, seltenes Geräusch kaum wahrgenommen wird. Für manche Motive ist eine manuelle Auslösung sinnvoll, etwa wenn ein Zug am Bahnsteig hält. Andere Geräusche sollen in festen oder zufälligen Abständen erscheinen. Schon bei der Projektidee war deshalb klar, dass das Modul nicht lediglich zehn Taster mit zehn Audiodateien verbinden sollte. Es brauchte ein Bedienkonzept, mit dem sich unterschiedliche Szenen ruhig und kontrolliert gestalten lassen.
Warum wir selbst entwickeln wollten
Es ging uns nicht darum, eine vorhandene Lösung nachzubauen. Wir wollten ein eigenes System entwickeln, das zu unseren Vorstellungen passt und dessen technische Zusammenhänge wir vollständig nachvollziehen können. Dazu gehörte die Freude am eigenen Aufbau, aber ebenso der Wunsch nach klaren Entscheidungen. Wir wollten wissen, wie ein Wiedergabebefehl zum Audiomodul gelangt, wie der Arduino den laufenden Sound erkennt, was mit einer zweiten Anforderung geschieht und wie der Betrieb ohne aktive PC-Verbindung weitergeht. Hardware, Firmware und Bedienoberfläche sollten nicht als schwarze Kästen nebeneinanderstehen. Wir wollten jede Schnittstelle selbst festlegen und später erklären können.
Eine eigene Entwicklung gibt außerdem die Möglichkeit, die Grenzen bewusst zu wählen. Als Steuerplattform bleibt der Arduino Nano mit ATmega328P gesetzt. Firmware und Konfiguration verwenden ausschließlich seinen internen Speicher. Ein externer EEPROM, FRAM, eine SD-Karte für Konfigurationsdaten oder ein größerer Mikrocontroller sind nicht Teil des Konzepts. Wenn Speichergrenzen erreicht würden, müssten Funktionen oder Maximalwerte reduziert werden. Diese Einschränkung ist kein versteckter Mangel, sondern eine klare Projektentscheidung. Sie hält den Aufbau übersichtlich und zwingt dazu, Datenstrukturen, Warteschlange und Kommunikation sparsam zu planen.
Von Anfang an offen und nachbaubar
Der Open-Source-Gedanke gehörte von Beginn an zum Projekt. Andere Modellbahner sollen nicht nur ein fertiges Programm ausführen, sondern den Aufbau nachvollziehen, die Firmware lesen, die Windows-Anwendung untersuchen und eigene Änderungen vornehmen können. Deshalb verwenden wir allgemein erhältliche Standardkomponenten. Der Versuchsaufbau funktioniert auf einem Steckbrett; später kann er auf Lochraster oder einer selbst entworfenen Platine umgesetzt werden. Eine besondere MOBA-Module-Platine ist nicht erforderlich. Ebenso wichtig war eine vollständige Dokumentation mit Verdrahtungsplan, Netzliste, Hinweisen zum JQ6500, Build-Anleitung und Testunterlagen.
Offen bedeutet in diesem Zusammenhang nicht, dass jede beliebige Erweiterung bereits Bestandteil der Version 1.0.0 ist. Veröffentlicht werden der tatsächlich entwickelte Stand und die dazugehörigen Quellen. Quellcode und Dokumentation stehen unter der MIT-Lizenz. Der Name MOBA-Module, das Logo und das Icon sind davon ausgenommen. Wer den Aufbau verändert, kann daraus ein eigenes Projekt entwickeln, darf eine veränderte Fassung aber nicht als offizielles MOBA-Module-Release ausgeben. Diese Trennung schützt die Nachbaubarkeit und zugleich die eindeutige Kennzeichnung der ursprünglichen Veröffentlichung.
Zur Nachbaubarkeit gehört für uns auch, Grenzen und Abhängigkeiten offen zu benennen. Der JQ6500 benötigt zum Bespielen einen eigenen Uploader, der als Drittsoftware nicht im Repository liegt. Die Arduino-Firmware verwendet eine externe JQ6500-Bibliothek. Für einen eigenen Windows-Build werden PureBasic, WebView2 und ein vorbereitender Python-Schritt benötigt. Solche Angaben gehören in eine technische Dokumentation, weil ein Projekt erst dann wirklich nachvollziehbar ist, wenn nicht nur der fertige Aufbau, sondern auch die notwendigen Werkzeuge und Zwischenschritte beschrieben sind.
Drei Teile gehören zum Soundmodul
Das MOBA-Module-Soundmodul besteht aus drei wesentlichen Teilen. Der erste Teil ist die Hardware mit Arduino Nano, JQ6500-16P, Lautsprecher und bis zu zehn Eingängen. Der zweite Teil ist die Firmware auf dem Nano. Sie steuert das JQ6500 über UART, wertet den Wiedergabestatus aus, entprellt die Eingänge, verwaltet die FIFO-Warteschlange, speichert die Konfiguration und führt die Automatik aus. Der dritte Teil ist die mit PureBasic entwickelte Windows-Anwendung mit eingebetteter Weboberfläche. Sie sucht das Modul, baut eine PC-Sitzung auf, zeigt Zustände an und ermöglicht die aktive Bedienung.
Die Windows-Anwendung war keine nachträgliche Zugabe und ist kein bloßes Einstellprogramm. Sie gehört zum Bedienkonzept. Im Softwarebetrieb lassen sich Sounds manuell starten, Lautstärke und Betriebsart wählen, Automatikfunktionen ein- oder ausschalten und die Einstellungen der zehn Sounds bearbeiten. Status, Warteschlange, BUSY-Rohwert, aktive Eingänge und laufende Ereignisse werden sichtbar. Daneben existiert der autonome Eingangsmodus. Ohne aktive PC-Sitzung verarbeitet der Nano die Hardwareeingänge selbstständig. Beide Betriebswege sind aufeinander abgestimmt, aber nicht gleichzeitig aktiv. Im Softwaremodus werden die Eingänge ignoriert; im Eingangsmodus sind manuelle PLAY-Befehle und Softwareautomatik deaktiviert.
Die Trennung der Betriebsarten war eine frühe und wichtige Entscheidung. Eine aktive PC-Sitzung versetzt das System nicht einfach in einen zusätzlichen Fernbedienmodus, während die Eingänge unverändert weiterarbeiten. Stattdessen entscheidet die Firmware eindeutig zwischen SOFTWARE und INPUTS. So bleibt klar, woher eine Anforderung stammt und welche Automatik gerade zuständig ist. Beim Start einer PC-Sitzung werden ausstehende Eingangswünsche verworfen und die Softwareautomatik zunächst deaktiviert. Beim Rückfall in den Eingangsmodus werden wiederum Softwarezeitpläne und Warteschlange zurückgesetzt. Diese Regeln verhindern gemischte Zustände.
Arduino Nano, JQ6500 und Lautsprecher
Für den ersten Versuchsaufbau haben wir einen Arduino Nano mit ATmega328P und ein JQ6500-16P verwendet. Der Nano übernimmt die Steuerung, besitzt aber keinen eigenen Audiospeicher und dekodiert keine MP3-Dateien. Das JQ6500 speichert die Audiodateien in seinem internen Flash, dekodiert sie und treibt den Lautsprecher direkt an. Hinzu kommen zwei getrennte Widerstände mit jeweils 1 kΩ, Verbindungskabel, eine stabile 5-Volt-Versorgung und Taster, Schalter oder geeignete Open-Collector-Kontakte. Empfohlen sind außerdem ein 470-µF- und ein 100-nF-Kondensator nahe am JQ6500.
Diese Aufgabenteilung war für das Verständnis hilfreich. Der Nano entscheidet, wann welcher Sound angefordert wird und in welchem Zustand sich die Steuerung befindet. Das JQ6500 kümmert sich um Speicherung und Wiedergabe. Der Windows-PC spricht mit dem Nano, nicht direkt mit dem Audiospeicher. Audiodateien werden separat über den USB-Anschluss des JQ6500 übertragen. Firmware und Windows-Anwendung laden keine MP3-Dateien. Auch Dateinamen kann die Projektsoftware nicht aus dem internen Flash auslesen; sie arbeitet ausschließlich mit den Soundindizes eins bis zehn.
Was das Soundmodul können sollte
Die erste Funktionsliste war bewusst praktisch. Zehn externe Eingänge sollten zehn Sounds auslösen. Im autonomen Eingangsmodus ist die Zuordnung fest: Eingang eins spielt Sound eins, Eingang zwei Sound zwei und so weiter. Eine frei programmierbare Eingangsmatrix gehört nicht zur Version 1.0.0. Im Softwarebetrieb sollte die Windows-Anwendung dieselben zehn Soundnummern manuell anfordern können. Für jeden Sound sollten Dauerwiedergabe, Zufallswiedergabe und Intervallwiedergabe einzeln einstellbar sein. Der Zufallsbereich gilt global, die Intervallzeit wird dagegen für jeden Sound separat gespeichert.
Mehrere Anforderungen sollten nicht den laufenden Sound verdrängen. Deshalb war eine FIFO-Warteschlange vorgesehen. Was zuerst angefordert wird, wird zuerst wiedergegeben. Ein Sound darf sich nur einmal gleichzeitig in der Wiedergabe oder in der Warteschlange befinden. Das verhindert einen Rückstau aus identischen Einträgen. Die Konfiguration sollte im internen EEPROM des Nano erhalten bleiben und mit Kennung, Versionsnummer und CRC geprüft werden. Feste Uhrzeiten, Kalender, Wochenpläne oder eine Echtzeituhr waren nicht vorgesehen. Die Automatik arbeitet mit Dauerwiedergabe, zufälligen Zeitabständen und festen Intervallen in Sekunden.
Zur geplanten Bedienung gehörte außerdem eine aussagekräftige Statusanzeige. Die Anwendung sollte nicht nur melden, ob eine Verbindung besteht, sondern auch den Playerzustand, den aktuellen Sound, die Auslöseart, die Warteschlangenlänge, den BUSY-Rohwert und die aktiven Eingänge darstellen. Ein Reset und eine Medienprüfung sollten ebenfalls erreichbar sein. Die Medienprüfung kann die Anzahl der Dateien im JQ6500 feststellen, aber keine Namen anzeigen. Damit bleibt die Bedienoberfläche eng an den tatsächlichen Möglichkeiten der Hardware und des seriellen Protokolls.
Der erste Aufbau auf dem Steckbrett
Das Steckbrett war für die Entwicklung die richtige Grundlage. Leitungen konnten geändert, Messpunkte erreicht und einzelne Funktionen getrennt geprüft werden. Zuerst ging es um eine stabile Versorgung und die serielle Verbindung zwischen Nano und JQ6500. Danach musste ein Wiedergabebefehl den richtigen Soundindex starten. Die ersten Dateien wurden direkt auf das JQ6500 geschrieben. Ihre Übertragungsreihenfolge bestimmt die Nummern: Die erste Datei ist Sound eins, die zweite Sound zwei. Diese Zuordnung muss außerhalb des Moduls dokumentiert werden, weil die Software keine Dateinamen kennt.
Als der erste Ton aus dem Lautsprecher kam, war damit nur die Grundidee bestätigt. Der Nano konnte einen Befehl senden, das JQ6500 reagierte und der Lautsprecher gab die Datei wieder. Für einen realen Einsatz fehlten jedoch noch wichtige Zusammenhänge. Der Arduino musste sicher erkennen, wann die Wiedergabe beginnt und endet. Die Eingänge mussten entprellt werden. Eine zweite Anforderung durfte nicht verloren gehen. Beim Wechsel zwischen PC-Sitzung und Eingangsmodus mussten Warteschlange, Automatik und laufende Wiedergabe in einen definierten Zustand gebracht werden.
Der Steckbrettaufbau half außerdem, die spätere Dokumentation vorzubereiten. Jede Verbindung musste einen eindeutigen Namen und eine nachvollziehbare Aufgabe erhalten. Schon in dieser Phase trennten wir Versorgung, Datenleitung, BUSY-Signal, Lautsprecherweg und Eingänge gedanklich voneinander. Diese Ordnung war wichtig, weil ein funktionierender Prototyp allein noch keine brauchbare Nachbauanleitung ergibt.
Ein abgespielter Ton war noch nicht genug
Die entscheidende Arbeit begann nach dem ersten erfolgreichen Abspielen. Das BUSY-Signal des JQ6500 musste so ausgewertet werden, dass kleine Messschwankungen keinen falschen Zustandswechsel erzeugen. Für den Start war ein Timeout nötig, falls ein angeforderter Sound nicht vorhanden ist oder BUSY nicht rechtzeitig erkannt wird. Die Firmware brauchte eindeutige Zustände für bereit, startend, wiedergebend und zurücksetzend. Ebenso musste festgelegt werden, welche Befehle während einer laufenden Wiedergabe erlaubt bleiben. Ohne solche Regeln könnte die Bedienoberfläche widersprüchliche Anforderungen senden.
Auch der Rückfall ohne PC erforderte eine klare Lösung. Wird die Anwendung geschlossen, die Verbindung getrennt oder bleibt die Kommunikation länger als ungefähr vier Sekunden aus, beendet der Nano die PC-Sitzung. Er schaltet die Softwareautomatik ab, leert die Warteschlange, setzt die Zeitpläne zurück und wechselt in den Eingangsmodus. Läuft noch ein Sound oder ist der Player nicht sicher bereit, wird das JQ6500 zurückgesetzt, weil kein zuverlässig bestätigter unmittelbarer STOP-Befehl zur Verfügung steht. Damit war die Richtung für den vollständigen Aufbau festgelegt.
Die Aufgaben waren damit klar verteilt, aber noch nicht vollständig umgesetzt. Aus der einfachen Tonwiedergabe musste eine Steuerung werden, die auf reale Zustände reagiert. Sie durfte weder nach festen Wartezeiten raten noch bei einer fehlenden Datei blockieren. Ebenso musste die Bedienoberfläche erkennen, wann Änderungen erlaubt sind. Diese Anforderungen führten direkt zu den späteren Playerzuständen, den Sperrregeln und der Statusausgabe.
Der erste Aufbau konnte bereits Sounds wiedergeben. Für einen verlässlichen Betrieb mussten anschließend Versorgung, serielle Verbindung, BUSY-Auswertung, Lautsprecher und die zehn Eingänge sauber zusammengebracht werden. Genau darum geht es im zweiten Teil.
English version
Sounds make a scene believable
For us, a sound module for the model railway starts with the scene rather than the electronics. A station feels different when an announcement can be heard, when platform activity is suggested by voices and footsteps, or when a bell accompanies an operating sequence. A depot may use compressors, tools and workshop noise. A factory, sawmill or construction site can be supported by machines and vehicles. Road traffic, a harbour, farming, animals, a fairground, urban ambience or quiet landscape sounds are equally possible. These recordings should not run without purpose. They need to suit the location, the operating situation and the amount of attention the scene is meant to receive.
That is why the project does not prescribe a fixed sound collection. Audio files are not part of the repository because every layout tells a different story. A small rural stop needs different announcements from a large station. Animal sounds or a church bell may suit a countryside layout, while machinery, shunting and background ambience may be more useful in an industrial area. Each user selects their own files and remains responsible for the relevant copyright and usage rights. The module supplies the technical framework: ten numbered playback positions, several ways to trigger them and a control system that can be understood and modified.
Timing matters as much as the choice of recording. A continuously running sound can dominate a small scene, while a very rare event may go unnoticed. Some situations are best triggered manually, for example when a train stops at a platform. Other sounds suit fixed or random intervals. From the beginning, the project therefore required more than ten buttons connected to ten files. It needed an operating concept that could support different scenes in a controlled and understandable way.
Why we wanted to develop it ourselves
We were not trying to copy an existing product. We wanted to create our own system, shaped by our requirements, and to understand every technical relationship. The enjoyment of building it ourselves was part of the motivation, but clear engineering decisions mattered just as much. We wanted to know how a playback command reaches the audio module, how the Arduino detects an active sound, what happens to a second request and how operation continues after the PC session ends. Hardware, firmware and user interface should not behave like unrelated black boxes. We wanted to define and document every interface ourselves.
Developing the system ourselves also allowed us to set firm boundaries. The Arduino Nano with ATmega328P remains the control platform. Firmware and configuration use only its internal memory. An external EEPROM, FRAM, an SD card for configuration data or a larger microcontroller are not part of the design. If memory limits were reached, features or maximum values would have to be reduced. This is a deliberate constraint. It keeps the hardware simple and requires the data structures, queue and communication protocol to be designed economically.
Open and reproducible from the beginning
Open-source publication was planned from the beginning. Other model railway enthusiasts should be able to do more than run a finished executable. They should be able to inspect the wiring, read the firmware, study the Windows application and make their own changes. We therefore chose generally available standard components. The prototype works on a breadboard and can later be transferred to stripboard or a custom PCB. No special MOBA-Module board is required. Complete documentation is equally important, including wiring diagrams, a netlist, JQ6500 instructions, build notes and test records.
Open source does not mean that every imaginable extension is already included in version 1.0.0. The published material describes the system that was actually developed and tested. Source code and documentation use the MIT License. The MOBA-Module name, logo and icon are excluded. Builders may modify the design and create their own versions, but a changed version must not be presented as an official MOBA-Module release. This distinction supports practical reuse while keeping the origin of an official build clear.
Three parts form the sound module
The MOBA-Module sound module consists of three essential parts. The first is the hardware: Arduino Nano, JQ6500-16P, loudspeaker and up to ten hardware inputs. The second is the firmware on the Nano. It controls the JQ6500 over UART, evaluates playback status, debounces inputs, manages the FIFO queue, stores configuration and runs the scheduler. The third is the PureBasic Windows application with its embedded web interface. It searches for the module, opens a PC session, displays the current state and provides active control.
The Windows application was not added as an afterthought and it is not merely a configuration utility. It is part of the operating concept. In software mode it can start sounds manually, set volume and control mode, enable or disable automation and edit the settings for all ten sounds. It displays the state, queue, raw BUSY reading, active inputs and recent events. The autonomous input mode is the second operating path. Without an active PC session, the Nano processes the hardware inputs. The paths are coordinated but not active at the same time: inputs are ignored in software mode, while manual PLAY commands and software automation are disabled in input mode.
The separation of operating modes was an early design decision. An active PC session is not an extra remote-control layer running alongside the hardware inputs. The firmware selects either SOFTWARE or INPUTS. This keeps the source of each request clear. Starting a PC session discards pending input requests and initially disables automation. Returning to input mode clears the software queue and schedules. These rules prevent mixed control states.
Arduino Nano, JQ6500 and loudspeaker
The first prototype used an Arduino Nano with an ATmega328P and a JQ6500-16P. The Nano controls the system but does not store or decode MP3 audio. The JQ6500 keeps audio files in its internal flash memory, decodes them and drives the loudspeaker directly. Two separate 1 kΩ resistors, connecting wires, a stable 5 V supply and push-buttons, switches or suitable open-collector contacts complete the core hardware. A 470 µF capacitor and a 100 nF capacitor close to the JQ6500 are also recommended.
This division of responsibilities made the design easier to understand. The Nano decides when a sound is requested and manages the control state. The JQ6500 handles storage and playback. The Windows PC communicates with the Nano, not with the audio storage during normal operation. Audio files are transferred separately through the JQ6500 USB connection. Neither the firmware nor the Windows application uploads MP3 files. The project software cannot read file names from the internal flash either; it works only with sound indices one to ten.
What the sound module was meant to do
The initial feature list was practical. Ten hardware inputs should trigger ten sounds. In autonomous input mode the mapping is fixed: input one plays sound one, input two plays sound two, and so on. Version 1.0.0 does not provide a freely programmable input matrix. In software mode, the Windows application should request the same ten sound numbers manually. Continuous, random and interval playback should be configurable for each sound. The random range is global, while each sound stores its own interval time.
A new request should not replace a sound that is already playing. The design therefore required a FIFO queue: the first request received is the first one played. A sound may occur only once at the same time, either as the current sound or in the queue. This prevents repeated triggers from building an uncontrolled backlog. Configuration should remain in the Nano internal EEPROM and be checked by a signature, version number and CRC. Clock times, calendars, weekly schedules and a real-time clock were outside the design. Automation uses continuous playback, random delays and fixed intervals measured internally in seconds.
The first breadboard setup
A breadboard was the right development platform. Connections could be changed, measurement points remained accessible and functions could be tested separately. The first tasks were a stable supply and serial communication between Nano and JQ6500. A playback command then had to start the correct sound index. The first files were written directly to the JQ6500. Their transfer order defines their numbers: the first file is sound one and the second is sound two. The user must document this mapping outside the module because the software does not know file names.
When the first sound came from the loudspeaker, it confirmed only the basic idea. The Nano could send a command, the JQ6500 responded and the loudspeaker reproduced the file. Reliable layout operation required much more. The Arduino had to detect exactly when playback started and ended. Inputs needed debouncing. A second request must not disappear. A change between PC session and input mode had to place the queue, automation scheduler and current playback into a defined state.
One played sound was not enough
The decisive development work started after the first successful playback. The JQ6500 BUSY signal had to be evaluated without small measurement changes causing false transitions. A start timeout was required if a requested file was missing or BUSY did not appear in time. The firmware needed explicit states for ready, starting, playing and resetting. It also had to define which commands remain valid while playback is active. Without these rules, the user interface could send commands that conflict with the actual player state.
Fallback without the PC needed an equally clear solution. When the application closes, the connection is removed or communication is absent for about four seconds, the Nano ends the PC session. It disables software automation, clears the queue, resets its schedules and changes to input mode. If a sound is still running or the player is not safely ready, the firmware resets the JQ6500 because no reliably confirmed immediate STOP command is available. This defined the direction for the complete hardware and firmware implementation.
The responsibilities were defined, but the implementation was not yet complete. Simple playback had to become a controller that reacted to real states. It could not guess completion from fixed delays or remain blocked by a missing file. The interface also needed to know when changes were allowed. These requirements led directly to explicit player states, command locks and detailed status reporting.
The first prototype could already play sounds. Reliable operation still required the power supply, serial connection, BUSY evaluation, loudspeaker and ten inputs to work together correctly. Part 2 covers that complete hardware setup.