Bergwerk-Modell 1:14 (Obsolete Doku)

Bedienungsanleitung (PDF-Scan, 10 Seiten A4)
Konformitätserklärung (PDF-Scan, 3 Seiten A4, identisch mit jener zum Radlader)
Seriennummern: Fahrzeug: -, Fernbedienung: 1G047198, Empfänger: 1G047223

Kamera niedrig (alt)

Das Not-Aus schaltet den Output-Enable-Eingang der PWM-Platine und nicht mehr die dicke Leitung vom Hauptakku. Der Akkuanschluss wurde auf die originale, unangezapfte Leitung mit XT60-Stecker rückgebaut. Der „Magic Controller“ ist verzichtbar; die PWM-Platine hat noch genügend Anschlüsse für die Beleuchtung. Dinosauriergeräusche sind kein Muss, der Ton kann vom Raspberry mit einem sparsamen Verstärker kommen.
TODO: Bei der nächsten Revision steht das Zurücksetzen der Kamera und der gesamten Baugruppe nach hinten an, um die Kameralinse nicht jedesmal durch die Frontscheibe fädeln zu müssen. Dazu muss der Tiefsetzer auf die andere Seite, unter die Kamera.

Problem: Autonomie oder wenigstens Positionskorrektur anhand optischer Marker in weiter Ferne. Lenk- und Verwindungspoti zerstört durch ungeschicktes Anheben des Lasters. (Verwindungsbegrenzer aus Alu gefertigt.) Bei reiner Zeitsteuerung (Fahrantrieb, Lenkung) deutliche Abhängigkeit vom Ladezustand des Fahrakkus. Als Spielzeug konzipiert ist eine reine PWM-Servosteuerung drin und kein Istwertaufnehmer bspw. für Radumdrehungen, wie das bei Rasenmährobotern gemacht wird.

Lösung: (Gelöst)

Die ursprünglich vorgesehene Weitwinkel-Kamera („Fischauge“, 230326 gemessener horizontaler Öffnungswinkel 94°) für den Raspberry wurde schließlich durch eine „normale“ Kamera ersetzt und dafür ein Adapter + Halter konstruiert und 3D-gedruckt. Wichtig ist nämlich, dass die kleine Kamera nicht wackelt! Diese ist nämlich nur lose befestigt.

Bedienungsanleitung (PDF-Scan, 9 Seiten A4)
Konformitätserklärung (PDF-Scan, 3 Seiten A4, identisch mit jener zum Muldenkipper)
Seriennummern: Fahrzeug: -, Fernbedienung: ?, Empfänger: 1G047204

PWM-Platine (unten) und A/D-Wandler-Platine (draufgeklebt)
Defekte Lautsprecher: Einer klapprig, der andere tot

Licht fehlt?⚓

Kein Licht leuchtet, der Magic Controller bekommt seine 6 V, keine Spannung kommt da 'raus. Verdacht: Im Magic Controller ist eine durchgebrannte SMD-Sicherung. Dieser ließ sich vergleichsweise leicht ausbauen und aufschrauben. Keine Sicherung drin, die kaputt gehen könnte, sieht alles OK aus. Die 9 vermeintlichen Lampenanschlüsse sind nur 8 Ausgänge, der vorletzte Anschluss macht 'was besonderes, und der letzte geht nicht über den ULN2003 sondern über einen gesonderten MOSFET.

Bestückungsseite
Unterseite
Schaltplan Seite 1: Mikrocontroller
Schaltplan Seite 2: Audio-Endstufe
Board-Layout-Rekonstruktion Oberseite
Board-Layout-Rekonstruktion Unterseite

Suchen nach „CXSTUDIO“ und „RC16-2“ bleibt ergebnislos. Also Bauteile recherchieren und Schaltplan erstellen:

• TPA3130 = Klasse D Audioverstärker 2× 15 W (an 7,4 V Akkuspannung eher 2× 5 W an 4 Ω)
• STM8S105K6T6C = 8-Bit-Mikrocontroller mit 32 KByte Flash, leistungsmäßig vergleichbar mit ATmega328 auf Arduino Uno
• GD32F350CBT6 = 32-Bit-Mikrocontroller bis 108 MHz, 128 KByte Flash, 16 KByte RAM, DAC (Datenblatt). Nur als Soundgenerator: UART-Steuerung, DAC-Ausgabe.
• W25Q64FVIG = 8 MByte SPI-serieller NOR-Flash-Speicher. Laut Bezeichner und Datenblatt Nibble-Mode voreingestellt. Sample-Speicher für Sound und Sprache. Nicht der Nibble-Mode wurde genutzt sondern bitweises SPI: Datentransfer mit angezogener Handbremse. Reicht für Mono.
• 12- und 18-poliger Wannenstecker, 2-reihig, 2 mm Pitch, 2 mm Reihenabstand.

Warum das Licht aus bleibt ist rätselhaft. Vermutlich gibt es eine Einstellmöglichkeit über die originale Funkfernbedienung, und es wurde „aus Versehen“ eine PWM-Folge generiert, die das Licht dauerhaft ausgeschaltet hat: Das Herumwursteln mit Closed Source ist und bleibt ein Martyrium!

Ausgelagert auf gesonderte Seite

Siehe auch Mathematik

Für die Erfassung „ob die Kuh vor'm Tor“ steht wurden die sattsam bekannten Ultraschall-Entfernungsmesser HC-SR04 oder so ähnlich (nicht von mir!) ausgewählt und verbaut, und für deren Abfrage ein Arduino Uno (Schaltplan) verschwendet. (Eine vernünftige SPS könnte das auch, müsste dazu „nur“ TTL-Ein- und Ausgänge aufweisen. Aber TTL ist für Hutschieneneinklicker ein Fremdwort.) Über die 3 m langen Leitungen mit nur TTL-Pegel und einer parallel laufenden Motorsteuerleitung fängt sich das System alles mögliche ein. Mit Widerständen habe ich eine Art Terminierung realisiert, die sowohl Störungen unterdrückt als auch Arduino und die HC-SR04 schützen.

Im Arduino werkelt eine Gruselsoftware. Diese habe ich schon mal umgeschrieben und verkürzt. Dabei könnte der kaum ausgelastete Mikrocontroller ruhig noch etwas anderes machen! So zum Beispiel die gesamte SPS ersetzen und — wenn's denn unbedingt sein muss — OPC-UA „sprechen“. Hier wurde mal eben schnell ein 50 cm langes WS2812-Lichtband rangefrickelt, welches einfach Gleichlicht anzeigt. Dazu wurde kurzerhand die (übliche) Arduino-Bibliothek NeoPixel eingesetzt und das Projekt als .ino-Datei (aka Arduino-Projekt) belassen. Für ein ordentliches C++-Projekt müsste man NeoPixel selbst in die Hand nehmen. Dafür gibt es sogar deutsche Dokumentation.

Die „dicke Wurst“ zwischen Schaltschrank und Tor kann man IMHO niemandem verkaufen; das Kabel ist viel zu unhandlich und teuer. Richtiger wäre ein lokales Bussystem zwischen Steuerung und Tor. Dazu würde ich RS485 favorisieren, neben Profibus (ebenfalls RS485) und USB (mit RS485 verwandt). USB hätte den Vorteil, dass die Tore auch einzeln (am PC) angeschlossen und in Betrieb genommen werden können sowie dass es eine idioten­sichere Steck­verbinder-Norm gibt. Nachteil wäre dann, dass der Schaltschrank als USB-Host fungieren muss, ein entsprechend großer Mikrocontroller mit geeigneter Funktionalität wäre bspw. STM32F4xx. Daher plädiere ich für bimodale Tore, USB und RS485 auf den gleichen Leitungen.

Mit Beschriftung aber zu klein
Ohne Beschriftung, da fehlt 'was
Ganz ohne Beschriftung

Die Schaltschränke und Tore 🙈:

• Zusammengesetztes Kabel zwischen Siemens-Steuerung und den Toren zwecks Abschirmung zu den Sensorleitungen.
  Rückgebaut, durch Terminierung obsolet
• Auf der Arduino-Platine für Siemens waren die Ausgänge Sensor1 und Sensor5 vertauscht. Dadurch chaotische Zuordnungen.
  Korrigiert in Hard- und Software
• Die gemeinsame Triggerleitung wurde durch übersprechsichere getrennte Triggerleitungen ersetzt. Der Arduino-Bastler wusste offenbar nicht, dass die mit A0..A5 bezeichneten Anschlüsse auch digital sind.
• Die Arduino-Software wurde online entwickelt. Diese war mit diversen delay()s gespickt und gähnend langsam.
  Faktisch komplett neu geschrieben
• Die mechanische Fertigung des Schaltschrankes lässt zu wünschen übrig. Unpassende Clip-Befestigungen zur Wandstärke, Netzstecker unisoliert. Schräg sitzende Stehbolzen, irrsinnig wenig Platz hinter dem Netzstecker. Der (Koffertransport-)Griff ist zu tief, unbequemer Transport.
  Neukonstruktion s.u. am Netzstecker, weil sicherheitsrelevant. Leider musste einer der Netzstecker geklebt werden, weil Rastnasen abgefeilt(!!) waren. Lüftergitter durch Schrägfeilen des Schaltschrank-Ausbruchs fixiert. Der Rest bleibt so, merkt hoffentlich keiner.
• Die Schaltschränke sind unterschiedlich, und in beiden Fällen stimmt der Schaltplan nicht. Alle 4 Tore sind unterschiedlich.
  Korrigiert und gleichgezogen. Massive Arbeit
• Beschriftungen fehlen oder sind unleserlich. Wacklige Not-Aus-Beschriftung. Not-Aus lässt sich drehen, Verdrehsicherung unwirksam.
  TODO: Neuerstellung. Echtes, passendes Not-Aus-Schild (kaufen?)
• Der Schaltplan wurde nur gedruckt und verschmiert ausgehändigt und enthält viele Dopplungen.
  Mühselig verglichen und Dopplungen entfernt. Der Schaltplan existiert als vertrauenswürdiges Original nunmehr nur in Papierform mit PDF-Kopie:
  • Schaltplan 60 cm breiter Schaltschrank (2×) 11 Seiten A4 quer
  • Schaltplan 40 cm schmaler Schaltschrank (1×) 1 Seite A4 quer
  • Schaltplan Tor (4×) 3 Seiten A4 quer
• Kein Zugang zur Schaltplan-Quelle.
  TODO: Neuerstellung
• Die Schaltschrank-Innenbeleuchtung wurde in einem (ach-so-tollen papiernen) Konzept vorgesehen und dann komplett vergessen.
  Ist eingebaut. Über verdrehsichere dreipolige PSK-Stecker auf der Arduino-Platine angeschlossen und mit 5 Volt versorgt.
• Es fehlt immer noch die dritte Steuerung, zwei Netzeinbaustecker-Sicherung-Schalter-Kombinationen sowie die Zierecken für den dritten Schaltschrank.
  Erledigt. Fehlt noch die SPS sowie ein Teil des Harting-Steckers: Wird nachgeliefert.
• Unnötige Löcher (2× USB-, 1× Ethernet-Durchführung, 2× M12-Buchse)
  M22: Erledigt mit Blindstopfen als 3D-Druck, TODO bei M12-Buchse

Conrad
Stück	Bestellnummer	EVP/€	Beschreibung
2	501638-VQ	4,89	Snap-In-Netzbuchse
1	1990799-VQ	13,99	19300061541 Steckergehäuse
1	749623-VQ	22,99	09160243001 Stecker - lieferbar in 4 Wochen
4	749296-VQ	0,99	09150006101 Steckstifte Crimp
1	1990309-VQ	18,99	09300060301 Buchsengehäuse
1	749637-VQ	21,99	09160243101 Buchse
4	749478-VQ	1,29	09150006201 Buchsenstifte Crimp
1	749469-VQ	0,42	09330009915 Kodierstift

Item
8	0.0.627.60	a.A.	https://www.item24.com/de-de/verbinder-abdeckkappe-8-r40-90-grau-aehnlich-ral-7042-62760/

Die Firmware für ATtiny25 und V-USB. Der Schaltplan ist trivial und im Firmware-Quelltext angegeben. Inzwischen (November 2022) wurde die Schaltung wieder entfernt, der Quelltext ist historisch. Denn so kam die Grapefruit nie zum Einsatz, niemand sah sich imstande, die Steuersoftware mit dieser Not-Aus-Funktion zu ergänzen. Also nachträglich vielen Dank für die fruchtlose Zusammenarbeit.

Der mühsam erarbeitete Ansatz mit der Software-PLL musste verworfen werden. Damit entfällt die Echtzeit­uhr und die Batterie­stütze. Der ATmega stürzt unvermittelt ab oder macht sonstwas, wenn er in gestörter Umgebung mit RC-Oszil­lator läuft, egal ob mit oder ohne PLL. Der Jitter ist (vermutlich nicht nur für die serielle Schnitt­stelle) einfach zu groß. Was nicht dokumentiert ist, und womit nicht wirklich zu rechnen war! Es war einfach zum Verzweifeln! Immer wieder Abstürze mit irrsinnigen Fehl­funktionen. Schließlich wurde ein Baudraten­quarz eingesetzt, und alles läuft wunderbar. Bis auf die Echtzeituhr, die ist erst mal totgelegt. Und der Controller braucht etwas mehr Strom. Zusätzlich wurde der MOSFET überbrückt und ein Elko spendiert. Nun wackeln die A/D-Wandler nicht mehr so elend. Am (fehlenden) Reset-Pullup hat's nicht gelegen. Der Brownout-Detektor wurde aktiviert. Ein Pin wird frei.
Konsequenz: Die störärmere Speisung der Potenziometer mit AU_CC wurde eingebaut. Dazu Tiefpasskondensatoren. Und der „riesige“ Quarz.

Die Eingänge des AVR lassen sich nicht als Schmitt-Trigger gebrauchen. Daher ist eine rein passive Impulsfilterschaltung unmöglich, und es muss/sollte für den Tacho die „bewährte“ Schaltung vorgesetzt werden. Inzwischen gruselt's mir vor einer Software-Lösung, und ein paar Einzelgatter habe ich noch 'rumliegen.
Konsequenz: Erfordert Platinentwurf, und da kommt gleich mal der piepslige DCK-Typ mit 0,65 mm Pinabstand weg.

Die Servo-Stecker drängeln. Böser Verdacht: Der Pinabstand am Fernbedienungs-Empfänger ist nicht 2,54 mm. Tatsächlich!! Der Spezial-Pfostenstecker hat einen Pitch von 2,64 mm! Gibt's nirgendwo zu kaufen. Deshalb hat sich Adafruit (?) damit beholfen, die PWM-Ausgänge im Viererblock anzuordnen, um weniger zu drängeln. Sie wussten das also. Irgendwoher.
Konsequenz: Wurde im Platinentwurf beachtet. Drängelt immer noch, aber es ist alles steckbar.

Dass der Löffel (Schaufel) des Radladers nicht unabhängig von der Stellung des Hubarms steht ist anzunehmen und vermutlich vorbildgerecht. Aber das Viereckgelenk für den Löffel hat eine Unstetigkeit (nennt man das so?): Das Heben des Arms funktioniert nicht mit komplett heruntergeklapptem Löffel, es klemmt bei 3/4 der Hubhöhe. Na gut, kommt eher selten vor, aber so ist die Kinematik nicht kollisionsfrei! Ein Regler würde sich „zu Tode regeln“.
Konsequenz: Das ist vom Anwender (I²C-Master) zu beachten.

Aus dem Schneider bin ich mit der Wahl des ATmega48 in Durchsteck: So ließ sich bei mangelndem Flash-Speicher (nur wegen Gleitkomma, später unnötig) schnell auf ATmega328 „aufkeulen“.
Konsequenz: Auch der Platinentwurf verwendet den Durchsteck-Typ. Obwohl man mit SMD mehr Platz und 2 A/D-Wandler mehr hat, mit ATmega328B sogar mehr Ein-/Ausgänge.

Mal schnell dem Raspberry das Zerstören der µ-SD-Karte austreiben ist immer noch ungelöst! Hier wird ein Raspberry mit angeschlossenem 7"-Touchscreen eingesetzt. Mit vcgencmd otp_dump kann man den OTP-ROM auslesen, und irgendwie kann man den auch setzen (von wegen One-Time). An Adresse 17 ist (angeblich) folgendes DWORD:

• Bit 1 (0): sets the oscillator frequency to 19.2MHz
• Bit 3 (1): enables pull ups on the SDIO pins
• Bit 19 (0): enables GPIO bootmode
• Bit 20 (0): sets the bank to check for GPIO bootmode
• Bit 21 (1): enables booting from SD card
• Bit 22 (0): sets the bank to boot from
• Bit 28 (1): enables USB device booting
• Bit 29 (0→1): enables USB host booting (ethernet and mass storage)

Mit dem Standardwert 0x1020_000A und dem zu setzenden Wert 0x3020_000A Schon geradezu zu erwarten ist, dass das Setzen von Bit 29 umständlich-verrückt ist: Unter [all] ist in /boot/config.txt die Zeile program_usb_boot_mode=1 einzubauen, und (von SD-Karte) neu zu starten. Das setzt das Bit 28. Erst ein paar Tage später kam ich schließlich zur Funktion:

• Der USB-Massenspeicher muss an der USB-Buchse rechts unten (!!) angesteckt sein, damit's klappt! Andere Buchsen funktionieren manchmal, und das scheint davon abzuhängen, welche weiteren USB-Geräte (hier: Tastatur und Maus) noch angesteckt sind.
• Vom Einschalten bis zum Erscheinen des Vielfarb-Quadrates (wird von bootcode.bin oder start.elf erzeugt) dauert es beim Booten von USB deutlich länger als beim Booten von SD-Karte, also Geduld mitbringen!
• Das mit dem „Beliebige Taste drücken um Bootmeldungen zu sehen“ hat hier noch nie geklappt.
• Damit auch ein 4-GB-Speicherstick genügt, muss man mit dem „Raspberry Pi Imager v1-7-3“ „Raspberry Pi OS (Legacy)“ auswählen. Man muss dabei nicht auf die GUI verzichten. Außer einem anderen Hintergrundbild (Angkor Wat) konnte ich keine Einschränkungen / Nachteile feststellen.
• Aber AFS passt dann nicht mehr 'drauf, und kein Double Commander. Da ist man blind und taub, und es droht Datenverlust durch „Disk Full“!

Oh, ein ATmega-Bug! Oder zumindest ganz schön unterdokumentiert: Bei Slave-I²C-Ausgabe kam es sporadisch zu fälschlich gesetztem Bit 7 beim Raspberry als Empfänger. Das brachte mich auf die Idee, dass:

• der Clock-Stretch zu kurz ist,
• das ACK-Signal in das Bit 7 einstreut,
• der Raspberry mit der steigenden Taktflanke einliest,
• die Leitung zur Erprobung mit 1 m elend lang ist.

Oh, ein Raspberry-Bug! Hier ist's beschrieben: Auch wenn Broadcom beteuert, dass das I²C-Interface I²C-kompatibel ist, das ist auch beim Raspberry Pi 4 nicht der Fall! Mit dem Oszilloskop auf der Fehlersuche sah das Signal 1A wie aus dem Bilderbuch aus: Keine verschliffenen Flanken, keine Überschwinger, Vor- und Nachhaltezeiten korrekt wenn auch manchmal grenzwertig. Aber wehe wenn der ATmega mit seinem Clock-Stretch kommt, da gibt es Takt-Nadeln! Getestet mit Raspberry Pi 3B+.
Die angepriesene Lösung mit dem Pingpong-Treiber ließe sich sicherlich verbessern, wenn man Einzelbytes mit der Broadcom-I²C-Hardware senden/empfangen könnte, also ohne Start- und Stoppsequenz. So wie beim ATmega. Das ist aber (erst mal) nicht mein Bier. Das klappt sogar mit …delay_us=1 und ergibt ca. 330 kHz SCL-Takt. Mit dem 1 m langen Kabel sind die Flanken etwas abgerundet, trotzdem ist die Kommunikation fehlerfrei. Nein! Bis auf das Problem, dass beim ATmega manchmal SDA(!) auf Lo klemmt. Muss noch geklärt werden; bis jetzt (230217) tut's eine Watchdog-Routine (via OCR2B) in der Firmware auflösen. Achtung: Die neue Testsoftware öffnet standardmäßig /dev/i2c-3!

Software-I²C-Treiber mit i2c_gpio_delay_us=1: Taktverfälschung
Gleicher Treiber mit i2c_gpio_delay_us=2 3 Wochen später: Dasselbe
CRC-Fehler im Raspberry, Recover durch Timeout im AVR, Folgeabfrage
Der AVR scheint die Startsequenz „mitten im Byte“ zu ignorieren

Für die (immer schon vorhandenen aber nun massiv, vor allem bei Maus­bewegung) auftretenden Kommunikations­fehler wurde die Raspberry-Software mit einem Debug-Ausgang versehen, der derzeit nur manchmal funktioniert. Aber wenn, dann gibt es tatsächlich auch ein Problem!
Lösung: i2c_gpio_delay_us=2 muss es sein! =1 geht nicht!! (Hier: Raspberry Pi 3) Wer auch immer solche Kernel-Module baut! Dadurch sinkt die SCL-Frequenz von 330 kHz auf 200 kHz, und die mittlere Gesamt-Abfrage­dauer des Test­programms (alle Schichten) beträgt 8 ms.
Drei Wochen später: Oh nein! Es geht immer noch nicht! Der Fehler ist nur seltener geworden, ca. aller 5 Minuten einer.

Die Möglichkeit der Vollgrafikausgabe bewegte mich zunächst nach X11. Immerhin hatte ich dafür mal vor langer Zeit (um 1997) ein Programm erstellt: Einen Videotext-Archiv-Betrachter. Geht heute noch. Auch damals bin ich über das Problem mit den mangelhaften Fonts gestolpert, aber auch heutzutage gibt es keine funktionierende UTF-8-Unterstützung und keine proportionale Schrift, die ansehnlich ist. Weder auf dem Raspberry lokal, noch unter Xming für Windows, der die Windows-Schriften verwenden könnte. Wie ich (durch das Studium veröffentlichter WireShark-Protokolle) herausfand, generieren moderne X11-Anwendungen (etwa Firefox) die Schrift selber und übertragen das gesamte Bild per bitblt. Na schönen Dank auch! Das benötigt massiv Netzwerk-Bandbreite und ist für die Remote-Darstellung schnell veränderlicher Werte so ziemlich ungeeignet. Ein X11-Beispiel für eine einfache, mehrsprachige MessageBox funktioniert bei mir auf Teufel-komm-raus nicht. (Jedenfalls nicht für andere Sprachen außer 7-Bit-Englisch.) Schade auch dass weder Putty noch LXTerminal keine ReGIS-Grafik unterstützt, was wenigstens ein bisschen weiterhelfen würde. Wäre brauchbar um Oszillogramme darstellen zu können. Der Notbehelf Braille-Zeichen ist zu grobpixlig und hat Farbprobleme wenn sich mehrere Grafen schneiden.

230504: Nun ist mir schon zum zweiten Mal ein ATmega328P über den Weg gelaufen, der eine erhöhte Stromaufnahme zeigte! (100 mA bei 4 V, 70 mA bei 3,3 V, normal 7 mA.) Diesmal versagte auch der Pullup an ICP = PB0. (Der erste war aus dem Arduino des Schaltschranks.) Entweder war es derselbe (ich hatte den aber IMHO weggeworfen recycelt) oder die ATmega328P sind empfindlicher (auf was?) als ich dachte. Ein Glück dass genügend herumliegende Arduinos für schnellen Nachschub sorgen.

230509: Huch? Die zweite USV X728 hat einen anderen Mikrocontroller. Dieser sieht wie ein umgelabelter ATtiny45-SO aus. Denn die „überraschend breiten Flatschen“ gab's nur bei Atmel. Und IMHO nur bei ATtinyX5, nicht beim (hier sicherlich mehr als ausreichenden) ATtiny13.
Immerhin, der Bug mit dem prellenden Taster tritt hier nicht auf. Da hat man wohl nachgebessert.

Huch? Eine dritte USV gleichen Typs sieht schon wieder etwas anders aus und hat als Chip wieder den (geratenen) PIC12F508. Also hatte man ein paar Cent Kosten gespart, und die Version mit dem (etwas teureren) ATtiny45 ist die alte Version.

230704: Der Raspberry-4-Compute ist endlich da. Ich hatte einen zerstört, als ich mit Tastspitzen am GPIO-Header der Trägerplatine abgerutscht bin. Zerforscht sozusagen. Für 120 €, nicht wie sonst 39 €. Obendrein eine Light-Version ohne WLAN. Der Unterschied als Foto. Findet keine SD-Karte! Ein Bug?