[RELEASE] Freie Software für Dxx Digitaldecoder

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • [RELEASE] Freie Software für Dxx Digitaldecoder

      Hallo!
      Ich melde mich nach langen Jahren der Abwesenheit zurück.
      Vor einigen Jahren habe ich ja auf Sourceforge ein Projekt zur Erstellung einer freien Software für Carrera Decoder (AtMEGA8 basierend) initiiert.
      Vielen Dank hier an alle, die bis jetzt mitgewirkt haben, besonders bedanken möchte ich mich bei:
      Mangari - Co Admin, hat dankenswerter Weise alles am Laufen gehalten und Sourcecode bereitgestellt
      Unrene - vielen Dank für die sehr gute Dokumentation im Wiki
      Minislot - vielen Dank für die Hardware-Dokumentation
      Mitglieder die aktiv Code beigetragen haben:
      Mangari, Slotandi, Unrene, Sprintolli, Carreinhard, - vielen vielen Dank!

      Vielen Dank auch an Slotbär für die wirklich ausgezeichnete Dokumentation des D132 Protokolles, und nachträglich noch einmal Entschuldigung für die unglückliche Kommunikation von damals - man wird älter und wächst....



      Meine Programmierkenntnisse waren damals sehr, sehr bescheiden, jetzt sind sie nur mehr bescheiden ;)
      Nachdem ich die letzten Jahre immer mehr auf Arduino gemacht habe, und bei uns im Club hoffentlich bald eine neue Bahn aufgebaut wird habe ich mich zwangsläufig mit dem D132 Protokoll auseinandersetzen müssen.
      (wir wollen eine spezielle Boxengasse bauen, die das IR-Signal des Tanksensors nur weitergibt, wenn auch das passende Auto in seine Tankbucht einfährt)
      Dann vielleicht noch einige Erweiterungen, wie eine wählbare Spannung für beide Slots separat (so will ich gleiche Bedingungen schaffen - es wird ja nie gleich, egal wie man das Layout des Tracks wählt,....)
      Dann noch meinen eigenen Decoder (klein, potent, mit ISP - und Seriellem Port, eventuell mit Rückkanal zur Kommunikation mit der CU
      Und irgendwann will ich das D132 Protokoll "verlassen" (erweitertes Protokoll für 8 Cars, etc.)

      Im ersten Schritt habe ich mich um das Lesen des D132 Protokolles gekümmert, und mit einer Software für Carrera Decoder begonnen.
      -Warum ich eine eigene Software auf dem Decoder will?
      Ich möchte in Zukunft das Ansprechverhalten der Autos ändern können (ist jetzt schon möglich über Neuprogrammieren, später via Bahnprotokoll, ähnlich Gas/Bremse über BB/CU)
      Weiters will ich eine Art "Antischlupfregelung" für den Start implementieren, undwasweisichnochwas.

      Ich will mit Euch meine aktuelle Version einer Arduino basierenden Car-Decoder Software teilen.
      Bitte beachtet dass das sich das Ganze noch in einem sehr frühen Stadium befindet.
      Die Einbindung der entsprechenden Funktionen (soll mal ein LIbrary werden) ist sicher nicht optimal, hier würde ich Hilfe von einem erfahrenen Programmierer benötigen.



      Hier der Link zum Sourcecode : Repo auf SourceForge



      Bin schon gespannt auf Eure Reaktionen.
      liebe Grüße,
      Rainer
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von automated () aus folgendem Grund: Link changed

    • Werbung
    • Update 2017-12-02:
      Erster Release.

      Die Software läuft stabil auf Originaldecodern, auch das Setzen von Gas/Brake in der Boxengasse (Cockpit XP) funktioniert zuverlässig.
      Vielen Dank an Steven für die Tests!



      Pipeline:
      • Weiter an der CU² arbeiten
      • Talkback cur CU² via IR-LED (Prüfstand) zum Auslesen von einstellungen wie Gas, Bremse
      • anpassbarer Adaptionslevel für Gas (um Unterschiede in Motoren anzugleichen - hierfür bauen wir uns einen eigenen Prüfstand)
      • Versuche mit einer zum bestehenden Protokoll kompatiblen Prüfsumme für die Datenworte


      Unterstützt werden:
      • Hardware:
      • Atmega8 (Original Decoder)
      • Atmega328 (getauscht am Ori-Decoder - später für meinen eigenen gedacht)
      • Protokoll:
      • Programmieren von CarID
      • Programmieren von Gas/Bremse auch im Fahrbetrieb (wählbar über #define)
      • Auswertung Frühstart (LEDs blinken)


      Wenn es jemand ausprobieren will, bitte das Setzen der Fuses nicht vergessen (steht im Header des Cardecoder Sources beschrieben)
      Folgende Vorgehensweise ist einzuhalten:
      • Fuses entsprechend der verwendeten Hardware setzen (momentan atmega8, atmega328) - steht im Cardecoder Scetch
      • Wenn Ihr einen Original Decoder zum ersten Mal beschreibt muß ein Chip-Erase vor dem Setzen der Fuses vorgenommen werden. Beispiel: avrdude -p m8 -P usb -c stk500v2 -e
      • die boards.txt Datei aus dem Hardware Ordner in euren Arduino Ordner übernehmen
      • In der Arduino IDE das entsprechende Board wählen (D132_Originaldecoder oder D132_Decoder328)
      • Prepare EEPROM Sketch laden, übersetzen, mit ISP Programmer flashen
      • Nach dem Flashen bitte warten bis die LEDs blinken (EEPROM Werte geschrieben)
      • Cardecoder Sketch laden, übersetzen, mit ISP Programmer flashen


      Alternativ können auch die (ungetesteten) .hex Files aus den jeweiligen Ordnern verwendet werden

      Alte Updates:
      Spoiler anzeigen

      Update 2017-11-27:
      Release Candidate 3

      Fehler in der Routine zur Lichtsteuerung (an/aus) behoben
      "Dirty Patch" für falsches Setzen von Gas0 bei Auto1 (CarID 0) bei Störungen an der Bahn
      Die Software läuft sehr vielversprechend, erste PCB Protoypen sind in Fertigung

      Update 2017-11-23:
      Release Candidate2


      Update 2017-11-22:
      Erster Release Candidate.
      Das Ding läuft auf unserer Bahn nun sauber, unterstützt werden:
      • Hardware - Atmega8 (Original Decoder)
      • Hardware - Atmega328 (getauscht am Ori-Decoder - später für meinen eigenen gedacht)
      • Protokoll:
      • Programmieren von CarID und Gas/Bremse (momentan nur im Stillstand)
      • Auswertung Frühstart (LEDs blinken)


      Update 2017-11-13:
      Ich habe an der Manchester Decodierung rumgefeilt und das Parsen der Datenworte angepasst.
      Die ersten Testläufe gestern waren schon sehr vielversprechend, aktueller SourceCode und ein kompiliertes binary sind im Repository (Post1) zu finden.
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.

      Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von automated () aus folgendem Grund: Update

    • schön, das es an dieser Stelle weitergeht. Wobei es nicht zwingend schön ist, das es auf arduino Basis geschieht.
      ich hatte mich auch schon am weichencode vergangen und den für eine carrera kreuzweiche angepasst und auch um eine Funktion erweitert, um eine normale weiche als cockpit xp sensor zu nutzen. Deshalb war ich für die Grundlagen schon immer sehr dankbar.
    • Jedem das Seine, ich habe halt mit dem Arduino Ökosystem ein gutes Auskommen.
      Die Funktionen sind ja einfach portierbar sofern man in C programmiert - und etwas zu gebrauchen ist ;)

      Adaptierte Weiche ist eine coole Sache, darüber hatte ich auch schon nachgedacht, wir werden aber separate Sensoren verbauen.

      Ich habe noch eine Menge zu lernen, bin meinem Ziel aber schon sehr nahe.
      Bevor ich mit dem Cardecoder weitermache beschäftige ich mich mit dem selber Senden des Datenprotokolles, da ich ein paar eigene Befehle einfügen möchte um die Gas- und Bremskurven über das Bahnprotokoll ändern zu können.
      Das veranstalte ich auf einem ESP32.

      Ziel:
      Dezentrale Anbindung der Controller über AD-Wandler die über I²C und RJ45 Kabel kommunizierten - da sollten sich ca. 4-5m. Kabellänge ausgehen
      vierzeiliges Display an der Box
      6 Eingänge für IR-Sensoren, Anbindung paarweise über RJ45-Kabel
      Kommunikation mit Cockpit XP (Rundenzeiten, Sektorzeiten)
      3x Ausgabe Bahnprotokoll
      Ports 1 und 2 vorläufig mit parallelem Bitflow
      Port 3 mit angehängtem 150us Signal (Pitlane)
      Dezentrale Ausgangsstufe(n) für Bahnspannung/Protokoll
      Kalibrierfunktion für Controller, und und und.....

      Wie weit ich momentan bin:
      Timer für Laptime,
      Senden Bahnprotokoll zyklusgenau (statische Datenworte, noch nicht geparst), Handshake vorbereitet)
      6x IR receiver über Interrupts inkl. Auswertung CarID (Stresstest Gleichzeitigkeit steht noch aus)
      Serielle Kommunikation neben den anderen Tasks
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.
    • Wäre ja schon was feines wenn man ein eigenes System hat was mit C kompatibel ist so das man seinen eigenen Dekoder bauen und "CU" bauen kann
      Ich werde das hier weiter verfolgen :thumbup:
      ------------------------------------------MfG------------------------------------------
      -----------------------------------------Luzen-----------------------------------------
      :mua: wer Recteshchbiehlehr fniedt draf dseie bheltaen :mua:

      :kugeln: Wer zweideutig denkt hat eindeutig mehr Spaß :kugeln:

      
    • Werbung
    • automated schrieb:

      ich habe halt mit dem Arduino Ökosystem ein gutes Auskommen
      prinzipiell mag ich arduinos auch - aber wenn es zeitkritisch wird, muss man weg von arduino befehlen und vieles selber machen. aber so lange es läuft ist es super.
      da haste dir auf jeden fall gut was vorgenommen, aber klingt eindeutig machbar.
    • quotschmacher schrieb:

      prinzipiell mag ich arduinos auch - aber wenn es zeitkritisch wird, muss man weg von arduino befehlen und vieles selber machen. aber so lange es läuft ist es super.
      Ja, das musste ich auch feststellen,

      Quellcode

      1. #if defined(__AVR_ATmega8__) || defined(__AVR_ATmega16__) || defined(__AVR_ATmega32__) || defined(__AVR_ATmega64__)
      2. {
      3. //digitalRead and digitalWrite needs too much Time on Arduino - the Price for being versatile ;)
      4. rbit = (PIND & (1<<PD2));
      So frage ich bspw. den Pin für das Bahnsignal ab
      Mein Eigenbau-Decoder soll dann auf einem 328 laufen, hat ein paar PS mehr ;)
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.
    • Hallo Rainer,

      Da hast Du Dir ja einiges vorgenommen. Ich habe ebenfalls einen Decoder selbst gebaut, der auch generell funktioniert. Probleme gibt es im Zusammenhang mit Cockpit-XP. Da erkennt der Decoder nicht alle Programmierworte.

      Wie läuft denn Dein Decoder? Hast Du schon Erfahrungen mit Cockpit-XP damit machen können.

      Frank
      :thumbsup:
    • Hallo RedFranky!
      Läuft soweit gut, ich habe letztens ein paar .zig Runden auf unserem Track gedreht.
      Der Test der letzten Änderungen steht noch aus (Bremse verriegeln bei Neustart) steht noch aus.

      Ich habe momentan nur die Programierworte 0 und 1 (Gas, Bremse) implementiert.
      Welche Programmierworte verwendet Cockpit XP?

      Zu den Programmierworten:
      Kommando2: werde ich nicht unterstützen
      Kommando 4, value 0 und 8: ist mir klar
      Rest Kommando 4: Es ist mir noch unklar, wie das Auto auf die verschiedenen Fuel Level zu reagieren hat
      Kommando5: ist das für das Auto von relevanz?

      Eventuell kann sich ja jemand, mit einem Oszilloskop bewaffnet die Duty Cycles eines Ori-Decoders am Motorausgang (mit ohmscher Last) bei folgenden Betriebszuständen ermitteln, das wäre eine große Hilfe:
      Jeweils für Gas 0-15:
      Normalbetrieb
      In der Boxengasse mit vorhandener Pitstop Lane
      Kommando 4, value 0-7


      Ich liste hier mal die mir bekannten Programmierworte auf:

      Quellcode

      1. * Known Commands for CU communication (from Slotbaers Documentation - Thanks for That!!)
      2. *
      3. * Word Comment Bits Descriptor for Shortcuts
      4. * n 13 12 11 10 9 8 7 6 5 4 3 2 1 0 V Value
      5. * 1 ProgrammingDataword | 1 | V0| V1| V2| V3| C0| C1| C2| C3| C4| R0| R1| R2| C Command R Controller
      6. *
      7. *Command Value Controller Description
      8. *0 0-15 0-5 Set Speed for Car (R)
      9. *1 6-15 0-5 Set Brake for Car (R)
      10. *2 0-15 0-5 Set Tank Size for Car (R)
      11. *3 unknown or not used
      12. *4 0 0-5 Normal mode for Car (R), no Pitlane Adapter connected
      13. *4 0-7 0-5 Normal mode for Car (R), Value equals to Fuel Level. 0=empty, 7=full Pitlane Adapter connected
      14. *4 8 0-5 Car blinks due early Start no Pitlane Adapter connected
      15. *4 8-15 0-5 Car blinks due early Start, Value equals to Fuel Level. 15=full Pitlane Adapter connected
      16. *5 0 0-7 Car leaves the Mode "Enable to refuel"
      17. *5 1 0-7 Car enters the Mode "Enable to refuel"
      18. *6 1-8 0-7 Position of Car (R)
      19. *6 9 0 Sent on first Press of Start Button (all LEDS red) - resets Position Display
      20. *7 1 0-7 Car (R) has done the Race
      21. *8 1 0-7 Car (R) has passed the Finish Line with new best Laptime
      22. *9 1 0-7 Car (R) has passed the Finish Line without new best Laptime
      23. *10 0-7 0-5 Fuel Level for Car (R)
      24. *10 15 0 Turn off Fuel Display on DriverDisplay till the next Delivery of a Fuel Level (command above)
      25. *10 15 4 Reset the first delivered ProgrammDataword ???????????????? WHAT ???????????????
      26. *11 1 0-5 Early Start by Car (R)
      27. *12 unknown or not used
      28. *13 unknown or not used
      29. *14 unknown or not used
      30. *15 unknown or not used
      31. *16 0-5 7 Active LEDS of CU and Start Traffic lights
      32. *17 0-15 7 Lap Time of Leader: High Nibble - only sent if no Lap Counter is connected to CU
      33. *18 0-15 7 Lap Time of Leader: Low Nibble
      34. *19 0 7 Reset
      35. *20 1-4 7 Finish Lane Mode of Pitlaneadapter: 1=off, 2=Finish Line, 3=Pace Time1, 4=Pace Time2
      36. *20 15 7 Reset after Commands 19, 0, 7 - CU will check for Pitlaneadapter available after that
      37. *21-31 unknown or not used
      38. *
      39. *Custom Commands: DANKGER!!! IF WE HAVE BAD LUCK THIS COULD CAUSE TROUBLE, IN THE WORST CASE WE "catch" A FUNCTION WHICH WRITES TO PERIPHERY
      40. *17 10-11 0 Sending custom Gas values |
      41. *18 0-15 0 Index (0-15) - where to write } One Block for writing custom Gas/Brake Values, each Command Pair (17+18) is sent two times
      42. *17 0-15 0 Data (High nibble) | CarGassteps[0-15] or CarBrakesteps[0-10]
      43. *18 0-15 0 Data (Low nibble) |
      44. *17 10-11 0 End of Block |
      45. *18 0-15 0 Checksum | Calculate: XOR Hnibble,Lnibble
      46. *
      47. */
      Alles anzeigen
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.
    • Hallo Frank,


      >Probleme gibt es im Zusammenhang mit Cockpit-XP. Da erkennt der Decoder nicht alle Programmierworte.

      Ich denke da täuscht du dich.
      Cockpit-XP macht keinerlei Änderungen am Bahnprotokoll
      Und Setzen von Geschw/Bremse ist Standard
      Also da liegst du komplett falsch.



      Es grüßt Cockpit-XP
    • Werbung
    • automated schrieb:

      Eventuell kann sich ja jemand, mit einem Oszilloskop bewaffnet die Duty Cycles eines Ori-Decoders am Motorausgang (mit ohmscher Last) bei folgenden Betriebszuständen ermitteln, das wäre eine große Hilfe:
      @MiniSlot hat da mal was für Speed und Brake gemessen, vielleicht hilft dir das ja weiter:
      Open Lap - Open Source Android-App für Carrera Digital 124/132
      Open Lap - Slot Car Race Management App for Carrera(R) Digital 124/132 (Google Play)
      carreralib - Python interface for Carrera(R) Digital 124/132 slotcar systems
      CarreraDigitalControlUnit - Carrera(R) Digital 124/132 interface library for Arduino and mbed OS
    • Hallo Cockpit,

      Bitte nicht falsch verstehen, ich gebe Cockpit-XP ja nicht die Schuld, dass bei mir etwas nicht funktioniert. Mein Decoder versteht die Programmierdatenworte für Bremse und max. Geschwindigkeit, seit kurzem sogar für alle 16 Stufen. An der CU kann man ja nur 10 verschiedene Werte einstellen.

      Also die Einstellungen von Bremse und max. Geschwindigkeit funktionieren bei mir im Stand und auch während der Fahrt wenn man die Programmierung an der CU vornimmt. Es funktioniert auch mit Cockpit-XP wenn man langsam macht. Bei normalem "Renntempo" gehen Werte verloren. Evtl. liegt es auch an dem Kontakt zur Fahrbahn und/oder wenn das Auto über eine Weiche fährt. Die CU sendet die Programmierdatenwort ja 2 mal hintereinander. Mein Decoder erwartet die beiden Programmierdatenworte um Datenübertragungsfehler auszuschließen. Vielleicht sollte ich das lassen und bereits das erste Programmierdatenwort akzeptieren.

      Weiß jemand zufällig wie der original Decoder das macht?

      Frank
      :thumbsup:
    • Hallo Rainer,

      Mein Decoder unterstützt nur die Programmierung von max. Geschwindigkeit und Bremse. So weit ich weiß braucht man die Tankeinstellungen bei Verwendung einer CU nicht mehr.

      Hast Du eigentlich eine eigene Hardware gemacht oder programmierst Du den Carrera Decoder um?

      Frank
      :thumbsup:
    • Werbung
    • RedFranky schrieb:

      Hast Du eigentlich eine eigene Hardware gemacht oder programmierst Du den Carrera Decoder um?
      Noch vergew* ich einen OriginalDecoder - mit dem 16*x6 Array für Gas geht mir gerade das RAM aus :( *miau*, habs mir schon beim Einfügen in den Code gedacht, daß das an den Baum angeht :D
      -eigener Decoder ist in Planung, dort will ich einen ATMEGA328 verbauen - eventuell ziehe ich den vor.
      Es ist ja immer so: 90% hat man sehr schnell erreicht, für die restlichen 9% benötigt man die gleiche Zeit wie für die ersten 90,.......

      OK, danke für den Hinweis mit dem Tanken - das lasse ich dann mal fallen
      Danke auch für Deinen Sourcecode den Du zum Download bereitstellst - ist eine große Hilfe!

      Ich habe meine CU² jetzt mal soweit dass sie brav das Protokoll ausgibt, ich will das 150us Pitlane Signal am Decoder verwenden, um Gas zu limiten und die Bremse hochzustellen (versorge die Boxengasse separat von der CU² aus)

      Ich versuche jetzt mal das 16x16 Array vom EEPROM aus zu handlen, schau mer mal ;)
      Wissen ist das einzige Gut das sich vermehrt wenn man es mit anderen teilt.
    • automated schrieb:

      btw: wie kommt man zu dem Status "Open-Source-Aficionado" ? - wär doch glatt was für mich :D

      quotschmacher schrieb:

      das müsste der eigene benutzertitel in deinen profileinstellungen sein wenn ich mich nicht täusche
      Genau ;)
      Open Lap - Slot Car Race Management App for Carrera(R) Digital 124/132 (Google Play)
      carreralib - Python interface for Carrera(R) Digital 124/132 slotcar systems
      CarreraDigitalControlUnit - Carrera(R) Digital 124/132 interface library for Arduino and mbed OS