Funktionsgenerator oder wie erzeugt man DCC Signale zum Test von Modellbahn Decodern

stinakovits

Mitglied
22. Apr. 2013
90
6
8
Kottingbrunn
Sprachen
  1. Assembler
Hallo zusammen,

für ein aktuelles Projekt wäre es sehr hilfreich einen Funktionsgenerator zu haben der Rechtecksignale mit variabler Breite liefern kann. Also fix programmierbare Sequenzen von aneinander gereihten Rechtecken die unterschiedliche Breiten haben. Schwer zu erklären. Daher hier ein Bild.

1597781887879.png1597781956994.png

Hab keinen Funktionsgenerator. Wenn es einen gibt der derartiges bieten kann würde ich einen Erwerb, so ich mir das Ding dann auch leisten kann, in Betracht ziehen.

Gibt es jemanden der damit Erfahrung hat?
 
Hi Manfred,

so etwas nennt sich Arbitrary-Generator ( https://de.wikipedia.org/wiki/Arbiträrgenerator ).
Der kann aber nur wiederkehrende "analoge" Muster erzeugen. Bei dir sieht es eher nach einem digitalen Muster / Bitmuster aus.
Das wird wohl auch ein Arbitrary-Generator nicht können (auf jeden Fall die bezahlbaren nicht :flute:). Je nach Speichertiefe für die
Muster wird der Preis sowieso recht heftig.

Ich hab mal ein wenig gesucht ... PEAKTECH 4120 Funktionsgenerator, arbiträr, 1 µHz ... 5 MHz ( 279,-eur )
- integrierter Wellenformeditor (2 bis 8000 Punkte)
Die Anzahl der Punkte sagt aber nichts über die Darstellungsmöglichkeit der Wellenform. Wenn die Zwischenwerte interpoliert werden,
dann bekommt man dort mehr oder weniger eine Sinuskurvenformation raus. Das ist wohl nicht so was gewünscht wird.

Weiter geht es dann unter anderem mit ... MFG-2160MR Funktionsgenerator, arbiträr, 1 Kanal, 60 MHz, RF 320 MHz ( 834,-eur )
- Punkt-für-Punkt-Ausgabe von arbiträren Wellenformfunktionen : 200 MSa/s, 100 MHz Wiederholrate, 14 Bit Auflösung, 16k Speichertiefe
... und natürlich ist die Preisspanne nach oben offen o_O

DCC hört sich mächtig nach Modellbahn an. Willst du damit den Booster steuern? oder soll der Generator das Gleis selber versorgen?
Außerdem ist das ein bidirektionales Protokoll. Die Endgeräte arbeiten mit der Modulation des Laststroms (wenn ich mich recht entsinne).
So etwas ist schon echt speziell. Würde ich eher als "Protokoll-Gateway" und nicht als "Funktionsgenerator" benennen.

Sieht nach einer Frequenzumtastung mit Fehlereinbau (verlängertes 0-Bit) für die Anfangskennung eines Datenframes aus.
Such mal im "Stummis Modellbahnforum" (https://www.stummiforum.de). Da hab ich damals ne Menge Infos gefunden.
Es ist auf jeden Fall ein guter Startpunkt für eine Suche.

Gruß
Dino
 
Zuletzt bearbeitet:
Hi Dino,

danke für deinen Beitrag.
So ähnliche wie du aufgelistet hast, hab ich im Netz auch gefunden. Leider konnte keiner das Gewünschte darstellen. Egal wie teuer.

DCC hört sich mächtig nach Modellbahn an.

Ja, so ist es. Sind die Steuersignale für Decoder.

Willst du damit den Booster steuern?

Nein. Ich entwickle Zubehördecoder die der DCC Norm entsprechen und mit diesen Signalen programmiert und gesteuert werden.

oder soll der Generator das Gleis selber versorgen?

Nein. Die Decoder hängen zwar am Gleissignal, werden jedoch mit DC Spannung fremdversorgt. Digitalstrom ist teuer. Es kommen nur die Befehle vom DCC Gleissignal.

Außerdem ist das ein bidirektionales Protokoll.

Naja, in der gelebten Praxis nicht wirklich oder extrem selten. Theoretisch ist es bidirektional. Verwendet aber kaum ein Decoder.

Die Endgeräte arbeiten mit der Modulation des Laststroms (wenn ich mich recht entsinne).

Ja. Das Signal transportiert sowohl die Energie für die Motoren als auch die Befehle für die Decoder. Daher sind es in der Regel symmetrische Signale. Gleichgerichtet ergibt es eine "schönes" DC Spannung und die positive Halbwelle verwendend kommen die Nullen und Einsen für die Datenübertragung daher.

Sieht nach einer Frequenzumtastung mit Fehlereinbau (verlängertes 0-Bit) für die Anfangskennung eines Datenframes aus.

Nein. Die Synchronisierung vor den Datenframes erfolgt mit 11 Einser Bits. Das verlängerte Null-Bit ist was spezielles. Wird verwendet wenn eine analoge Lok auf einer digitalen Anlage fahren soll. Ist in der gelebten Praxis eher eine seltene Ausnahme. Ich kenne niemanden der das macht.

"Stummis Modellbahnforum"

Ja, ist mir natürlich als Modellbahner bekannt. Hat mich aber auch nicht wirklich weiter gebracht.


Tja, da muss ich wohl, obwohl ich das vermeiden wollte, doch eine DCC-Zentrale zum entwickeln besorgen. (Die von der Modellbahn kann ich nicht abbauen. Die Kollegen würden mich "fressen") :cool:
 
Woher kommen die auszugebenden Bits?
Grundsätzlich sollte sich das doch durch einen Tiny selbst machen lassen (PWM wegen der Pufferung, ein Compare für die Frequenz, eins für die Hälfte, im IRQ der Hälfte dann die Werte für das Nächste Bit vorladen.
Werte kommen zB über UART rein, Ringpuffer, Ausgabe.
Sollte mit etwas Bitgeschubse in Assembler kein Ding sein.
Zum Analog-Lok-Kram hast du ja noch keine konkreten Anforderungen geschrieben.

Auswertung des Laststromes ist vom Tisch?
 
Hallo,

ich würde da auch eher mit nem ATmega nen eigenes Gateway bauen. Zum PC hin ne serielle Schnittstelle (UART) und zur DCC-Seite dann ne Gegentaktendstufe, die das Signal rausbringt. Im Gegenzug könnte man das Gateway dann auch zum Mitlesen verwenden. Sozusagen nen DCC-Sniffer der die Daten per UART an ein Terminalprogramm sendet.
Das Protokoll sollte nicht allzu schwer sein. Könnte man dann auch noch auf Merklin-Protokoll erweitern.

Schau mal hier ...
Eventuell kann man da was wiederverwerten oder eine Richtung für die Suche nach Lösungen erkennen

Gruß
Dino
 
Zuletzt bearbeitet:
Woher kommen die auszugebenden Bits?

Auszugebenden Bits? Ich will keine Bits ausgeben. Ich will ein "Gerät" welche die Bits ausgibt um meine Entwicklungen zu entwickeln und zu testen. Also sowas wie einen Funktionsgenerator. Leider scheint es keinen zu geben der meine Anforderungen unterstützt. Dino hat es schon gesagt: "Etwas spezielles". Nun. Es ist wie es ist. Ich brauch halt eine richtige DCC-Zentrale um die gewünschten Bitfolgen in der gewünschten variablen Amplidudenbreite er erhalten.

Grundsätzlich sollte sich das doch durch einen Tiny selbst machen lassen (PWM wegen der Pufferung, ein Compare für die Frequenz, eins für die Hälfte, im IRQ der Hälfte dann die Werte für das Nächste Bit vorladen.

Ja. Da hast du vollkommen Recht! Aber ich will nicht erst das Prüfgerät entwickeln um meine Entwicklungen zu entwickeln und zu testen :eek:

Sozusagen nen DCC-Sniffer

Gibt es einige. Aber was fang ich mit einem Sniffer an, wenn nichts da ist was snifft ;)

noch auf Merklin-Protokoll erweitern.

Könnte man. Aber davor graust mir jetzt schon. Nein nein. Ich bleib bei DCC. Das ist ein weltweites Protokoll und nicht so proprietär wie das Motorola, mfx usw. von Märklin. Unsere Anlage besteht aus Märklin Schienen, teilweise Märklin Loks (alle auf DCC umgebaut), Märklin Waggone aber gesteuert wird mit DCC. Man nehme halt das Beste aus beiden Welten :) (Aber ist nur meine bescheidene Meinung - Märklinisten würden mich für so eine Aussage wohl am nächsten Baum aufknüpfen :yes4: )
 
Ich will keine Bits ausgeben. Ich will ein "Gerät" welche die Bits ausgibt um meine Entwicklungen zu entwickeln und zu testen.
Doch, Dein Gerät soll "irgendeine" Bitfolge (bzw mehrere) ausgeben, und meine Frage war, wie Du dem Gerät mitteilen willst, welche konkrete Bitfolge (also welches Telegramm) ausgegeben werden soll.
 
Doch, Dein Gerät soll "irgendeine" Bitfolge (bzw mehrere) ausgeben

Lieber LotadaC, ich hatte es falsch verstanden. Du meinst natürlich das Gerät welches mir die Bitfolgen schicken soll um meine Entwicklung zu testen. Klarerweise muss diese Bitfolge, also die unterschiedlichen Amplidudenlängen, programmierbar sein. Nach langem Suchen und Lesen hab ich festgestellt, dass auch, wie mir schon von Dino03 mitgeteilt wurde, ein Arbitrary-Generator das auch nicht kann. Zumindest nicht so wie ich es brauche. Also bleibt wohl nur der Weg eine richtige DCC Zentrale zu besorgen, welche die notwendigen Befehle in DCC Signale umsetzt. Wie es ausschaut führt kein Weg daran vorbei.
 
Du meinst natürlich das Gerät welches mir die Bitfolgen schicken soll um meine Entwicklung zu testen. Klarerweise muss diese Bitfolge, also die unterschiedlichen Amplidudenlängen, programmierbar sein.
Ich habe die Tabelle und die Darstellung aus #1 so verstanden:
  • Jedes Bit beginnt mit einer fallenden Flanke endet vor der fallenden Flanke des nächsten Bits
  • die Zeiten beider Pegel sollen symmetrisch sein
  • 'ne "1" soll insgesamt 116µs dauern, 'ne "0" 200µs (plusminus Toleranzen, klar) - oder meinst Du mit "unterschiedlichen Amplitudenlängen" noch was anderes?

Du willst jetzt irgendwelche … äh … Slave Geräte entwickeln und/oder testen, die über diesen Weg angesprochen werden können.
Du willst also irgendwelche Binären Telegramme (auf einem immer noch nicht näher genannten Weg) erzeugen, in Dein AWG/Gateway/Mikrocontroller einspeisen, der die TTL-Bits in diese... äh … frequenzmodulierten (Dino, wie heißt das korrekt?) Bits umwandelt, und diese (über eine Push-Pull-Endstufe) ausgibt.

Du hast eine eher spezielle Anforderung, die aber eigentlich nicht sonderlich schwer umzusetzen ist - warum also nicht selbst das Gateway umsetzen?

Mein Vorschlag aus #4 (den auch Dino aufgegriffen hat) war, daß Du im einfachsten Fall dein Bit-Telegramm am PC in irgendein Terminalprogramm eintippst und absenden läßt. Sinnigerweise vorrausgehend die Anzahl der Telegramm-Bits mitsenden.
Der Controller liest aus dem ersten empfangenen Byte also die Anzahl der zu sendenden Bits aus (und ggf auch die Anzahl der zu empfangenen Bytes); ab dem zweiten Byte werden alle beim Empfang zwischengespeichert, bei hinreichend hoher Baudrate (über den Daumen ab 11kBaud) kannst Du sofort nach Empfang des zweiten Bytes (das erste Telegramm-Byte) loslegen lassen.
erstes Bit aus dem Byte schieben und entsprechend die beiden Compare Register schreiben (eins für die steigende Flanke, eins für den Überlauf = fallende Flanke). Den eigentlichen Timer einen Takt vor den Überlauf setzen und starten, dann den Ausgangstreiber aktivieren (bzw die Gegentaktendstufe).
Das alles im UART-Empfangs-IRQ.

Im CompareB-IRQ wird jetzt jedesmal ein Bit weitergeschoben (und ggf vorher das nächste Byte aus dem Puffer geladen), und die Compare-Register für das nächste auszugebende "Bit" vorbereitet. Bei PWM erfolgt der Schreibzugriff auf die Compare-Register gepuffert Änderungen die hier im CompareB-IRQ gemacht werden, werden erst beim Überlauf (CompareA) wirksam. Also das nächste Bit.
Bei Überlauf des Bitzählers (das letzte Bit wird also gerade ausgegeben, die steigende Flanke wurde gerade erzeugt) wird der das Bein vom PWM abgekoppelt und fest auf high gelegt, und außerdem der CompareA-IRQ (Timerüberlauf) scharfgemacht.

Im CompareA-IRQ wird die Gegentakt-Endstufe abgeschaltet, und der Timer angehalten, anschließend entschärft sich der IRQ selbst.

Bei 'nem effektiven Timertakt von 1MHz (also 8MHz und Vorteiler=8) ist es nicht sonderlich überraschend, daß für 'ne "1" 115 ins CompareA und 57 ins CompareB des 8Bit-Timers zu laden sind; für'ne "0" entsprechend 199 bzw 99.
Clever könnte das festlegen der Compares etwa so ablaufen:
115 mit LDI in ein Rechenregister laden
bei gesetztem nächsten Bit in Telegramm-Byte mit SBRS die das folgende LDI skippen
199 in dasselbe Rechenregister laden
Telegramm-Byte schieben
Rechenregister nach CompareA ausgeben
Rechenregister schieben
Rechenregister nach CompareB ausgeben

7 Takte

Wenn jedes Telegramm mit elf einsen beginnt, muß man das natürlich nicht unbedingt jedesmal durch den UART jagen.

Ja. Das Signal transportiert sowohl die Energie für die Motoren als auch die Befehle für die Decoder. Daher sind es in der Regel symmetrische Signale. Gleichgerichtet ergibt es eine "schönes" DC Spannung und die positive Halbwelle verwendend kommen die Nullen und Einsen für die Datenübertragung daher.
und
Die Decoder hängen zwar am Gleissignal, werden jedoch mit DC Spannung fremdversorgt. Digitalstrom ist teuer. Es kommen nur die Befehle vom DCC Gleissignal.
Wie ist das jetzt konkret zu verstehen?
Die gesamte Anlage wird bereits über irgendein DCC-Master-Gerät gesteuert, und Du willst jetzt mit Deinem Entwicklungswerkzeug-Gerät zusätzliche Steuersignale erzeugen?
Oder wird der vorhandene Master dazu getrennt?
Oder soll die Entwicklung und Testung getrennt von der Anlage erfolgen (also nur der Slave am (noch nicht vorhandenen Gateway/AWG/Controller-Werkzeug)?)
Brauchst Du beim letzten Fall dann überhaupt 'ne zusätzliche Gegentakt-Endstufe, oder könnte der Controller das Signal direkt erzeugen?
 
Hi,

ich glaube, ich habe was gefunden (jedenfalls ein Stichwort) ...


Das Stichwort ist "Patterngenerator" (aber nicht die Generatoren für Testbilder beim Fernsehen).



Such mal in der Richtung weiter (Google: "bit pattern generator" oder "Bitmustergenerator")
Bei dem einen Gerät bei meinen Links stand was von 199,- dollar. Würde ich als angemessen ansehen.

Gruß
Dino

Edit:

OK ... € 1.612,40 inkl. MwSt :flute:

32 Ch, 1 GHz USB LA & Pattern Gen. - The LA-Gold-36 combines two in one device, a sophisticated logic analyzer with a bit patterngenerator. The testing of digital circuits has never been easier! ---> scheint um einiges günstiger zu sein.
 
Zuletzt bearbeitet:
Hi,

Wie ist das jetzt konkret zu verstehen?
Die gesamte Anlage wird bereits über irgendein DCC-Master-Gerät gesteuert, und Du willst jetzt mit Deinem Entwicklungswerkzeug-Gerät zusätzliche Steuersignale erzeugen?
Oder wird der vorhandene Master dazu getrennt?
Oder soll die Entwicklung und Testung getrennt von der Anlage erfolgen (also nur der Slave am (noch nicht vorhandenen Gateway/AWG/Controller-Werkzeug)?)
Brauchst Du beim letzten Fall dann überhaupt 'ne zusätzliche Gegentakt-Endstufe, oder könnte der Controller das Signal direkt erzeugen?

also normalerweise werden die angeschlossenen Clients über die "Datenströme" auch versorgt. Quasi ein "Power over DCC" :sarcastic:
Bei manchen Geräten in Modellbahnen wird das Gerät direkt von einer Spannungsquelle versorgt und es empfängt durch die Ankopplung an das Gleis nur den Datenstrom. Hängt also nur "hochohmig" mit am Gleis. Da sowas bei Loks oder Wagen mit Funktion (Kranwagen) nicht geht, müssen die eben über den "Datenstrom" mit verorgt werden. Dafür wird der Datenstrom in einen Booster geschickt, der die entsprechenden Ströme liefern kann. Grob vergleichbar mit nem CD-Player (DCC-Master), nachgeschaltetem Verstärker (Booster) und angeschlossenem Lautsprecher (Lok, ...).
Für Tests kann man die entwickelten Schaltungen natürlich fremdversorgen und nur den Datenstrom vom Bitmustergenerator liefern lassen.

Gruß
Dino
 
Guten Morgen!

Der Weg der "Bitmuster" ist folgender:

Grundsätzlich wird ein PC dazu verwendet die Modellbahnanlage zusteuern. Am PC ist das Gleisbild. Der PC sagt der Anlage wo es lang geht, was gemacht werden muss, wo und wie die Züge fahren. Er passt auf, dass keine Unfälle passieren. Er koordiniert die Anlage vollautomatisch. Man sieht einfach zu wie sich die Welt im Kleinen bewegt.
Der PC liefert seine Informationen an eine Steuerzentrale. Diese setzt die Befehle des PC in ein genormtes Protokoll, namens "DCC" -> "Digital Command Control" um. Diese Steuerzentrale schickt die DCC-Signale an einen Booster (manche Zentralen enthalten bereits einen Booster). Dieser "verstärkt" die Signale. Liefert also die Energie, moduliert mit den DCC-Signalen/Befehlen auf das Gleis oder sonst wo hin. Dies war die sendende Seite.

Nun die empfangende Seite. Dieses DCC Gleissignal wird von verschiedenen Arten von Decodern aufgenommen, ausgewertet und in Aktionen umgesetzt.
Lokdecoder: Diese steuern die Motoren und verschiedene Zusatzfunktionen, wie Lichter an der Lok, in den Waggonen, Rauchgeneratoren oder anderes.
Zubehördecoder: Diese steuern alles andere was gesteuert werden kann. Ein großes Betätigungsfeld sind Beleuchtungen und die Ablaufsteuerung dafür. Ebenso müssen die Weichen und die Signale gesteuert werden. Mitunter auch Bewegungsabläufe wie Schranken oder sonstige Aktionen. Auch wären da noch die Rückmeldedecoder. Diese sind essentiell damit der PC weiß welche Lok gerade wo unterwegs ist. Es existieren da unzählige Möglichkeiten und der Fantasie sind keine Grenzen gesetzt.

Jetzt komme ich ins Spiel. Es gibt am Markt schon sehr vieles. Aber auch vieles nicht. Das muss dann, wenn man es denn haben möchte, selbst entwickelt werden. Auch ist manches eine Kostenfrage. Wenn etwa ein Rückmeldedecoder für 16 Eingänge am Markt 30 Euro kostet und ich mit einem ATmega einen mit 32 Eingängen zu etwa 15 bis 20 Euro bauen kann, ist das bei einem Bedarf von rund 30 Decodern alleine nur für die Rückmeldungen eine zu überlegende Alternative. Natürlich darf ich meine Entwicklungszeit nicht rechnen. Ist ja Hobby und Freizeitgestaltung.
Im Konkreten arbeite ich an einem Beleuchtungsdecoder für einen bestimmten Bahnsteigtyp von Faller. Die Platine ist passgenau und wird direkt unters Dach geklemmt um den Bahnsteig zu beleuchten. Natürlich soll sich da auch etwas tun. Also wird zu einer bestimmten Zeit (eine Tag-Nacht Steuerung gibt es natürlich auch - also einige Minuten ist die Beleuchtung an, dann wird es Abend, die Beleuchtung schaltet langsam runter bis es Nacht wird um dann wieder in den Morgen überzugehen.) die Beleuchtung angeschalten und bei kleinen Haltestellen ist in der Nacht keine Betrieb, also ausgeschalten um am Morgen wieder eingeschalten zu werden. Über Tag braucht man auch kein Licht am Bahnsteig. Allerdings an manchen Bahnsteigen schon. Die LEDs bilden beim Einschalten unterschiedliche Beleuchtungsmittel ab. Also etwa das Flackern und verzögerte Schalten von Neonröhren usw.
Die zu entwickelnde Platine braucht für ihre Funktion Befehle was sie wann tun soll. Wie sie es tut wird von Parametern gesteuert welche sich in genormten CVs befinden. CV ist einfach eine Speicherstelle mit einer genormten Nummer. Die DCC Norm sorgt dafür, dass Produkte unterschiedlicher Hersteller zusammen arbeiten können.
Für die Entwicklung solcher Produkte benötigt man diese genormten Signalfolgen um sie zu entwickeln und zu testen. Das ist essentiell!
Auch andere, als der jetzt beschriebene Decoder, liegen schon als fertige Print vor mir. Aber eins nach dem Anderen. Eine Hardware ist schnell entwickelt. Aber die Software, also das Herz des Ganzen, braucht schon eine Weile. Zumindest bei mir :cool:

Ich hoffe den Hintergrund einigermaßen rüber gebracht zu haben ......

Das Stichwort ist "Patterngenerator"
Das klingt super. Werde ich mir genauer anschauen!

OK ... € 1.612,40 inkl. MwSt
UPS ..... :eek:

also normalerweise werden die angeschlossenen Clients über die "Datenströme" auch versorgt............
Dino hat das exakt und viel kürzer erklärt als ich :rolleyes:
 
Und noch ein Lustiger Beitrag von mir hier im Forum.
Wenn ich dich richtig verstehe könnte es doch so was für Testzwecke sein.

1598098503926.png


Hatte mal 5 Stück gekauft alle funktionieren zuverlässig auch bei 1 oder 99 %. Ist ja das Lustige. Artikelpreis EUR 3.58 mit Versandkosten.

Gruß
fredred
 
Soo..

wenn man mal NEM 670 und NEM 671 anschmökert, wird's klarer und auch deutlich leichter

  • das DCC-Signal ist quasi 'ne (nicht-Sinus-)Wechselspannung (soweit bisher klar)
  • es werden immer Bytes gesendet, nach jedem Byte folgt allerdings ein zusätzliches Bit, welches immer "0" ist, nur am Ende des Telegrammes ist es "1"
  • für die äh … Frequenzsynchronisation soll der Master vorher mindestens sechzehn "1"-Bits senden
  • das letzte Telegramm-Byte enthält eine Prüfsumme (bitweises XOR) aller vorangegangenen Telegram-Bytes

Das Signal transportiert sowohl die Energie für die Motoren als auch die Befehle für die Decoder. Daher sind es in der Regel symmetrische Signale. Gleichgerichtet ergibt es eine "schönes" DC Spannung und die positive Halbwelle verwendend kommen die Nullen und Einsen für die Datenübertragung daher.
Wie konkret?
Graetz+Pufferkondensatoren ergeben (im Idealfall) 'ne mehr oder weniger saubere Gleichspannung.
Ohne Pufferkondensatoren hast Du dann für jedes Bit zwei gleich lange Hi-Pulse (bzw einen Gnd-Puls in der Mitte)?

Zeig mal bitte den entsprechenden Teil der Schaltungen, und gib an, was die Dekoder konkret für die Bitlängen messen (nur einen beliebigen der beiden Halb-Pulse, oder den Doppel-Puls nach Gleichrichtung).

(oder wird 'ne Einweg-Gleichrichtung verwendet?)

Dann müßte der PC eigentlich nur die Datenbytes und entweder die Anzahl der Bytes oder irgendeinen Terminator (oder irgendwas mit Timeout) senden, der Gateway-Controller stellt sechzehn Synchronisationsbits voran, füllt die "0"-Zwischenbits auf und generiert die Prüfsumme gefolgt vom "End of Telegram"-Bit (wobei die Bits vom PC zum Gateway TTL sind, und die Bits vom Gateway zum Dekoder "DCC-frequenzmoduliert")
 
Hi LotadaC,

Zeig mal bitte den entsprechenden Teil der Schaltungen, und gib an, was die Dekoder konkret für die Bitlängen messen (nur einen beliebigen der beiden Halb-Pulse, oder den Doppel-Puls nach Gleichrichtung).

den Doppel-Puls nach Gleichrichtung wird man schlecht messen können da es ja nen Rechtecksignal ist. Es geht eigentlich nur weil die SlewRate ja nicht unendlich hoch sein kann.
Also theoretisch und mit idealen Bauteilen würde es nicht gehen da nach der Gleichrichtung auch ohne Pufferelko ne Linie rauskommen würde.

Am einfachsten ist es also mit Brücke für die Versorgung und mit Einweggleichrichtung für die Signalrückgewinnung. Wenn man die Einweggleichrichtung für die positive und negative Halbwelle getrennt macht und an zwei Eingänge legt, könnte man eine zusätzliche Redundanz gegen Störungen aufbauen. Die beiden Halbwellen eines Bits müßten ja beim Datenstrom theoretisch gleiche Bitmuster ergeben.

Gruß
Dino
 
Gleichgerichtet ergibt es eine "schönes" DC Spannung und die positive Halbwelle verwendend kommen die Nullen und Einsen für die Datenübertragung daher.
Klang ein wenig nach: Nur ein Gleichrichter für beides, deswegen hab ich ja nachgefragt (und bin davon ausgegangen, daß keine theoretisch-idealen Bauteile verwendet werden;))
Auf der anderen Seite werden seine eigenbau-Decoder ja eh nicht über das DCC-Signal versorgt, also reicht hier eh 'ne Einweggleichrichtung (Die zusätzliche Graetz-Brücke hätte nichts zu versorgen, ist ergo unnötig).
Weiterhin gehe ich davon aus, daß der Empfang des Signals grundsätzlich soweit paßt - er scheint ja schon diverse Decoder entwickelt zu haben. Er sucht nur ein Werkzeug, mit welchem er "zu Hause/in der Hexenküche" neue Funktionen usw testen kann.

Ich kenne, wie gesagt, die konkrete Schaltung der Signalgewinnung nicht, aber grundsätzlich sollte es doch machbar sein, ein Gateway-Controller direkt an den Decoder zu hängen (also ohne +/-22V-Pegel erzeugen zu müssen; was kommt hinter der Gleichrichter-Schaltung noch raus, wenn der Gateway-Controller vorn nur mit 5V-Pegeln und auch nur den positiven Halbwellen draufliegt? Oder kann der Schaltungsteil zum testen umgangen werden, das Signal direkt auf den Controller im Decoder gelegt werden?

(sollte aus Redundanz- oder irgendwelchen anderen Gründen tatsächlich ein komplettes Signal beidseits von Gnd nötig seinmuß tatsächlich irgendein Ausgangstreiber eingeplant werden. Was soll dann im idle auf der Leitung liegen? Zur Versorgung konventioneller Dekoder müßte es ja high oder low sein, nicht Gnd)
 
Hallo ihr beiden,

bin positiv überrascht wie du, LotadaC, dich da "reinkniest". Dino scheint ja mit der Materie vertraut zu sein ;)

1598375824491.png

Die Energieversorgung kommt an den Anschlüssen A1 und A2 rein. Die Energie kann vom DCC Gleissignal kommen oder von einer Fremdspannung. AC oder DC. Alles frisst das Ding.
Auf A3 und A4 wird das DCC Signal angeschlossen wenn nur das Signal verwendet wird und der Decoder fremdversorgt wird.
Die Brücke J1 und J2 kommt zum Tragen wenn der Decoder ausschließlich an der DCC Energieversorgung liegt.

Es gibt mehrere Möglichkeiten ein DCC Signal per Mikrocontroller auszuwerten. Von sehr kompliziert bis eher einfach. Die komplizierteren Varianten werden für die Lokdecoder verwendet. Hier treten sehr viele Störungen wegen dem Rad-Schienen Kontakt auf. Das ist dann fast schon eine wissenschaftliche Arbeit diese Decodierung zu verstehen.
Aber glücklicherweise tritt dieses Problem bei fix verdrahteten Decodern nicht so oft auf.
Ganz einfach gesagt passiert das so: Der Nulldurchgang H nach L wird per Flankentriggerung festgestellt. Ein Timer läuft 1,5 x die Hälfte eines 1-Bits. Danach wird nachgeschaut welcher Pegel anliegt. So wird das 1-Bit oder das 0-Bit erkannt.
Die interne Verarbeitung will ich nicht ansprechen, da mir das zu weit gehen würde. Ist mehr Arbeit als es scheint, da etwa 8 verschiedene RCN-Vorschriften oder auch NEM-Vorschriften vom Decoder zu erfüllen sind.
 
Ah.. ok, also mittels Optokoppler...

Strenggenommen invertiert der OK das Signal, aber das interessiert wegen der Symmetrie des Signals nicht.
Grundsätzlich könntest Du auch den Ausgang eines Mikrocontrollers auf A4 legen und A3 auf Gnd - ab welcher Spannung der OK über R7 allerdings durchschalten könnte, weiß ich nicht - scheint ja auf'ne Differenz von etwa 8,5V dimensioniert zu sein...

Also müßte da ggf 'ne Treiberstufe (Transistor/FET) über 'ne höhere Spannung (knapp 9V) dazwischen.

Da Dein Decoder hinter dem OK auf fallende Flanken triggert, und lediglich den Pegel nach 87µs übernimmt (noch low->"0", schon high->"1"), sollte die Ansteuerung durch einen Controller via PWM wie oben angedeutet gut machbar sein.

Hmm… QuickNDirty parallel zu R7 'n zweiten 3K48 schalten (mal aus der Hüfte geschossen - Dino?) und dann entweder 5V auf A4 oder Gnd auf A3 und den jeweils anderen auf den PWM-Pin des Gateway-Controllers?

Im Idealfall haste dann Deinen USB-UART-Wandler am Gateway-Controller (der den dann auch noch via VUSB mit Strom versorgt), und von da die beiden Leitungen zum OK (wobei ggf der R7 verringert werden muß)

Ich würd's glatt mal ausprobieren, mit 'nem Tiny2313(A) oder so (die X-Cores hab ich mir noch nicht angesehen (wegen PWM)).

Edit: Der OK scheint'n SOIC mit RM=1,27mm zu sein - Pin2 zwischen Anode und Kathode existiert nicht, ergo hat man da sogar 2,54mm. Man könnte also den Gateway-Controller auch (über einen 2K2-Widerstand) direkt an den OK klemmen. Dino würde seine Challemger-Clips nehmen, ich die Klemmspitzen vom Saleae Logic8...
 
Zuletzt bearbeitet:

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)