[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
    Das Repo auf Sourceforge ist down, letzter Public Release: siehe Post #71



    Bin schon gespannt auf Eure Reaktionen.
    liebe Grüße,
    Rainer

    Better-Faster, Innovation

    3 Mal editiert, zuletzt von automated () aus folgendem Grund: Link changed

  • ebay Werbung
  • Update 2017-12-14
    Experimentielle Version mit folgenden Änderungen:

    • Gastabelle wird nun berechnet, Offsets zwischen den Gasstufen (0-15) ist einstellbar - somit sind feinere Abstufungen möglich
    • Bremskurven auf 5 erweitert (0=original, 1-4 werden immer schärfer aber feiner im oberen Bereich)

    Nur auf Atmega328:

    • Delinearisierer implementiert (Anpassung Gaswerte nach hinterlegten Tabellen) um das Ansprechverhalten des Autos anpassen zu können.
    • Delinearisierungskurve und Gain sind im Source über Variablen anwählbar - später über CU² oder Custom Commands via CockpitXP geplant

    Achtung!
    Das EEPROM-Layout wurde geändert, bitte zuerst den Prepare EEPROM Scetch auf den Controller spielen um default-Werte zu setzen



    Pipeline:

    • Weiter an der CU² arbeiten
    • Talkback cur CU² via IR-LED (Prüfstand) zum Auslesen von einstellungen wie Gas, Bremse
    • 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:

    Better-Faster, Innovation

    7 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

    Better-Faster, Innovation

  • 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:


    36346-1af6dc26.jpg

  • ebay Werbung
  • 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.

    Ziel:...

    da haste dir auf jeden fall gut was vorgenommen, aber klingt eindeutig machbar.

  • 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,

    Code
    #if defined(__AVR_ATmega8__) || defined(__AVR_ATmega16__) || defined(__AVR_ATmega32__) || defined(__AVR_ATmega64__)
    {
        //digitalRead and digitalWrite needs too much Time on Arduino - the Price for being versatile ;)
        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 ;)

    Better-Faster, Innovation

  • 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

  • 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:


    Better-Faster, Innovation

  • 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.

  • Google Werbung
  • 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

  • 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

  • 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

  • ebay Werbung
  • 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 ;)

    Better-Faster, Innovation

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

    das müsste der eigene benutzertitel in deinen profileinstellungen sein wenn ich mich nicht täusche

    Genau ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!